Re: Stopping onClose Event in Win32Lib
Patrick Quist wrote:
> What's wrong, I use for cancelling the request of closing by :
>
> WinMain(MainWindow)
> onload_MainWindow()
>
> That's all!
Well, for one thing, it doesn't *cancel* the request. At best, it re-opens
the window after it's been closed. Let me explain what currently happens
when the close icon is pressed in a window in Win32Lib, and why I prefer my
method:
1. Pressing the close icon issues a WM_CLOSE event to that window.
2. On getting the event, the Euphoria event handling code WndProc is
activated.
3a. Since this is a modal window, Win32Lib does some internal monkeying with
the popModal routine to make sure that if there is another modal window, it
will receive focus.
3b. If the window is modal, it is hidden (not closed), and WndProc is
exited, and the following events are *skipped*.
3c. If the window was *not* modal, the onClose event is run.
3d. The DefWindowProc routine is run to handle the default Win32 actions.
This generates a WM_DESTROY event.
4. On getting the event, the Euphoria event handling code WndProc is
activated.
5. If there is an onDestroy event, it is triggered.
6. WndProc calls PostQuitMessage to shut down the application.
*Whew* Been paying attention? If so, you might have noticed that onClose
doesn't work for modal windows. Oooops. Bug fix time.
Now, if you want to prevent a *modal* window from being closed, your only
chance is trapping in the onEvent routine, because the only window to see
the destroy event (WM_DESTROY) is the primary window. That's because
Win32Lib doesn't call DefWindowProc when a modal window gets a WM_CLOSE, and
so a WM_DESTROY never gets generated, yada yada yada.
On the other hand, if you want to prevent the *primary* window from being
closed, you can either trap it in onClose or onDestroy event handlers.
I can only *guess* what happens with your example:
1. When the close icon is pressed in the *primary* window, a WM_CLOSE is
issued.
2. Win32Lib runs whatever onClose code there is, and then runs
DefWindowProc, which issues WM_DESTROY.
3. Since WM_DESTROY was issued to the primary window, PostQuitMessage is
called to shut down the application.
4. PostQuitMessage causes WinMain to fall out if the message loop, and
destroy all resources.
5. onload_MainWindow() is called, which does goodness knows what. I'll go
out on a limb and guess that it calls openWindow, which reloads the main
window. It then falls out of onload_MainWindow() and does...
...I haven't the foggiest notion *what* it does. In theory, it's finished
running the code, so Euphoria should shut down at this point. But pressing
the close icon again *should* shut down the application, since there's
nothing to fall through to.
I have no idea *why* (or if) your example works. As far as I can tell, it
relies on a side effect which might go away in some future version.
In my mind, the optimal action would be to explicit with something like
cancelDefaultAction(). Sure, it's opaque (and the name is awful) - but it's
a more general solution, and the user has a better chance on figuring out
why that particular line is there, and what it might do.
-- David Cuny
|
Not Categorized, Please Help
|
|
