Help de-activating system menu in window
-
I've got a problem. Our software processes some messages in a CPropertySheet derived main window class. When a user presses "ALT" key, the system menu is activated, same thing when user click on the top left window icon, the system menu drops down. At this stage, when menu is active/down, the window doesn't process any incoming messages. I have written a separate thread that sends heartbeats to check if this state happens and now want to do somthing to de-activate the menu automatically wthout user intervention. How? I know that if I click somewhere in the window with the mouse, it de-activates the menu and messages gets processed again. (Assume this software is run 24 hours a day and operator forgets to check it. By accident an operator press ALT and leaves. Now I want to detect this and fix the state to normal)
-
I've got a problem. Our software processes some messages in a CPropertySheet derived main window class. When a user presses "ALT" key, the system menu is activated, same thing when user click on the top left window icon, the system menu drops down. At this stage, when menu is active/down, the window doesn't process any incoming messages. I have written a separate thread that sends heartbeats to check if this state happens and now want to do somthing to de-activate the menu automatically wthout user intervention. How? I know that if I click somewhere in the window with the mouse, it de-activates the menu and messages gets processed again. (Assume this software is run 24 hours a day and operator forgets to check it. By accident an operator press ALT and leaves. Now I want to detect this and fix the state to normal)
IMHO, stuff that needs to be running 24h a day shouldn't be in a UI thread at all. (It probably shouldn't even be in a process that has a UI thread, but in a service.) So put that stuff in a background thread and leave the UI thread to do UI processing only. If you can't because the messages you need to process are real windows messages (and you can't change that), process them with a different, hidden window -- which you could put in a different UI thread, though I'm not sure that's necessary. If you take the approach that you want to detect a stalled situation and terminate it, you have to make sure you identify all possible stall situations ahead of time. You've identified one already, and even if there aren't any others now, you or someone else might add one in the future. By using a different thread and/or window, you're more likely to be able to handle all possible stall situations without failing to process the incoming messages. The UI will get out of sync with data perhaps, but the messages will still be processed.
-
IMHO, stuff that needs to be running 24h a day shouldn't be in a UI thread at all. (It probably shouldn't even be in a process that has a UI thread, but in a service.) So put that stuff in a background thread and leave the UI thread to do UI processing only. If you can't because the messages you need to process are real windows messages (and you can't change that), process them with a different, hidden window -- which you could put in a different UI thread, though I'm not sure that's necessary. If you take the approach that you want to detect a stalled situation and terminate it, you have to make sure you identify all possible stall situations ahead of time. You've identified one already, and even if there aren't any others now, you or someone else might add one in the future. By using a different thread and/or window, you're more likely to be able to handle all possible stall situations without failing to process the incoming messages. The UI will get out of sync with data perhaps, but the messages will still be processed.
You are right and I agree. However, the code is 6 years old and very complex (read bad). I was just hoping someone had a solution so I won't have to re-write all this code, also risking introducing bugs. Oh, well, off we go...