I checked previous versions and this does not occur in LabVIEW 8.0 or 7.1. When you click on a ring or enum a popup list appears that you can select from. As soon as you enter this area with the mouse (sometimes this is instantaneous) the VI Mouse Leave event fires, as long as it is registered for of course. This applies to combo boxes and picture rings as well.



CAR ID #4C2ANAK8

David

Confirmed here on LabVIEW 8.2.1.

On that note, it sure would be nice if enums would fire an event when the user hovers over each selection item...

This only support my theory that LabVIEW FP object are getting converted over to XControls.

So if I wanted to implement an enum drop down, I could fire an event on mouse down and then show a floating picture control to present the list. In that case, I'd expect to see the mouse leave when I go to the picture control. An if I used the picture control as I mentioned, I could use the "mouse Move" to fire events and change the selection highlighting.

Wouldn't it be just grand if NI opened up the library of all of their XControls?

Ben

No. What it should support is a theory that drop boxes are implemented as hovering windows -- just as they are in every other app environment that I know of. The VI Mouse Leave event is correct in that respect ... the mouse is now over a different window. I believe you'll get the same thing with popup menus.


I think we have. When XControls were new in 8.0, there were zero in the palettes and (to the best of my knowledge) that was because none of NIs controls were XControls. I think that remains true for all the core LabVIEW controls. XControls have started showing up in some of the modules and toolkits, but all the ones I've seen are wide open (no password protection).

The popup is 'part' of the control that is on that VI front panel. No matter how it is implemented it should not state that you left the VI's front panel. This is new behavior with LabVIEW 8.2 as well.

The drop box can actually over hang the edge and/or bottom of the window (and it can over hang the top of the window in the case of a very large drop menu). That's why it is implemented as a separate window -- it is actually a different window. You have left the front panel any time you are over these components. You get a VI Window Leave because the operating system has a VI Window Leave.

I am very surprised to hear that this is new in 8.2. Very surprised because the implementation of the rings/enums has been this (again, to the best of my knowledge) for as long as there have been rings and enums. I would expect this behavior to go back to 6.1 (the introduction of the event structure). The fact that it doesn't replicate says to me that someone fixed a bug. Probably we weren't detecting other cases where we had left the window, leading to various bugs in other VI use cases (such as someone implementing custom popup menus or somesuch by creating temporary windows).

Looking back it seems like this could easily have caused a Mouse Leave event in other versions. But I hope that this special case was handled especially. And thus hopefully something broke in 8.2 which means it will be fixed in a future version. Because I see no real use for getting that event for entering a control's popup selection area.

In fact, for LabVIEW 7.1 at least, if you clicked on a ring and then left the VI front panel completely you didn't get a Mouse Leave event. I assume that what really changed is that when a ring was clicked on, further mouse events went to whatever was showing the popup. Now in 8.2 the events are being routed back to the owning VI. So maybe you just need to filter what events are sent.

Hi all,

For some history on what has changed regarding mouse enter / leave, see the bottom of this post. It's some information about how we implement the mouse enter / leave in Windows.

What Aristos and others have pointed out is accurate -- namely that the ring's menu is displayed in a separate window. The material below explains that there have been changes in how LabVIEW detects and reports mouse enter and leave events. We attempt to maintain correct behaviors and fix incorrect ones. I believe the change in behavior pointed out here falls into more of an 'undefined' area -- or perhaps more accurately put, an area open to interpretation.

There are two ways to interpret what 'mouse enter' and 'mouse leave' mean: literal and conceptual.

In the literal sense, any time the mouse cursor moves out of what the operating system considers to be a window, a 'mouse leave' event should occur. This means that, in Windows, moving the mouse over a windowed ActiveX control in your VI's panel should generate a 'mouse leave' event. It also means that when the mouse moves into a popup menu, it should generate a mouse leave.

In the conceptual sense, we have the notion of the panel, and suggest that the mouse enter / leave pertains to the panel as a whole, not elements within it. This is in conflict with that the operating system reports, and is a more subtle and difficult problem than one may initially believe. Thus, the info presnted in the material below -- namely, we took measures to NOT use the literal interpretation of leave panel as it pertains to ActiveX controls and some other situations, e.g. tip strips.

