PJM_labview Posted August 20, 2009 Report Share Posted August 20, 2009 This has been tested on LabVIEW 2009: If you run the attached VI you will see that the scrolling will stop even tough you did not "mouse up". If you remove the mouse move event, everything is back to normal. Somehow the mouse move event is interfering with the scrolling. <object width="886" height="530"> <param name="movie" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/jingswfplayer.swf"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/jingswfplayer.swf"></param> <param name="quality" value="high"></param> <param name="bgcolor" value="#FFFFFF"></param> <param name="flashVars" value="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/FirstFrame.jpg&containerwidth=886&containerheight=530&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/2009-08-20_1533.swf"></param> <param name="allowFullScreen" value="true"></param> <param name="scale" value="showall"></param> <param name="allowScriptAccess" value="always"></param> <param name="base" value="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/"></param>'>http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/"></param> <embed src="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/jingswfplayer.swf" quality="high" bgcolor="#FFFFFF" width="886" height="530" type="application/x-shockwave-flash" allowScriptAccess="always" flashVars="thumb=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/FirstFrame.jpg&containerwidth=886&containerheight=530&loaderstyle=jing&content=http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/2009-08-20_1533.swf" allowFullScreen="true" base="http://content.screencast.com/users/PJM_LabVIEW/folders/Jing/media/01db0d71-dee8-4cff-89e4-753c60f812f2/" scale="showall"></embed> </object> Note: while this does not seem that bad in the video above, in some situation it is so bad that it becomes very difficult to scroll. mouse move scroll bug.vi PJM 1 Quote Link to comment
Mads Posted August 21, 2009 Report Share Posted August 21, 2009 This goes for all similar events - like the cursor move event, or the window resize event e.g. - the GUI will be affected by how quick the event is handled. This is why I typically just set a flag in the event case and then do the processing of the event somewhere else. The ideal solution would be to be able to set the event structure to have a lossy buffer..i.e. it should only keep the latest unprocessed instance of the event, not stack them up. (It has been proposed on the Idea Exchange already). 1 Quote Link to comment
Daklu Posted August 21, 2009 Report Share Posted August 21, 2009 This goes for all similar events - like the cursor move event, or the window resize event e.g. - the GUI will be affected by how quick the event is handled. This is why I typically just set a flag in the event case and then do the processing of the event somewhere else. I agree. A 50 ms process in an event case is a long time. The ideal solution would be to be able to set the event structure to have a lossy buffer..i.e. it should only keep the latest unprocessed instance of the event, not stack them up. Hmm... I think there are significant problems with this idea. Discarding events based on whether or not that event is already in the queue is a bad idea because it depends in part on the number of events in the queue, which the programmer has no control over. This would make for very unpredictable behavior. Furthermore, if you keep only the most recent instance of the event it might never get processed because new events go to the back of the queue. Discarding new duplicate events and keeping the original could be useful in certain circumstances, but it is easy enough to implement using a notifier to trigger an event processor. If anything a 'no duplicate queue' would be better implemented as a downloadable reference design rather than an addition to current event structure. Quote Link to comment
PJM_labview Posted August 21, 2009 Author Report Share Posted August 21, 2009 I agree. A 50 ms process in an event case is a long time. The 50 ms is there so people can easily replicate the bug. I discover this issue with an operation that is way faster (where I have built in smart to not do unnecessary computation). The funny thing with this bug is that every so often you grab the scroll bar and everything works great for as long as you keep moving is around (there is basically no way to make it fail). This is why I think there is some sort of issue that goes beyond the obvious (which is to limit what to do in this event frame). PJM Quote Link to comment
Daklu Posted August 21, 2009 Report Share Posted August 21, 2009 Okay, I believe you. I played around with your vi a bit and threw up some booleans to indicate various mouse events. I noticed a few things: No MouseUp events are firing on the array, tab, or pane, even though the behavior makes it look like it is. It doesn't have to be a Tab.MouseMove event. It will also halt on Pane.MouseMove or Array.MouseMove events, as long as those events are being fired. If you move the mouse cursor off the control that is triggering the MouseMove event it won't halt and you can keep scrolling. If you click and hold on the scrollbar (not on the handle) and move the mouse (keeping it inside the scrollbar edges) while the handle is scrolling, it will halt. Not much help, but at least you're not going crazy. Quote Link to comment
Mads Posted August 21, 2009 Report Share Posted August 21, 2009 With the events I mentioned - cursor move, window resize etc. you do not need any of the intermediate events, the really important event is the latest - that is the event that tells you where the cursor was moved last, how large thw window is now etc...and previous positions/sizes are of much less interest....so I do not understand why you see significant problems...after all this would only be a setting that you could active for the events it is suitable for. I agree. A 50 ms process in an event case is a long time. Hmm... I think there are significant problems with this idea. Discarding events based on whether or not that event is already in the queue is a bad idea because it depends in part on the number of events in the queue, which the programmer has no control over. This would make for very unpredictable behavior. Furthermore, if you keep only the most recent instance of the event it might never get processed because new events go to the back of the queue. Discarding new duplicate events and keeping the original could be useful in certain circumstances, but it is easy enough to implement using a notifier to trigger an event processor. If anything a 'no duplicate queue' would be better implemented as a downloadable reference design rather than an addition to current event structure. 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.