Xojo 2021 release 3.1. macOS Monterey 12.2.1. Very-long-time user. Lite Mac license.
I have a big, complicated, personal-tool project with sixteen windows and many classes and modules. I rewrite deprecated language constructs when and as I get to them and there are plenty left. I’m not sure when the problem began. In my project, there is a single window among many that causes the IDE to hang with a spinning rainbow wheel, and to show as “unresponsive” in “Force Quit Applications.” It hangs the IDE when I click on it, so I can’t export it. A text search will find methods and other code in this window, and the code loads and displays with no problems and without freezing the IDE. I imagine it has something to do with the window and control layout. The application builds and runs normally, but freezes with the spinning raindow wheel when I take actions that open that specific window. It freezes whether I run within the IDE or build the app and run the app.
The main things I’ve done to troubleshoot the problem are to run older versions of Xojo, as far back as 2019 release 3.1, and older versions of the project, as far back as the first one containing this window. They all show identical behavior. I’m not what to try next to troubleshoot.
I’d like to export the entire project to source and reimport it but I don’t now to do that. I can’t export the offending window because the IDE freezes when I try to select it.
The window has been in the project for a couple of years and many small incremental project changes and has never had problems before.
Anything’s possible, but the problem began with in the last few months–I know it because this window is associated with a program function I use a lot, and it has worked until quite recently. I have saved copies of the project file from the past, when I know the problem wasn’t occurring, and trying to select this window hangs the IDE on all of them. The thing is, even if there is circular parentage, I don’t know how to troubleshoot or fix it if the IDE hangs when I select the window! I would argue that the IDE probably shouldn’t hang in a situation like that. I suppose I should try letting the wheel spin for an hour or so and see if it ever terminates with a useful error message.
In the IDE, select that window entry from the Navigation pane, then print it to pdf.
You will get all code from that window inside Events, Controls, Methods. Print it and you will understand what I mean.
Most interesting, you cannot overlook (forgot to watch) code.
If there is offending code there you will found it. If the code is elsewhere… I do not know.
Another idea: if the window is self working (no dependency or little), export it, create a new project, import it and run… In all cases, it will give you clues (quite sure, not time consuming, only some minutes).
Please remember that any attempt to select the window from within the IDE causes the IDE to hang, with a spinning pizza wheel, and become unresponsive according to the Force Quit window. Since I can’t select the window within the iDE, I can’t export or print the contents of the window.
Remember that simply selecting the window within the IDE causes the IDE itself to hang. Experiments show that anything within the code that causes the window to open or to show hangs the running application. This seems to happen before any event code within the window is involved.
While there is no certainty of the circular ref I mentioned, one way to test this might be to obtain Arbed and open the window for review there
In this screenshot, I have done that for a simple window that has a canvas control, plus a pusbutton.
At design time, the pushbutton is a child of the canvas.
You can see that the Canvas is the initialparent of the button.
By deleting “Canvas1” here, I could force the pushbutton to be a child of the window instead.
But Arbed might also reveal other odd properties…
Only by dragging the control so that it is no longer on a control showing a red border.
And you can only do that if you can open the window in the IDE, which the OP cannot do.
There is no exposed property in the IDE inspector for parent that I can find.
You can set the parent to nil in code at runtime when the window opens, if the app runs.
I was referring to having control a’s parent being control b, control b’s parent being control c and control c’s parent being control a in the IDE. Since, with design only (without any code), each control must be below another to be its parent, you can’t get a loop.
Agreed.
The prospect of circularity is purely a guess based on experience of other ‘things that get tied up in knots when opening’
Only the OP and Xojo have a copy of the window.
I’ve experienced cascading paint events on PC, but the OP is using Mac, otherwise I would be suggesting overalapped controls.
Something may have an invalid size and be causing a memory problem.
This is happening in the IDE! It is happening when the program is not running. It happens when I am just trying to edit the project. I agree that there is probably a close loop, but it isn’t a loop in my Xojo code. It’s a loop in the IDE that is associated with trying to view the window layout.
what about saving a copy of the project in text format and looking into the file that contains the Window with a text editor. Maybe you can see something strange and remove it from the window. After every change open the project in Xojo and check if the issue still exists. Tedious, I know…
