ONE window in my project freezes both IDE and running app

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.

Wrong. To print a window contents from the Xojo IDE, you only have to highlight its name in the navigation pane.

If that crash, your project may be corrupted.

Did you try to copy the project file in a different disk ?
(if this is possible, the file can be OK even if the project contents can be corrupted).

You can export the project to xml or save it as Xojo Project (not Binary) if you have a license.

Other ideas ? Guesses ?

Where the project resides ? In the cloud ? in a prehistoric hard disk ? (very slow HD) :grinning:

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.

Out of curiosity, what version of Xojo were you using previously that did not have this issue?

1 Like

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 :wink:

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.

To help narrow this down, what versions of Xojo did this work fine with?

That would seem to indicate that it’s not an IDE problem per se.

Feels to me like either the project got corrupted, or one of those “small incremental changes” did something Bad to the window in question.

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.

Any chance you could find a way to run the Profiler to see whee it’s spending all of that time?

OP said it’s not happening when the app is running, so the profiler wouldn’t have any data.

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.

This may have been asked - but did you update the operating system lately? I wonder if something external to Xojo may be the cause here.

The very title of the question seems to say otherwise: ONE window in my project freezes both IDE and running app

And even if it’s only happening in the IDE he still could do an OS level Profile to find out where the IDE is spending its time…

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.

From Norman at TOF:
Try this he says:

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)

Then at least that offender can be diagnosed