I have a few Movable Modal Windows (dialog boxes) and one thing I’ve noticed is that if the mouse moves out of that box area then any “MouseEnter” events that are on the underlying parent window are fired. Fortunately the MouseDown Event is not, but it doesn’t look good, and likely confusing for the User.
I guess I could have some code on each control not to fire if another window is open?
What would be the simplest way to avoid this?
In each Window MouseEnter Event , check ifthat window is frontmost Window(0) and execute the code ?
Personally I wouldn’t do what Emile suggests as I don’t think you’ll have mouse roll over if the window is in the background so it will look like the app is unresponsive as you roll over it from another app.
Xojo should really disable the window that opens the modal window to stop things happening on the previous window until all actions are complete on the modal window and its closed. This would be standard windows behaviour (I just checked it in VS2017 to make double sure).
As Xojo doesn’t do this, you need to disable the window first using:
Declare Function EnableWindow Lib “User32” (hWnd As Integer, bEnable As Int32) As Int32
Then call your modal window.
Then call it again to in your Window.Close to re-enable the parent window so that focus is return to that window.
Now, in your MouseEnter you can check:
Declare Function IsWindowEnabled Lib “User32” (hWnd As Integer) As Int32
to stop code from running.
That being said, all this should be handled by the Xojo framework as there are windows events raised that you would rarely come in contact with (WM_CANCELMODE and WM_ENABLE) that controls should be listening for to disable their own functionality thus removing you from having to do all this. I’ll make a feedback about this.
In case this is all double dutch 
I’ve made a little demo for you here, if you have any questions about it, let me know.
@Julian: no problem from me.
I hope you don’t take it the wrong way, its a valid idea/method 
just because I dont think its the best way doesn’t mean its wrong, everyone else might be ok with it
Mouse events can happen on any window - not just the front most
Absolutely not. When a solution (or a good / better solution) is shared I am happy and grateful.
(thus my answer).
Well, I hope you BOTH don’t take this the wrong way . . . but I believe I’ve come up with my own solution.
Julian, I appreciate you creating that demo - I had a look at it, and it does indeed solve the issue. I can’t really understand how it works exactly as Declares are beyond my scope at this point and I would prefer to understand the code that I’ve used.
What I did was along the lines as suggested by Emile, but will not cause the potential issue of no mouse roll over if the window is in the background causing the app to look unresponsive.
Most of the buttons of concern are custom buttons with 3 states: disabled, enabled and mouseover, which did complicate things a bit because the state change is driven by whether they are disabled or not.
I created a global boolean flag: anotherWindowOpen which is set to false as the default. The rest of the code is pretty much as it was except for adding AND anotherWindowOpen in the If/EndIf block in the enter event.
The only other thing to do was to set the flag on the modal dialog to true on open and false on close - which has to be done for all the other modal windows.
In the MouseEnter Event:
If Me.Enabled = True AND anotherWindowOpen = False Then
Me.MouseCursor = System.Cursors.FingerPointer
Me.Backdrop = IconMenuOpenMouseOver
Else
Me.MouseCursor = System.Cursors.StandardPointer
End If
In the MouseExit Event:
If Me.Enabled=True Then
Me.Backdrop = IconMenuOpenEnabled
End If
I know this is a bit of a “hack”, but I can’t see an issue with this method (yet), and would be happy to hear if there is a potential problem that I haven’t forseen.
Thanks Norman. This issue does not present itself when using a simple MsgBox or a standard Open/Save dialog box. So what is the difference with those?
Cheers.
Dialog Box .
and also:
Dialogs .
Basically a Dialog interrupt the application running, whie a simple window does not. [I do not found text that confirm my memory: am I right ?].
In FireFox, an Open or Save Dialog (open/save file) does not allows you to access the owning Window.
Thanks Emile.
I did some testing today at my work (don’t tell the boss 
) I used every software software I could think of on both Windows and Mac OS and they all behaved as they should.
A “floating window” will give access to the parent, as it should (ie. toolbox etc.). But a Modal Window should not, and it did not in all the apps that I tested.
Also as Julian pointed out, he tested in VS to be sure.
[EDIT] Like I said in my first post - it’s not that bad because at least the MouseDown Event is not fired - it just looks like it could be.
Nice.
Well, it’s taken me an hour or so to change the code in all the custom buttons and all was looking good until . . .
I’ve realised that my code and solution will only work with “custom made” buttons. The standard buttons, including dropdown lists etc. cannot benefit from my dirty work-around.
Fortunately there are only a few, and I can disable/enable them when anotherWindowOpen is True.
So, in the end code is likely indeed be the best way - hard for me to understand though.
IN ANY CASE, As pointed out by Julian and my own basic tests of other built software - this should not happen - it’s a Xojo issue.
The thing is, that before posting this yesterday, I wrote down in my notebook (as I always do) what part of my code I was going to tackle next. It certainly wasn’t this issue. But I’ve spent all this time working on a “fix” that really should not need a fix.
I do love what I’ve been able to achieve using Xojo, but it’s these little things that consume my time and energy that annoys me sometimes.
btw. Is this issue only related to Windows - or does it also happen using MacOS as well?