popupmenu, GPF

[Chris Holbrook]

I forgot that a popupmenu can yield a result of 0, and of course used the result to look up a table (that's the short version of the story). But what I didn't know, and rather surprised me, was that the same result occurs when you task-switch out of a popupmenu, or close the application which it's working for. So I wondered at what point the application code stops being executed, and it looks like it is back in the message loop (dialog callback function in my case). So the popupmenu looks like a window, in fact it has to be a window, but it (presumably) doesn't respond to WM_SYSCOMMAND messages. Am I thinking on the right lines here?

[Michael Mattias]

So I wondered at what point the application code stops being executed, and it looks like it is back in the message loop (dialog callback function in my case)

Well, message loop and your callback functions are two different things.

Your code enters the message loop when you exit the callback function and the underlying dialog procedure. Your dialog procedure is entered when some event worthy of notification (worthy as determined by the operating system) occurs and that notification is sent.

What you may be missing here is when you task-switch, Windows sends your dialog WM_ACTIVATE and WM_NCACTIVATE notifications, which, if you don't do anything with it is processed by that default procedure... which "apparently" 'un-displays' any currently popped-up menu. (Hmm, according to the doc for WM_NCACTIVATE, that's exactly what it does).

But with everything being re-entrant, I don't see why there could not be multiple simultaneous invocations of your dialog procedure. Is it possible you were using non-stack-based (GLOBAL, STATIC or THREADED) variables here? That could be a source of problems.

MCM

[Chris Holbrook]

Well, message loop and your callback functions are two different things.

OK, "message process including my callback function".

What got me is that the menu window (and it has to be a window) appears to respond to these messages by just returning zero, and does not, like other child windows of the dialog which is being closed (for example), close itself, so it is working partly in a modeless way (not closing) and partly in a modal way (responding to the parent being closed). Thinking more about it, that is not too much of a problem, but it does need to be taken into consideration when processing the result from the menu, which is what I - and maybe countless other fools - did in the first place.

What you may be missing here is when you task-switch, Windows sends your dialog WM_ACTIVATE and WM_NCACTIVATE notifications, which, if you don't do anything with it is processed by that default procedure... which "apparently" 'un-displays' any currently popped-up menu. (Hmm, according to the doc for WM_NCACTIVATE, that's exactly what it does).

don't mistake me for one of these people who does nothing until he has read the manual. I'm for learning by experience, me. Though I still miss the other fingers...

[Edwin Knoppert]

>don't mistake me for one of these people who does nothing until he has read the manual. I'm for learning by experience, me.

One of my frustrations..

If you are doing learning from experiance, fine.. but the MSDN or win32 api help file is a technical doc.
When you are using a message or api and so on, you should at least read the in and out of its behaviour.

I often point people to use some windows message or api and i expect them to look it up.
If they don't want to read at least that... good luck.

[Chris Holbrook]

...good luck.

Sorry Edwin just my little joke which I was sure MCM would appreciate.

[Edwin Knoppert]

Oh.

[Michael Mattias]

>I forgot that a popupmenu can yield a result of 0,

Are you using TrackPopupMenu[Ex]? It this for a popup for a tray notification icon, where the rules for that are different and the 'task-swtich' issue workaround is right in the API documentation?

Wait a minute, you must be using TrackPopupMenu.. regular menus don't return anything, they only notify the parent, unless you are talking about one of the menu management functions which do return soemthing, but those don't use messages, they use regular function calls.

Bottom line is, "show offending code."