In Cocoa, the following code:
Pushbutton1.Action
Window2.Show
for i as integer = 1 to 100
app.SleepCurrentThread(20)
nextThe window appears instantly - you don’t have to wait for the current event to complete two seconds later.
However, when using .Visible=True:
Pushbutton1.Action
Window2.Visible=True
for i as integer = 1 to 100
app.SleepCurrentThread(20)
nextWindow2 won’t actually become visible until the for loop has completed.
I am guessing here… but a few things come to mind… none of which would classify this as a bug… and I may even be wrong 
And I’m also “assuming” the for #2… that Window HAD been visible previously… or the delay makes even more sense… as it has to turn the VISIBLE=TRUE into a SHOW as well.
If it’s a message vs. event difference, it wouldn’t explain why Window.Visible=false also works immediately. So what’s weird to me is that there are 4 ways to change the visibility of a window, and in Cocoa, 3 of the 4 happen immediately but one of them is delayed until the next event loop.
Since there’s a workaround this is not a terribly critical issue.
Visible really should be read-only. Show/Hide are the correct methods to manipulate the visibility of a window.
Actually, both are needed as they are not synonyms:
Window.Show : will make a window visible AND make it frontmost if it’s not
Window.Visible=True : will make window visible but will NOT make it frontmost.
In other words, you can change a window’s visibility without affecting the window ordering.
Actually, this brings up an issue with my workaround:
If you substitute Window.Show in place of Window.Visible=True, then the behavior is not quite the same : Window.Show will also make a window front-most, which may (or may not) be what you want.
So it would be nice if the bug gets fixed so that Window.Visible=True operates at the same time as the other 3 commands.
Michael, if you want a window “invisible” but to maintain its z-order when you “show” it, move it offscreen to “hide” it, and back onscreen to its previous location to “show” it.
That’s a valid technique, although it’s not always obvious what “offscreen” is, given that a person can have very weird monitor setups - such as 8 monitors stacked vertically with the menubar on the bottom one : the coordinates (-10000, -10000) might be onscreen. Truth is stranger than fiction, etc.
Iterate the screens. Keep a minimum top. Move the window to minTop - window.height - 10. Benchmark that with a couple monitors to see if it’s a performance hog. If it is, cache the value and listen for an Apple Event telling you that the screen configuration has changed.
That would work, surely. Even better if the bug is just fixed, though…
Not so sure it’s a bug. Could very well be least common denominator among supported platforms or a design decision to do what users typically expect.
[quote=24367:@Brad Hutchings]Not so sure it’s a bug. Could very well be least common denominator among supported platforms
[/quote]
Win32 and Carbon work as expected, and this behavior is new in Cocoa for the one particular case.
What user would expect 1 out of 4 ways of controlling window visibility to be different, and only one 1 of 3 platforms?
Occam’s razor: it’s a bug.
It’s certainly possible that the bug is due to limitations in the underlying Cocoa framework, in which case Xojo could document the limitation in the LR.
OK, so file a bug report. See where that gets you. A lot of things that I think are bugs turn out to have a reason behind them. I’m just saying that this could be one of them. You and I don’t get to decide that with whomever’s razor we’re using :-).
Hi Brad, you might want to read the thread more carefully before responding - a bug report was already submitted - Also, please try the demo app (which was uploaded with the bug report) before you claim ‘it’s not a bug’.
Michael, you might want to read it more carefully too. I was addressing the “bring to front” portion of your issue.
Oh, so when I said “the bug is fixed” you assumed I was talking about something other than the bug report which was the topic of this thread? That would explain the confusion…
You never said “the bug is fixed” before the previous post. Anyhoo, no worries. If you want to file a feedback on the z-order issue, go ahead. It does not look to me like you have. In the meantime, I’m pretty sure you have a very workable workaround for that issue, whether it is determined to be a bug or not, above.
Just to clarify: I said “if the bug gets fixed” (which is the post you replied to with your suggestion about offscreen) and then again “the bug is fixed” a few posts later. In both I was referring to the bug report that I filed.
The Z-order discussion (the fact that .Show will change the Z order, where .visible=true will not) is not a bug - that’s how .Show and .Visible are supposed to work. The point I was trying to make was that my proposed workaround (use .show instead of .visible) doesn’t solve the problem in all situations, so I would like to see “the bug” https://xojo.com/issue/28580 fixed.
So how about someone at Xojo take the time to explain this and also what we should do as the “proper” way to get the same behavior we had in Carbon ?
Self.visible = true doesn’t work at all for me, even if after it was set to true I click on the App icon to activate it. Unless I use self.Show, the window will stay hidden forever.