I am struggling with something which I’ve been after for a while now - as the title says, I am trying to prevent users shrinking my panel past a certain width (because at that width and smaller, my formatting breaks down).
An interesting thing is, some of the default panels do this, while some don’t. For example, you can shrink the Flight Assistant down a width (and height) of a top-left minimize button (on the left), while at the same time, the Weather panel (on the right) stays fixed at a certain minimum width and height:
Also, there is a free add on out there, WBSIM C172, which does have an in-game panel with the same ability to stop shrinking at a certain width and height, however, when looking at its code, there is nothing to indicate that they are limiting the width - unless, somewhere deep inside default stylesheets, there is a specific class whose parameter contains a style that affects the size limiting. There are only 3 source files for that panel, HTML, JS and CSS, and the usual manifest and json files, plus, of course, a spb file which I am not sure if it contains any formatting info. I’ve looked inside them and couldn’t find anything that would indicate resize limit.
Hi! Thanks! This is exactly what I was looking for!
However - it is not working for me - when I invoke the panel, I get a whole screen blurred, as if the panel is huge, and I see a small but empty part of it (the empty parts of those panels blur the sim background). What are the units here? I assumed pixels… this is what I have:
To answer my own question… I determined that I need to divide my pixel values with a factor of 10.38 to get the values I need. This worked… but, what is the significance of 10.38?
I am not a web designer, but I do get by quite nicely with the limited info I have. However, if this is some arbitrary value being used here, this is some of the wirdest stuff I have seen in a long time
I’m the one who created the toolbar for WBSIM C172.
I can’t find anything in the documentation that confirms this, but I’ve always considered these values as relative units normalized to the simulator’s viewport (0-100, as a percentage).
This allows the toolbar to have consistent (relative) dimensions regardless of the user’s monitor resolution/size.
Therefore, minWidth=“43” and minHeight=“43” will indicate that the toolbar should occupy at least 43% of the viewport.
+@Jayshrike Thanks for chiming in, but not quite. To get exactly to 500x800 pixels width and height, I had to use
minWidth="48.17"
minHeight="77.07"
Given that my screen is 1920 x 1080, if these were screen percentages, that would compute to 925x832. Perhaps it IS some kind of a percentage, but not of the display - perhaps something internal to MSFS. Asuming these values as percentages, the MSFS “desktop” would be 1038 x 1038 (hence the factor I mentioned).
And thanks for your toolbar/dialog, @TugaAviator ! It helped me getting things going!
In a 1080p, we typically observe:
virtualHeight = 1038
This value appears to be an “effective” UI height, coming from the layout system (viewport + internal rendering constraints). It can also be found in several core simulator files for margins, widths, etc., via:
calc(var(–unscaledScreenHeight) * 42px / 1080);
The /100 corresponds to the normalization of XML units:
XML values are defined on a 0–100 scale, i.e., as a percentage, but based on the virtual resolution rather than the actual screen resolution. 1 XML unit = virtualHeight / 100
The factor 10.38 is not a fixed screen constant, but the result of the conversion between a virtual height provided by the MSFS runtime and an XML system normalized in percentages.
More on this - I have by mistake used an old XML file that makes spb, which had (wrongly) width and height units in pixels (500 x 800), and now my panel is a huge mess that opens at a size of 5000 x 8000 pixels, just a blurry white overlay on the screen. There is no way I can resize it. Cuherent Debugger shows
The thing is - I have corrected the mistake, created a new SPB (used measurements from another file that I know work), however, nothing changes. It’s like SPB is cached somewhere, and it won’t go away. I did everything - cleared the package from the project folder, making sure the one in the community is the only one, re-started a few times, cleared rolling cache… nothing.
Is there a trick to this SPB? Do I have to do anything with Coherent Debugger?
The SPB can indeed remain “stuck” even after recompiling, especially with Coherent GT.
The issue usually comes from the fact that the compiled panel size is already stored somewhere, and the sim keeps loading that saved state/version.
The simplest solution is:
In the XML, set proper MINIMUM values for width/height.
Reload the panel in the sim.
Use the manual window resizing in MSFS until the panel becomes usable again (the window should eventually clamp to the minimum dimensions defined in the XML).
Once the window is back to a normal size, recompile the SPB with the correct final values.
The Coherent Debugger usually does not help for this issue — it is generally not what keeps the bad scaling cached.
The problem is more likely related to the saved panel/window state on the sim side.
You can also try deleting the saved layout/UI files in the MSFS LocalCache folder to force a complete reset of the panel window sizes.
I tried this - I re-compiled the SPB with “normal” values, including MINIMUM values of something like 4 and 4 (which should translate to ~40x40pix. I got the same thing. I COULD resize manually from the bottom and right, but it never clamped back to a size where it would show me the top bar or any menu content - just a blurred overlay. Am I missing something?
Where exactly and which types are layout/UI files? I am looking at my LocalCache folder but nothing points to any files that would hold panel window sizes… unless you meant, blow the whole LocalCache and let the sim rebuild it? I am afraid what that would do to my settings…
