Yes. I got a response from Xojo feedback. Among other things, I fibbed. The window only causes the IDE to become unresponsive for about fifteen minutes. I’m very slowly struggling, one editing action every fifteen minutes or so, to see if I can identify something within it.
Xojo notes that the window has more than 250 controls on it. (You know… it just grew. I’m not defending the UI design). But it wasn’t a problem before, I don’t understand why it suddenly is. I actually succeeded in cutting a group of about fifty controls in three control arrays from the window and pasting it into a new, blank window, without much change.
I’m not sure what the normal behavior is, but the result of cutting and pasting was that every control in the the received renumbered indexes, making me worry that the controls didn’t really get cut from the offending window,–even though they aren’t visible.
It resides on the SSD boot drive. And people keep ignoring the fact that this is new behavior. This is completely unlike anything that has happened before, and this project is something I’ve been nibbling away at for at least five years.
Today, we have super-fast computers and can write thousands of records to a database with virtually no waiting time.
But to display a form with 250 controls on the screen takes 15 minutes? This shows that something is fundamentally wrong in Xojo or that far too much happens internally when displaying a form. Sometimes OOP and events could be evil
This isn’t a performance problem. This isn’t Xojo slowing down because I just keep adding more and more controls into a window. This is something broken, somewhere. This is the same crazy-bloated-easier-to-just-keep-adding-than-to-refactor window that worked fine for three or four years.
It is not a question of small incremental changes, and if I could address it by backing out a few recent changes I would. I regularly save copies of the whole project, and the problem is occurring in copies of the project as old as a couple of years ago. It is also occurring with older versions of Xojo back to a couple of years ago. I see two possibilities: macOS system changes, which I’m working on; or, new versions of Xojo are installing things somewhere, maybe Preferences or Application Support, that are affecting the behavior of older versions of the app.
More than 250 controls on the same window probably explains your issue. The IDE probably redraws every control individually, resulting in a sensible amount of time. Although 15 minutes seems way beyond a redraw of a couple milliseconds per control (already terribly long).
What kind of controls are you talking about ?
But it may also come from some corruption of the window code. Perhaps try to recreate the window. Careful copy and paste of controls onto a brand new window could perhaps be a way to mitigate the issue.
a) Use containers everywhere.
b) Always use external items instead of a single file. This even works with the lite version.
c) Don’t make copies. Instead use SVN or Git or whatever.
You pretty much can’t use SVN or GIT with the Lite version it doesn’t allow you to save in a non-binary format. You can’t save as XML or Xojo Project. You have to pay 3 times the price to get that feature.
It happens in the IDE. It also happens when the program is run. Basically, any action that would cause the window and controls to be displayed, either within the IDE or at runtime, causes a 10-minute stall.
Unequivocally: it happened when I upgraded from macOS 11 to 12. I had saved a full bootable image backup of 11.1 on an external rotating USB 2.0 disk. Booting takes about half an hour and applications take minutes to open.
Running Xojo 2020 Release 1.2 under macOS 11.1, I was able to open an 11/19/2020 version of my project in the IDE, and (once loaded), the offending window display and loaded in about 3 seconds. Normal.
Loading the same version of the same project under the same version of Xojo, under macOS 12.2, displays the same old 10-or-so-minute load time. 10 minutes under macOS 12.2.1, three seconds under macOS 11.1.
I can run the app under 11.1 and it, too, behaves “normally,” with the offending window opening in a reasonable amount of time.
I don’t know where to go with this, but the problem is definitely associated with Monterey.
Save the project from an old version as text or XML (or find someone who can convert a binary project to XML)
Something
Make a copy of that
Work only on the copy
Using JUST a text editor remove one window at a time to find the offender (how to do this varies depending on what textual format was created)
