1. Re: Win32LIb & Child Windows
Here's the scoop on child windows, as far as I understand it (which isn't
much):
[Closing Child Windows]
When you press the close button in a window, Windows issues a WM_CLOSE
message to the window to inform it that it is going to be closed. Windows
then removes the window from the screen, and issues a WM_DESTROY event to
the window, informing it that the window has been destroyed. This event is
then issued to all the child controls of that window.
Win32Lib doesn't support multiple windows (yet). So when it sees the
WM_DESTROY message, it runs the following bit of code:
-- close the app
c_proc( xPostQuitMessage, { wParam } )
This shuts down the *entire* application.
The problem is that Win32Lib executes this even if the window is *not* the
primary window. If you take a look in the event loop around line 4816, you
can see where I had code that used to test for the primary window, and calls
DestroyWindow instead.
If you want multiple windows to be handled, you probably can hack the code
to do the following:
1. If the window is the primary window ( = defaultWindow), shut down using
the PostQuitMessage routine.
2. If it's not the primary window, destroy the window with DestroyWindow,
and return a zero, indicating that the window was destroyed.
This is *not* an optimal solution. The problem is that the window is
destroyed, along with it's menu. If you want to re-display the window, there
will be problems.
Instead, I should be capturing the WM_CLOSE event, and *hiding* the window
that is being closed. That way, the window isn't really destroyed, and so it
can be popped up again.
This can *probably* be done by trapping the WM_CLOSE event, and issuing a
ShowWindow( hWnd, SW_HIDE ) event if the window is not the main window.
[Modal Windows]
As far as I can figure, Windows won't let me create a modal window. Modality
is reserved for dialogs, and Win32Lib can only *simulate* dialogs by
creating windows that look like dialogs.
So the best I can do is set an internal modal flag in Win32Lib, and detect
when one of the application's windows is getting focus. If it's not the
"modal" window, focus is re-directed to the "modal" window.
This seems less than optimal - the title bar flashes as focus is lost and
then re-directed - but I've seen the same defect in other Win32 programs, so
I guess I'm not the only one using the same hack.
Codewise, it shouldn't take too much code - creating a
modalGrab/modalRelease routine to set a variable, and a test in the
WM_SETFOCUS and WM_LOSEFOCUS in the WndProc routine... In theory. 
If I can get it running, I'll try to include this code in not-too-distant
release of Win32Lib. I'd really like to support multiple windows, and get on
to more interesting problems.
Hopefully, this answered more questions than it raised?
Thanks.
-- David Cuny
