Mouse Hover Through ?

[cippyboy]

Hi,

I was wondering if a property similar to MouseClickThrough would exist for hover states ? I'm setting MouseClickThrough to a window but the window underneath loses the hover state image although the callbacks related to entering and leaving the hover state work accordingly.

[CrazyEddie]

If you mean MousePassThrough (since there is no MouseClickThrough), then this already passes the mouse movement events to the 'correct' window (as evidenced by the fact you're getting related events firing), which means that your issue must be caused by something else you are or are not doing... If you can post a little more info about what you're doing, how you're doing and the results you're looking for, hopefully someone will be able to assist

CE.

[cippyboy]

Here's a sample

[img=http://img146.imageshack.us/img146/3928/guiissue.th.jpg]

Every square widget (in the red rectangle) has a hover enter/leave function attached that shows and hides the anexed hover frame (in blue, it has an extra arrow attached outside of it, with ClippedByParent turned to false). Initially I made the hover frame static but, whenever the cursor gets into the arrow widget which is a child of the hover window, the square widget with the item stops having the blue hover frame it has in the pic, but when I leave it's surface, the hover frame gets hidden, the leave hover gets processed, but the button doesn't have the hover image on it at all times. Anyway, we found a fix, to move the hover frame so that the cursor will never step on that arrow and create issues .

Previous to that fix I also tried attaching an enter hover callback to the hover frame so that if I step on it by accident, to get hidden, but to my surprise that state wasn't triggered (without enabling MousePassThrough).

[CrazyEddie]

Say what?!

All joking aside, I'm glad you found a suitable work-around. It's true that some of the mouse entered mouse leaves events do not do what some people expect (such as entering a child widget within the bounds of it's parent - the parent gets the mouse leaves notification, and the child gets the mouse enters notification - some people say that this is incorrect since the mouse has not left the area of the parent window, however I believe we're not the only UI that does it this way), though I would have thought it should be fine if the hover window and the arrow child bother had pass through enabled, having said that, I've not tested anything like that, so who knows

CE.

[cippyboy]

Actually, you gave me an idea. I did have "pass through" on the hover frame but not on the arrow (I thought it should get the property through inheritance since it should be considered a surface from the parent window, I guess that doesn't apply ?). If we're going back or something I'll try that (why bother if it works, right ? ).

By the way, as a side question : I have a default window covering the entire render window as the parameter to SetGuiSheet. On initial activation everytying works ok, but if I alt-tab the application and go back to it there's a strange behaviour going on : all windows receive hover messages, but when I try clicking stuff, the first click doesn't get processed, it only works on the second click. After this everything works from the first click, regardless of sub-window. So I'm thinking the main gui sheet gets deactivated but I attached a callback on the Window::EventDeactivated and I get no calls to that. How can I fix this ?

[CrazyEddie]

I have a default window covering the entire render window as the parameter to SetGuiSheet. On initial activation everytying works ok, but if I alt-tab the application and go back to it there's a strange behaviour going on : all windows receive hover messages, but when I try clicking stuff, the first click doesn't get processed, it only works on the second click. After this everything works from the first click, regardless of sub-window. So I'm thinking the main gui sheet gets deactivated but I attached a callback on the Window::EventDeactivated and I get no calls to that. How can I fix this ?

As far as I recall we do not do anything special when alt-tabbing away, and I'm unsure about the issue you're having; I will have to test it out for myself to see the behaviour and decide whether it's an issue. What you could try is the System::injectMouseLeaves function when you alt-tab away - not sure if it will help or not, but it's worth a try

CE.