How to detect if the containing popup window is deactivated?
-
Hello people. I have a tooltip-like system that shows up information in a popup window based on where the mouse cursor points. Works fine most of the time, but when there's a message box or other modal dialog popping up because of certain events hapening in the background, the tooltip windows just stays on the screen. I guess this is because once the parent window containing the control that has the tooltips is deactivated/disabled (because of the modal dialog), it no longer receives any mouse messages thus the "tooltip" will think that the mouse is still pointing at the given location (since there's no WM_MOUSEMOVE, no WM_MOUSELEAVE...). I used the usual mouse messages (WM_MOUSEMOVE, WM_LBUTTONDOWN...) along with TrackMouseEvent[^] to know when and what to show and hide. But i don't know how to handle the case when we no longer receive any mouse input. One way i guess would be to handle WM_ACTIVATE in the parent window and then channel the event towards the child that has the tooltips but this seems to be quite a non-portable and ugly solution. So anyone knows how to do this right?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world. Fry: But this is HDTV. It's got better resolution than the real world <
-
Hello people. I have a tooltip-like system that shows up information in a popup window based on where the mouse cursor points. Works fine most of the time, but when there's a message box or other modal dialog popping up because of certain events hapening in the background, the tooltip windows just stays on the screen. I guess this is because once the parent window containing the control that has the tooltips is deactivated/disabled (because of the modal dialog), it no longer receives any mouse messages thus the "tooltip" will think that the mouse is still pointing at the given location (since there's no WM_MOUSEMOVE, no WM_MOUSELEAVE...). I used the usual mouse messages (WM_MOUSEMOVE, WM_LBUTTONDOWN...) along with TrackMouseEvent[^] to know when and what to show and hide. But i don't know how to handle the case when we no longer receive any mouse input. One way i guess would be to handle WM_ACTIVATE in the parent window and then channel the event towards the child that has the tooltips but this seems to be quite a non-portable and ugly solution. So anyone knows how to do this right?
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world. Fry: But this is HDTV. It's got better resolution than the real world <
Hi there, So what about just intercepting the event of when that parent window gets de-activated because of the pop-up and force to tooltip to disappear ? You may thus look for WM_ACTIVATE event. Its handler gives a state parameter by which you know if your window is being activated or deactivated, and in the second case it can even give you the address of the "guilty" window (the popups in your case)
Push Framework - now released ! http://www.pushframework.com
-
Hi there, So what about just intercepting the event of when that parent window gets de-activated because of the pop-up and force to tooltip to disappear ? You may thus look for WM_ACTIVATE event. Its handler gives a state parameter by which you know if your window is being activated or deactivated, and in the second case it can even give you the address of the "guilty" window (the popups in your case)
Push Framework - now released ! http://www.pushframework.com
As i said, that is one option, it just seems a bit...ugly. Having to do that for every "parent" window everywhere you want to use this tooltip thing isn't convenient.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world. Fry: But this is HDTV. It's got better resolution than the real world <
-
As i said, that is one option, it just seems a bit...ugly. Having to do that for every "parent" window everywhere you want to use this tooltip thing isn't convenient.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world. Fry: But this is HDTV. It's got better resolution than the real world <
Sorry I looked to your message rapidly, not paying attentio,n to your last sentence. Well, I do'nt thiink it is too ugly. By the way, you are already calling your tooltip from within the parent frame, in order to achieve things like the tooltip fades away when mouse leaves the control area, no ? I honestly can't see something else. I had this pbm before with Pustovoy' tooltip when popus are triggered by hyperlinks on the tooltip themselves.
Push Framework - now released ! http://www.pushframework.com
-
Sorry I looked to your message rapidly, not paying attentio,n to your last sentence. Well, I do'nt thiink it is too ugly. By the way, you are already calling your tooltip from within the parent frame, in order to achieve things like the tooltip fades away when mouse leaves the control area, no ? I honestly can't see something else. I had this pbm before with Pustovoy' tooltip when popus are triggered by hyperlinks on the tooltip themselves.
Push Framework - now released ! http://www.pushframework.com
No, i use TrackMouseEvent[^] to detect when the mouse leaves. Guess i'll have to go with the activation "relaying" then. Thanks for your help.
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world. Fry: But this is HDTV. It's got better resolution than the real world <