Jump to content

Capturing mouse events outside the client area


mje

Recommended Posts

I have an application that uses pairs mouse down/up events to control some external hardware. It works great, on a down event a start command is sent, and a stop command is sent when the mouse button is let go. The problem is if the up event is only received if the mouse button is released while the cursor is over the client area of the window. Is it possible to have LabVIEW capture the event if the cursor is outside the client area (say over the window border, or entirely outside of the window)?

It turns out that in this particular case I could do a work around by using value change events instead, but that might not always be possible so I'm wondering if there's any way of addressing the problem by continuing to use the up/down events?

Regards,

-michael

Link to comment

Neat, I completely overlooked those VIs. That could definitely do the job. Thanks, Mikael.

I still haven't found a way to receive the actual events though. I'm starting to think it's a general issue with how the operating system windowing model works, I'm not even sure if LabVIEW is sent the events by the OS if the cursor isn't over the window.

Link to comment

Yes, this would be very usefull to be able to have LV register for event happening outside of LV.

There is one instance when LV get you partial access to this during a Drag an Drop transaction. LabVIEW is able to detect when the user cancel the drag even when you are outside of the LV window. This is a very nice feature.

PJM

Link to comment

QUOTE (PJM_labview @ Jun 13 2008, 10:55 AM)

Yes, this would be very usefull to be able to have LV register for event happening outside of LV.

There is one instance when LV get you partial access to this during a Drag an Drop transaction. LabVIEW is able to detect when the user cancel the drag even when you are outside of the LV window. This is a very nice feature.

You can quickly write a nice little loop using those VIs that post user events with the relevant information to your main event processing loop. I've done it for various apps of my own.
Link to comment

QUOTE (Aristos Queue @ Jun 13 2008, 11:26 AM)

You can quickly write a nice little loop using those VIs that post user events with the relevant information to your main event processing loop. I've done it for various apps of my own.

I am assuming that you are talking about the input VIs. I also do stuff in a parallel loop posting user events, but this is very limited. Lets say for example that I want to access drag info start within explorer (Ex: A user is dragging a file from explorer to a LV path). Using the input VI you know that the user press mouse down and is moving, but this does not give you any info about the item that may be dragged (I say may, because you are not even sure they are actually dragging stuff). This is why it would be nice if LV could hooked up into OS events.

PJM

Link to comment

QUOTE (PJM_labview @ Jun 13 2008, 02:22 PM)

I am assuming that you are talking about the input VIs. I also do stuff in a parallel loop posting user events, but this is very limited. Lets say for example that I want to access drag info start within explorer (Ex: A user is dragging a file from explorer to a LV path). Using the input VI you know that the user press mouse down and is moving, but this does not give you any info about the item that may be dragged (I say may, because you are not even sure they are actually dragging stuff). This is why it would be nice if LV could hooked up into OS events.

PJM

First LabVIEW does not even get informed about user events that happen outside of it's own windows. There are some system events like shutdown, power management and such that get passed to all applcations but most other events like keyboard, mouse, etc. are only passed to the window that has currently the focus. That is an OS limitation and in fact a good one since otherwise user event handling would get SOOOOOOOOOO slow (and a misbehaving application could block the entire system from working properly).

That said one can register hooks in the form of C callback functions into the OS for particular types of events. They can be usually global but not always, or application specific. Windows is very clear about installing global event hooks: DON'T DO IT for released code and that would include LabVIEW. It's a sure way of degrading system performance and once every application would start doing it Windows would be sluggish to the point of uselessness (Some would argue that it is that already without global hooks).

So if you want such hooks you probably will have to bite the bullet and write some external code in C (and make sure to not include such code in production quality software).

Also it still wouldn't help for Drag & Drop. A target is only informed about a Drag & Drop operation at the moment of entering its window in a D&D transaction. This event can be used to query the available data formats and change the cursor to indicate acceptance or refusal of the D&D application. However this interface is rather complex to use and that is probably the reason why external D&D support hasn't yet been integrated into LabVIEW D&D. I'm sure there are myriads of difficulties and complexies that make offering this interface in LabVIEW very hard to make user friendly (I mean here LabVIEW programmer friendly).

To make things worse, D&D is implemented using COM and not routed through the Windows message queue.

Rolf Kalbermatter

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