Bug Report: internal code error when calculating screen size to display windows causes erratic size and scroll bar appearance

[OceanHydroAU]

As the majority of Fusion 360 users know (and hate), there is highly erratic behaviour of the size of input dialogues - sometimes they're OK, sometimes they show a scroll bar unnecessarily, making it unnecessarily difficult to reach the options we want, and sometimes (on smaller screens) the UI is so tall that the lower parts are off the bottom of the screen and are impossible to reach.

Here's one example (like I said - 50% this works, 50% this fails, at random):-

As you can see above - there's tons of screen space - it did not have to make me scroll to reach the factor:

This is what it looks like the other 50% of the time (at random):-

I'm a maintenance programmer - so I can tell from the above symptoms, that the cause of the problem is code which seems to be your measurement of the screen size - you're measuring something else (maybe the pointer address instead of its value?) and not the actual screen space.  This random number that's not the real screen size, is causing all the above problems (when this random number is smaller than the screen really is, we get unwanted scroll bars, and when this random number is larger than the screen really is, the UI is built too large, and goes off the bottom of the screen).

Please fix !!!

FYI - I use a Mac, not windows.

 

[HughesTooling]

This is a very old bug and has been reported many times!😞 It's not actually random though, if a dialog is docked to the right side of the screen or not docked it will resize but it will not if it's docked to another dialog.

Here I've moved the measure dialog to the edge of the screen and it resizes correctly. Unfortunately when the UI was updated another bug was introduced so the position of dialogs is no longer maintained between sessions so you have to reposition again after restarting Fusion.

Mark

[OceanHydroAU]

What makes you think it's not random?  I repeated the one I reported a dozen times (and it failed about half), plus I've seen this hundreds of times over the last few months, and there's no 100% repeatable pattern I can find, which definitely sounds to me like a C programmer is doing a "if(pointer>wanted_size){}" when they *should* be doing "if(*pointer>wanted_size){}" or the logical extrapolation of somehow using a value that's more-or-less random every time, no matter how hard I try to keep everything else the same.

The problem with random, is that if you do something and it looks like it works - you're not right, you're just "lucky" - you've got to do it 4 or 5 times again and for it to work every time, otherwise you can never be sufficiently confident that the dice-roll isn't just tricking you 🙂

[HughesTooling]

Maybe the size of the dialog is random but from what I've seen it's always when you dock a dialog to another dialog and this has been known for about 6 years! Did you try setting up like my image with the dialog docked to the edge of the screen not docked to another dialog? I'm using a PC so perhaps it's different but the first thing I do after restarting Fusion and creating a sketch is move any dialog like pattern, measure etc. to the edge of the screen then dock the sketch palette to it's left side and then have no problems. 

Seem to remember when support has bothered to reply to reports of this problem it's been blamed on the library they use for the UI (QT?). Perhaps it's using the size of the dialog it's docked to?

[OceanHydroAU]

OK - interesting - I wasn't aware that dialogs stayed where they got put last time (it's certainly not obvious on mac - there's always a gap between them and the edge if you drop them when the edge goes green, which I've just noticed happens and I don't know what that means - dock I guess - hard to even notice since it only happens when the mouse itself crosses the edge, not the dialogue, and who moves the dialog just halfway off the edge of the window, or tries to move it outside the visible area of the screen?)

But yes - that definitely seems like a clue!  When I did that, it worked 3 times in a row (while it failed the previous 3 times when not at the side of the screen).  Looks like the buggy code doesn't execute in that scenario.

It would be nicer to fix the problem of course - there's way too many dialogues to open them all and no room to dock them all on the side 🙂

So far, they do seem to get around to fixing stuff we report when we plaster the word "bug report" all over it and post it in this forum: their workflow is to hunt for these things once per month I was told (then I guess when it's on their radar, priority dictates how long before they get a coder on the fix - if it's a crash, they do those immediately - I dunno how they schedule the other things).