This is sort of in the same spirit as our previous exercise in writing a timed message box, but this is much easier. Here, we use the handy-dandy message to get us out of menu mode. Before displaying the menu, we set a timer. (And we use a thread timer because we don't own the window and therefore don't know what timer IDs are safe to use.)...
A few days ago, we saw a simple version of a timed message box which had a limitation that it could be used from only one thread at a time. Today we'll work to remove that limitation. As you may recall, the reason why it could be used from only one thread at a time was that we kept the "Did the message box time out?" flag in a global. To fix i...
The window manager provides a pointer-sized chunk of storage you can access via the constant. You pass it to the function and the function to read and write that value. Most of the time, all you need to attach to a window is a single pointer value anyway, so the free memory in is all you need. Note that this value, like the other window ext...
Sometimes you need a quick and dirty window and you don't want to go through all the hassle of registering a class for it. For example, you might need a window to do a brief snippet of DDE, or you just need a window to own a message box. To save yourself the trouble of registering a class for every single weenie thing you might need a window for...
As we noted at the end of part 3, now that you know the conventions surrounding the message you can put them to your advantage. The more robust you want the function to be, the more work you need to do. Here's the cheap version, based on the sample in the Knowledge Base, but with some additional bug fixes. This function acts just ...
Earlier we saw the importance of setting the right owner window for modal UI. It is also important, when manipulating a window, to respect its modality. For example, consider the program we ended up with last time, the one which calls the function to display a modal dialog. If we wanted to get that program to exit and sent a message to the mai...
Here is the very simple fix for the buggy program we presented last time. We have fixed the problem by passing the correct owner window for the modal UI. Since is modal, it disables the owner while the modal UI is being displayed, thereby preventing the user from destroying or changing the owner window's state when it is not expecting it. ...
If you decide to display some modal UI, it is important that you set the correct owner for that UI. If you fail to heed this rule, you will find yourself chasing some very strange bugs. Let's return to our scratch program and intentionally introduce a bug related to incorrect owner windows, so that we can see the consequences. Run this prog...
After our two quick introductions to modality, we're now going to dig in a little deeper. The trick with modality is that when you call a modal function, the responsibility of message dispatch is handled by that function rather than by your main program. Consequently, if you have customized your main program's message pump, those customizatio...
Last time, we saw an example of code that was UI-modal but not code-modal. The opposite is also true: You can have code-modality without UI-modality. In fact, this is far more common than the UI-modal-but-not-code-modal scenario. You encounter modal loops without a visible change in UI state when you drag the scroll bar thumb, drag the window capt...
