If you could create a sample simulating this part of your process, substituting your real charge by a loop with few sleeps instead of loading a file, it would help to understand the thing, and even help in a redesign of the process to obtain the desired result… Probably without your timers… not sure right now. But I have an intuition that it can be better done using another design.
Log the window position it is moving too and ensure that the width and height are > 0.
This crash is occurring in the Xojo framework, they need to find and fix it. However experience tells me that you have a very slim chance of this getting fixed, zero chance if you can’t provide them with a project that can reproduce the problem.
Does the desktopWindow support the frame rect (IIRC Xojo called this bounds in previous versions). Perhaps you can use this as a workaround?
There are a bunch of declares that you can also use to set the window position, I’d suggest looking into those to figure out alternatives. Just be warned, Apple uses bottom up co-ordinates for the macOS, while Xojo uses Top Down (I personally think top-down is more logical).
I think you mean don’t? I had to read it a couple of times before I realized the “n” was issing…
The way I see it, unless @Ian_Kennedy is passing in weird values (like values that exceed a 64-bit CGFloat, or some other limitation we don’t know about), the problem is not his responsibility.
We also can’t see the values that passed between the 3 (what I assume are C++) Xojo functions before they hit the OS, so this gives plenty of potential for a function to mess up the values.
The function [NSWindow _oldPlaceWindow:fromServer:] does cause a little concern. Last time I saw an API identify that’s its old, it had already stopped working and I had to use an alternative.
Situations like this are why I lobbied for a dedicated macOS programmer, someone who can keep the framework up to date. Apple move at a frustratingly rabid pace, and its tiring just keeping Sleep Aid up to date. I had to make changes for 12.6.x, 13.3 and even 13.4… The longer Xojo goes without having a dedicated macOS person, the more they’re going to struggle.
@Ian_Kennedy In case it helps in any possible way. It is window.bounds that I use to restore a window’s position on re-open.
I forgot too about “window.bounds”… lately and had troubles (the window’s title above the MenuBar, etc.) until I use the same values, but set in a Bounds…
And then: it magically worked fine, placing the window where it belongs (for me) !
Thanks for the many replies. I was actually in bed responding to some of these items, teaches me to post an issue last thing when USA and that part of the world is fully awake.
I will look at the values but I don’t think they are going to be the issue, it is always the same window and in a perfectly ordinary, single monitor, place. Certainly worth checking.
I will take a look at window.bounds. One operation is better than 4 in any case. If the API under the hood is different it could help too.
As for refactoring, I’m sure there are better ways of doing things than 3 years ago when this process was put into place, however, I’m close to a release and don’t want to majorly refactor an item that has been working and stable for the last 3 years.
So swapping to bounds rather than top etc does, at least so far, seem to have removed the problem. I’ve loaded 50 test files about 30 times now and not one crash. I’ll continue to test.
I will also try and track down a repeatable condition that can cause the original problem.
DesktopWindow contains a property called Bounds. Prior to saving I now have a Window property called Bounds, which I assign Window.Bounds. This makes a Thread safe version that I am using when saving.
The bounds are then written to my file. On reloading I recreate a version of WindowBounds rect and then assign them to the window in the final method. Instead of:
x = n1
y = n2
w = n3
h = n4
I can now do:
MyWindow.Bounds = LoadedBounds
The window’s location and dimensions are then set in that one operation.
Bounds is a rect, I never inspected it to see if is a struct or class, if struct it can can be saved as is, if object it must be serialized or you will get garbage. And there’s no thread safe visual operation, it must be set in the main (UI) thread, never from a user thread.
As you said it worked before, I assume you are doing the bounds part ok, but I’m afraid about where it is being set (UI or User thread).
Also not sure how Xojo is handling it under the hood.
If the bug is being triggered at
MyWindow.Bounds = LoadedBounds
From the UI thread, this may be worthy a try trying to workaround triggering the bug
As I pointed out I duplicate the Window.Bounds into a property so the thread is able to access the property and save it (obviously in a file friendly way) the thread never accesses Window.Bounds.
Equally, when I load the file it creates a new Rect in the threaded load process. In the Main thread when the process is complete I assign the thread created Rect to the Window.Bounds property. So far there hasn’t been any issue assigning to Bounds, rather than top, left, width and height.
So far I have not needed to hide the window while I assign Bounds.
To be clear:
// This triggers the error
Window.top = TopValue
// This, so far, does not
Window.Bounds = LoadedBounds
(especially lately)
