I’ve checked it on OSX (10.11.6), at this moment I can not check it on Windows.
You have a main normal window (Frame=0) and open a Modal Window (Frame=1) on it.
When you move the mouse pointer across these two windows, MouseEnter and MouseExit events of the main window are raised.
I thought that a Modal Window prevented all events out of this window.
Is it a bug or am I confused about modal windows?
PS.
It happens exactly the same with a message box
On Mac, windows receive such events even when they are in the background. Not on Windows.
In my app Char Menu Windows version I could not use any standard event to detect mouse movements and click. I had to resort systematically to System.
Yes. May be. The truth is I’m finding a lot of problems trying to move one application from Windows to OSX, and most of the problems are related to modal windows.[quote=284133:@Michel Bujardet]On Mac, windows receive such events even when they are in the background. Not on Windows.
In my app Char Menu Windows version I could not use any standard event to detect mouse movements and click. I had to resort systematically to System.[/quote]
Michel. Thanks for your comments. If Modal Windows behave differently on Windows and on OSX, this is very important and should be stated clearly in LR. I will check tomorrow with my Windows PC and I’ll file a request about this missing information.
It is not as drastic as you may think. Only MouseEnter and MouseExit are in fact still active. When a modal window is displayed, other windows no longer fire other events, such as mousedown (which I noted the modal window receives), or MouseMove.
But it does not hurt to specify it in the LR.
The other differences I noted were that a window that is in the background (the app as well) still receives mousedown and mousewheel in Cocoa, while it does not in Windows. Which I needed to do for my virtual keyboard.
On OS X, you are able to make screen shots on each and every window that appears on screen *, not only the front window. I imagine that if these two events are not fired, this feature cannot work.
Of course, when you do not know that, you may be surprised.
This is my opinion: for this reason I do not consider that as a bug.
(I keep the right to be wrong on this one.)
Make a window screen shot, any window that have a bit of it visible:
cmd-shift-4 + SpaceBar when the Mouse if above a Window, then Click.
That’s true. It is not as drastic. But only if you know it. Of course you can say I should know it, but I didn’t.[quote=284163:@Emile Schwarz]On OS X, you are able to make screen shots on each and every window that appears on screen *, not only the front window. I imagine that if these two events are not fired, this feature cannot work.
Of course, when you do not know that, you may be surprised.
This is my opinion: for this reason I do not consider that as a bug.
(I keep the right to be wrong on this one.)
Make a window screen shot, any window that have a bit of it visible:
cmd-shift-4 + SpaceBar when the Mouse if above a Window, then Click.[/quote]
Emile, I do not consider that as a bug either. Now, that I know.
But it is a bit bizarre. Because not only the window, but other controls, for example, in my case OpenGLSurface, fire the MouseEnter and MouseExit events.
And estrange things happen if you are not aware of it. For example a msgbox can be hidden by the main window, blocking the application and you see nothing, until you realize that the message box is behind the main window.
I don’t like it, but that’s the way it is, and probably Xojo can not avoid it.
But I insist they can warn us. In fact LR is full of warnings about something applying just Windows, just OSX, just Linux…
Hi Ramon,
I just realized that in your front window, you can check the MouseExit Event (of your front window). Starting from there, and until MouseEnter on your front window, everything is “not for you”.
A bit raging, but once we know…
Sometimes ago, when I pressed the Delete key in a Open | Save Dialog, and if the “previous front window” had a ListBox with a selected Row, that row was deleted (if you implemented the Delete key --> Delete a Row. The solution is to check the window.
I do not checked that recently.
[quote=284196:@Emile Schwarz]Hi Ramon,
I just realized that in your front window, you can check the MouseExit Event (of your front window). Starting from there, and until MouseEnter on your front window, everything is “not for you”.
A bit raging, but once we know…[/quote]
Yes, you are right. I can check Modal-Window Mouse_Exit event, raise a flag and when Main-Window Mouse_Enter event raises I know that I have to do nothing. In fact in another thread related with this I showed how I checked if there was a ModalWindow open when I entered the main window.
But, how do I do when what is on is a MessageBox? In this case there is no MouseExit event, and in main window I can not check if Mesage box is on.
Or… I can and I don’t know how to check it?
I won’t. I discovered it…
It is a system thing. Only global floating windows can pop above the front app window. It is conceivable to create a global floating MsgBox : create a small global floating window, and inside create a tight loop that can only be stopped by the button. That will effectively stop execution in all the app like a MsgBox. It would not prevent clicking outside, though.
Maybe one of our Cocoa declare geniuses can produce a modal global floating window ? There are so many options in the framework.
[quote=284225:@Ramon SASTRE]But, how do I do when what is on is a MessageBox? In this case there is no MouseExit event, and in main window I can not check if Mesage box is on.
Or… I can and I don’t know how to check it?[/quote]
You set a flag before you display the MsgBox, and as it will freeze execution until it goes, simply set the flag false after the line where you call the MsgBox.
Michel,
Thanks for all your suggestions. With them and with all I’ve discovered during the last days I think I can try to deal with Windows/OSX modal windows. It’s a pity that there is no standard behaviour. In fact I have not checked Linux, although probably it’s another case.
Events are not really cross-platform. The docs state somewhere, that for example the order of events is not guaranteed across different platforms.
I have dealt with cross platform design twice in a row : With Char menu which exists in Mac and Windows, and now with Check Writer III I designed originally on Mac, and then moved to Windows. Between the bugs in TextArea and specific stuff that flickers on Windows and not on Mac, I ended up having, again, two different source files, which I had avoided with the previous title.
The more complex an app, the more differences one finds that make a single source simply impossible.