I am trying to update an old app that controls some hardware in my lab. A strange issue is that creating the dialog window to adjust some settings takes ~15-20s just to create the window:
Dim w As MCSSettingsWindow
w= New MCSSettingsWindow
The MCSSettingsWindow is fairly busy- 3 tabbed panels with a half-dozen sliders, many buttons and text entry fields. The window is not displayed until after the settings are entered in later code, so the long delay is just at this line “w=…”. Execution after this seems normal without any delays I can observe.
I see that many of the items in this dialog are deprecated (Panels, Sliders, probably others?) but don’t see why that means it takes so long to create the window (xojo 2022r1 on an M1 Mac Mini, macos 12.3.1). The issue persists on the built application, so not just in the IDE/debugger.
Any advice here? I can’t see any way to “debug” the window layout.
Hmmm… nope- that gives compile-time errors since all the elements in the window are not defined in a generic window.
The other odd thing to note is that even selecting the “MCSSettingsWindow” class definition in the IDE give a long delay and the coloured spinning wheel for 10s or more. It does open after that OK but there is long delay every time I select it.
Start commenting out code. I’d start with anything in an Open event in the window or any of the controls on the window. That might help narrow it down a bit.
Bingo- yes. I changed all the sliders to “reasonable” values and it seems to open more quickly- both while running and also opening the class in the IDE. There is still a noticeable delay (a couple of seconds) so is not “cured” still.
My app speaks to a device that has 12 bit DACs so I used 4096 steps on the slider settings (0 to 4095) mapped onto the actual voltages. Changing them all to 1000 steps (and smaller page steps) made that difference. Not sure how to manage now if this is a “feature” I need to live with. Also odd that it still has a delay with the reduced step range sliders. Would changing to the newer DesktopSlider (basically a rewrite of a lot of code) make any difference?
Is this recognized as a bug (Xojo or Monterey) that will go away someday?
Thanks so much for helping find the issue!
Well it doesn’t seem to make any difference using the new DesktopSliders, Desktopxxx etc, — a very simple test app with 4 sliders in a window (0 to 4096) has the same behaviour. At least that explains why the Xojo IDE has the same issue for editing the controls as the app has in opening the window.
It turns out it is the tick settings (anything but “none”) that cause this behaviour. It is documented in the DesktopSlider section that I didn’t look at as I am using OG Slider still:
