Hi, I wish you a merry xmas.
I never noticed that a minimized window didn’t return its bounds.
I save the bounds of window when I quit the application in some of my software and I just realise that a minimized window return -26500,-25600,0,0 for its Left,Top,Width,Heigh. A workarround is to make MyWindow.Restore before get its bounds.
Try this sample project WinSizeMinimizedClose.
Click the segmented button “Open/Close Win2” to open the window2, minimize it, and click the button “MsgBox Win2Pos”, you will get -26500,-25600,0,0. If you close it while minimized it (clicking the segmented button “Open/Close Win2”) and reopen it, it will show at its default position. If you check the workarroung checkbox (which restore) it is ok.
I will try on Mac, I’m doing my test under Windows.
Is it a bug ? How can I know the window is minimized if I don’t want to Restore it if not needed (except putting a flag in the minimized.restored event)?
Just tried on Mac. It seems to return the same window size / location when open or minimised:
- Pressed “Open/Close Win2”
- Minimised the window that opened
- Pressed “MsgBox Win2Pos” and got the following:
- Same results with the window visible (not minimised)
Looks like width+length = 0 shows such condition
Well, I guess not, as maximize also changes those properties (usually) to larger values.
That’s an inconsistency. Xojo need to evaluate what’s the proper behavior and apply across the framework. Having a “Minimized” boolean flag makes even more sense here.
Yes, it is.
I would say that if you are restoring a window to its previous location when reopening you never want to restore to a minimised state. That would be very confusing for the user to open a file and not have a window show.
The values provided by Mac are useful in that context. I would agree an “Minimised” property would be useful, just as there is a “FullScreen” property.
Actually, Safari does exactly what you’re describing. Minimize a Safari window, quit the app, and open it up again.
In fact, I think Apple’s Mail also does this.
The modem approach seems to be a complete restoration of the pre-quit state of the application, at least on the Mac. It’s a lot of work but delightful for the user.
I also think they are useful, in any platform, not just Mac. It should act the same in Windows too, or the behavior will be inconsistent and cause troubles in multi-platform apps without “special care” to work properly. And we need virtual properties to reflect the current presentation style: visible, minimized, maximized and fullscreen. Normal would be: not( minimized or maximized or fullscreen )
The bounds of the window are saved somewhere as the window came back to its position/size once we restore it. And, I think I well understood what you wrote above, if we want to put back the window in the state it was before we quit the application, we have to save if Minimized or Maximized or fullscreen and its bounds (but the good bounds even if minimized as if the user restore it after quit and relaunch the app we have to know where restore it). In my case, I don’t want to save if minimized or not, just if opened or not and its bounds.
Then I will fill a bug report, but tomorrow, time to sleep here in France.
The idea is just to be able read the correct current values anytime, and the current state. Save or reopen as you wish anytime too. But reading [-26500, -25600, 0, 0] instead of [100, 150, 500, 200, minimized] will simply destroy anything.
A temporary solution would be to add two properties to your window (TempBounds As Rect and IsMinimized As Boolean) and fill these events of the window:
Minimized event:
IsMinimized=True
Restored event:
IsMinimized=False
Moved event:
if not IsMinimized then TempBound=New Rect(self.left,self.top,self.width,self.height)
Then TempBound would always contain the last known, valid bounds.
Note that, with declares or the MBS plugin, you can replace the “IsMinimized” variable (and related events) with a direct query.
I think everyone knows how to do workarounds for that, but I’m just a workaround hater. 
By the way, if a Window is minimized or not visible, it should not fire “moved” events.
Then you might ask for many posts in various threads to be removed, as answering “simple” workarounds is often done here.
That would be an stupid authoritarian thing, I’m a democratic person. I say what I think, but I won’t demand avoiding other people to say whatever they want. Also, If there aren’t solutions for things, workarounds are the way to go, but I still hate needing them.
Well, saying “your workaround is already well known, it’s not worth having mentioned it” is close to that.
Please, don’t use quotes when inventing phrases.
Why not?
Quotation marks: “they display something that’s been said, word for word.”
Thanks for the workarround, the problem with them is when the bug is resolved years after and we re-read our code, we ask ourself “Why did I do that” (yes, usually I note this is a workarround, but sometimes I have to add code somewhere else and add Global variable etc.). Then workarround make our code hardest to maintain.
That’s one of the things which annoy me with the Xojo team, when I report those kind of bug (which doesn’t seem very complicate), I would love a answer like, ok, we’re on it and we hope to correct it in one or two realize. In this case, as this bug exists for a long time and I just saw it, I would continue like that. If Xojo answer is that they don’t have time for that then I will make a workarround. But make a workarround for some months to correct a bug which exists for years is silly.
Edit: I still not create the feedback but I will soon.
We hit this problem a few years back and had to add code to handle the situation.
My understanding is that there is a fundamental difference in what a minimised window means on macOS and MS-Windows.
On macOS a minimised window seems to retain its current dimensions and the window server just hides it. On MS-Windows a minimised window no longer has any size.
I guess Xojo could possibly work around this but I’m not sure I would call it a bug.
It may not, but it is in fact a framework inconsistency. The framework should try to apply a consistency layer on top of the system behavior trying to make the same code working transparently on all supported platforms. If the system behave differently, and you want to expose how the system works, you should add extra virtual properties exposing the “crossplatorm” condition of the component like the real rectangle of the window when shown (even when hidden or minimized), and the current state of it as minimized, maximized, fullscreen, hidden…