Jump to content

Rings and Enums causes VI Mouse Leave event


JDave

Recommended Posts

I checked previous versions and this does not occur in LV 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.

http://forums.lavag.org/index.php?act=attach&type=post&id=6516

David

Link to comment

QUOTE(dsaunders @ Aug 1 2007, 04:51 PM)

I checked previous versions and this does not occur in LV 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.

Confirmed here on LV 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... :rolleyes:

Link to comment

QUOTE(orko @ Aug 2 2007, 11:00 AM)

Confirmed here on LV 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... :rolleyes:

This only support my theory that LV 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

Link to comment

QUOTE(Ben @ Aug 2 2007, 10:22 AM)

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.

QUOTE(Ben @ Aug 2 2007, 10:22 AM)

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

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).

Link to comment

QUOTE(Aristos Queue @ Aug 2 2007, 08:35 AM)

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 LV 8.2 as well.

Link to comment

QUOTE(dsaunders @ Aug 2 2007, 10:52 AM)

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 LV 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).

Link to comment

QUOTE(Aristos Queue @ Aug 2 2007, 09:02 AM)

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).

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 LV 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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.