John Lokanis Posted January 16, 2013 Report Share Posted January 16, 2013 Ok, first, I don't even know if this is possible. I have been messing with it for a few hours and have hit a brick wall. I hope someone knows a trick or two to help me make this work. Here is what I am trying to do: When a user drags on a row of a MCLB, I want to dynamically open a VI under the user's cursor (their mouse button is still down) with 50% transparency and allow them to continue to move the mouse to drag the new VI's front panel to someplace on the screen and then release the mouse button. At that point, the transparency will return to 100% and the window will act normally until they close it. The goal here is to allow them to access additional data that is related to the row they dragged on. The problem: Opening the VI a the location of the cursor when the drag starts is not a problem. But getting it to track the mouse until the button is released is not working for me. I cannot find any way to do this within the methods that LabVIEW offers. Perhaps there is a .NET or Win32 solution? thanks for any ideas (or for telling me what I want to do is impossible). I will post a solution here if I get it working. -John Quote Link to comment
mje Posted January 16, 2013 Report Share Posted January 16, 2013 Is it the drag event that's mucking things up? I do this all the time for tracking movements on graphs, but admittedly there's no native drag event happening. During mouse movement I shuttle data (including position) off to async floating window tasks depending on contexts such as near data, out of bounds, or mouse button state. However admittedly I rolled my own drag logic because the native one didn't suit my needs- not even sure if the graph controls support it? Quote Link to comment
mje Posted January 16, 2013 Report Share Posted January 16, 2013 Darn, a quick test shows indeed, the native drag events interfere with mouse tracking. Hmm... context drag.zip Quote Link to comment
fabric Posted January 16, 2013 Report Share Posted January 16, 2013 I have done something similar using win API calls: Use event structure (with timeout = -1) to detect the original click on the thing you want to drag When a Mouse down is detected then store the starting position and toggle the event timeout to ~10ms In the Timeout case of the event structure, do two things: Poll the mouse button (e.g. user32:GetAsyncKeyState) to know when drag has ended Manually move the floating panel into position (I use user32:SetWindowPos) When mouse button is released then reset timeout back to -1 Quote Link to comment
Yair Posted January 16, 2013 Report Share Posted January 16, 2013 You can also minimize some OS dependence by using the input VIs to poll the mouse location and button and use VI server properties to control the position of window. Quote Link to comment
Popular Post hooovahh Posted January 16, 2013 Popular Post Report Share Posted January 16, 2013 (edited) Okay I think I got it. Attached is a main and graph VI saved in 2011. The main can launch a new graph because it is reentrant. You can create a new graph window by clicking a boolean, or by dragging an item from the multi column listbox. Closing or stopping the main will cause all of the reentrant graph VIs to stop. If you created a new graph using the MCLB it will follow the mouse movement (with 50% transparency) until the mouse button is released. I used a few tips that fabric mentioned, but I did it using only native LabVIEW code, no Windows DLL calls, just the mouse VIs, and the VI property nodes. MCLB Drag Reentrant.zip Edited January 16, 2013 by hooovahh 3 Quote Link to comment
mje Posted January 16, 2013 Report Share Posted January 16, 2013 Nice. It's too bad there doesn't seem to be enough events exposed to stay away from polling, but I'd take working over not any day Quote Link to comment
hooovahh Posted January 16, 2013 Report Share Posted January 16, 2013 Nice. It's too bad there doesn't seem to be enough events exposed to stay away from polling, but I'd take working over not any day Well if we wanted to get tricky I think it could be hidden a little more. We could use the Windows Message Queue library. You could register for mouse movement, and then use that to fire user events. I don't know if you can register for a message that isn't tied to a HWnd, so now that I'm thinking about it I don't know if that would work. But even so I don't think it's that big of a deal. Sure you are polling but only while the object is being dropped. So this will likely happen relatively quickly. Quote Link to comment
JackDunaway Posted January 16, 2013 Report Share Posted January 16, 2013 Okay I think I got it. Nice! Your concept tracks refreshingly smoothly for a native LV solution! By the way, another great example of this concept is XTab by SAPHIR. Olivier created an impressive video to demonstrate (the embedded video is currently broken on that site; here's a direct link to the video: http://www.dailymotion.com/swf/xksiht -- the part you're interested in starts around 0min:38sec) 1 Quote Link to comment
hooovahh Posted January 16, 2013 Report Share Posted January 16, 2013 Yes I've seen this demo, and have played with the XControl too. A few things I don't like about it (but have never mentioned to the author) is the fact that you don't have control over allowing the user to close a tab or not. If I'm using this with subpanels, there is a use case where I load a non-reentrant VI into the subpanel and may not want the user to close it. Also I think it would be nice to be able to have control over what happens when a window is closed. Should it pop back in or close? Quote Link to comment
JackDunaway Posted January 16, 2013 Report Share Posted January 16, 2013 Yes I've seen this demo, and have played with the XControl too. A few things I don't like about it (but have never mentioned to the author) is the fact that you don't have control over allowing the user to close a tab or not. If I'm using this with subpanels, there is a use case where I load a non-reentrant VI into the subpanel and may not want the user to close it. Also I think it would be nice to be able to have control over what happens when a window is closed. Should it pop back in or close? Me too!! But in the spirit of not hijacking this thread, perhaps let's continue discussion on the XTab thread to help both OP and Olivier Quote Link to comment
John Lokanis Posted January 16, 2013 Author Report Share Posted January 16, 2013 Thanks for the ideas guys! I have put together my solution pulling from all of them. I decided to make the child window deal with the mouse tracking instead of the parent. So, once it it created, it is on it's own. Seemed simpler this way and frees up the parent to do other things. I tried to eliminate all polling by using the mouse enter and leave events but a fast mouse movement could still mess things up so I added the timeout polling to make it smoother overall. The target for this code will have the child subscribe to the same message stream that the parent uses to update each row of the MCLB, but with more details displayed. Should make for a nice UI. Drag to Snap off Window.zip Quote Link to comment
Val Brown Posted January 17, 2013 Report Share Posted January 17, 2013 Can you save this for 2011? Quote Link to comment
John Lokanis Posted January 18, 2013 Author Report Share Posted January 18, 2013 Saved for 2011: Drag to Snap off Window 2011.zip Quote Link to comment
Val Brown Posted January 19, 2013 Report Share Posted January 19, 2013 Saved for 2011:Drag to Snap off Window 2011.zip Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.