In the case of a popup menu, we're in a bit of a quandary. When you click the control to get the popup menu, the menu 'grabs' the mouse, and all mouse input is directed to the menu as long as it's on the screen. Mouse move events, mouse click events, etc. are NOT going to that VI panel. For all practical purposes, the mouse has 'left' the panel, because it cannot (and does not) provide any input events to it, down to the OS level.

The behavior in 8.2 is more correct considering where the mouse events are directed. I do not consider it wrong. One could, for example, fashion a custom 'popup' VI to be invoked on clicking a control that, to the user, looks and behaves exactly the same as a popup menu. From the perspective of the OS events, these are also indistinguishable. Obviously, in the case of the popup VI, you would, as the implementor, expect the mouse leave to happen, since the mouse entered another VI window (the popup VI).

I hope this clarifies why things behave the way they do.

===============================================================
Background:

There were two main problems with the WM_MOUSELEAVE event:

1) Not Entirely Reliable: When users move the mouse very rapidly, sometimes the event does not arrive. User input is posted asynchronously by the OS to the window, and we noticed that this event did not always arrive reliably from the OS. So, we could get cases where we *should* have gotten a WM_MOUSELEAVE, but we never did.
2) Child Windows: When a child window (like an ActiveX control) is present, we receive a WM_MOUSELEAVE when the mouse enters the child window of the VI panel. From the OS's point of view, this is perfectly legitimate. For our purposes, and the expectations of our users writing diagrams with the event structure, this does not constitute a 'mouse leave' event. The cursor is still in the bounds of the front panel. If you roll the mouse over a LabVIEW string control, you don't get a 'mouse leave' for the panel, so why should you get one if you roll over a Rich Text ActiveX control? (It also breaks tip strips for those controls, as I mentioned in my previous post.)

We tried to solve this by doing additional work when getting a WM_MOUSELEAVE to see if we *really* were leaving our window by crawling up the window parent chain after getting the window from the current mouse position, but this wasn't practical.

I'll now describe the scenario that ultimately brought us to using the timer. Consider when you have a windowed control that's partially off the edge of the parent window. The WM_MOUSELEAVE is sent to the VI window when the cursor enters the child window. If you then move the mouse off the edge of the window, the parent window (the VI) will never know that the mouse left it. I'll try to illustrate below. The mouse path follows the ***.

------------------
| VI Window |
------------------
| |
| |----------|
| | ActiveX |
| | |
| *****************-->>
| | |
------------------

In this case, when the cursor enters 'ActiveX' the 'VI Window' will get a WM_MOUSELEAVE . Then, mouse input goes to the ActiveX control. If we interfere with this, the ActiveX control will not work properly*. So once the cursor enters the ActiveX control, the ActiveX control receives the mouse events. When the mouse then exits the ActiveX control, it "really" left the VI window, too, but the VI window never receives another WM_MOUSELEAVE -- the ActiveX control does.

Also, because you can create VIs with or without title bars, borders, etc. this problem is not generally solvable solely using WM_MOUSELEAVE along with WM_NCMOUSELEAVE -- i.e. LabVIEW cannot rely on there being a border / title bar (non-client area). We let you create VIs without those features!

So, as you can see, the problem has many subtleties. When you throw two other operating system user interfaces into the mix (XWindows and MacOS), striving for a consistent experience on the block diagram in some areas proves to be quite challenging.

Hope this helps!

*You may notice that when you're editing a VI with an ActiveX control in it, you can pop up on the ActiveX control and you get a LabVIEW menu. So, we do, to some extent, 'interfere' with normal event processing for ActiveX controls. However, 'design time' and 'run time' distinctions are another huge complication in working with ActiveX controls in LabVIEW. That's another topic altogether, with many years' worth of work behind it. 8-)

This post has been edited by intvsteve: Aug 3 2007, 03:39 PM

Thank you very much for such a detailed explanation. I'll start digesting it.

A CAR has been filed on the issue for further investigation by LabVIEW R&D team under CAR ID #4C2ANAK8