Question about Event Structure Behaviour

[Will.D]

Hey guys,

I'm having difficulty understanding some event structure behaviour.  I was having a similar problem a few months ago (here), which was resolved by Christian.  This is VERY much in the same vien as that, but has a different twist. 

Run the attached vi (8.2).  If you move the "Value Change" scrollbar (by clicking on the arrows, not by dragging the bar), sometimes more than one event fires per value change.  I included a "Mouse Down" which if you play with the scrollbar the same way as mentioned above, functions as I thought the value change would function.

I can't figure out why more than one event fires.  In my previous problem linked above, there was an understandable race condition since I was using a Value(Signaling) property node.  This time it's just the control.

I expect this is going to make me look dumb, but we'll see.

Thanks!

[Evan]

Ok it took me a little to figure this out, but what is happening is that you are geting mutliple valid Value Change events, and they are all valid.

Click and hold down on the arrow and notice that you it will start changing the value a ton.  This is what we expect the scrollbar to do.  The mouse down one shows the same behavior.

Well when you simply click on the Scrollbar there is a timing issue.  How fast of a clicker are you?  If you click real fast: 1 change.  If your click is a little slower: 2 changes.

[Matt_W1]

I'd guess it's from holding down the mouse button a little too long. If you hold down the mouse button the scroll bar continuely updates (and there's not much of a delay if any between the initial click and when it starts repeating). It's kinda like when you hold down a key on your keyboard and it starts repeating the same letter.

[jpeters]

I think that this might be a bug with the scrollbar control but I am not 100% certain at this point.  This was reported to R&D (#43EEUKGQ) for further investigation.

I am not sure what you are trying to do, but it seems like a potential workaround is to do nothing if the value didn't really change.  Note: we will sometimes fire value change events even if the value doesn't change; this is not a bug in itself.  Take, for example the Value Signalling property... that will always fire a value change event.

Jeff Peters

LabVIEW R & D

[Will.D]

Thanks to all for your replies.

As far as holding the mouse down too long goes, should that even matter?  I guess as far as what I understand about the "value change" event to be, it is to be fired when the value changes.  I understand that the "value signaling" fires an event no matter what, but that follows what I'm trying to say.  Yes the property is written to, but why does a value change event fire even if the value doesn't change?  Does that not contradict the very definition of the event?

I do appreciate all dialog on this, I'm just trying to get a better understanding of how/why this all works. 

Thanks again

[Evan]

In my opinion as you are holding it down the value is changing.  There is really no difference between grabbing the scrollbar and draging it or holding the mouse down on the arrow.  Both actions cause the scrollbar to change values as it travels in what ever direction.

If the holding down only counted as 1 value change which one would it be.  For example in the web navigator I have a scrollbar on the right.  If I click and drag it around it constantly moves the age like we all expect.  Therefore it changed values like we expect.  Now if I click and hold on the arrow it also changes the page while I am holding.  If it only changed the value once then 1 of 2 things would happen.  1. The page would move a little, and it would not matter how long you held it that would do nothing.  2.  The page would not change until i actually mouse uped and then the entire page would snap to the final value I choose.

For me it makes sense that I should get all the value changes, and I have used that in a bunch of applications where I wanted to mimic a scrollbar moving a page.

[jpeters]

In my opinion as you are holding it down the value is changing.  There is really no difference between grabbing the scrollbar and draging it or holding the mouse down on the arrow.  Both actions cause the scrollbar to change values as it travels in what ever direction.

I agree... and this is what the scrollbar is supposed to do.  The reason that I reported it as a bug is because it seems like I was getting more value change events then there were actual operations.

For example, lets say that while holding the arrow the value is supposed to change every 10 ms, and I hold it for 30 ms.  You would expect 3 value change events, but in this case it seems like you sometimes get 4.  At this point, I don't know why you get this extra value change -- and so I want to investigate it.

Again, it is not necessarily a bug that you get value change events when the value doesn't change, but in this case, something smells fishy, possibly a value change on mouse up or something.

Jeff Peters

LabVIEW R & D

[Will.D]

"For example, lets say that while holding the arrow the value is supposed to change every 10 ms, and I hold it for 30 ms.  You would expect 3 value change events, but in this case it seems like you sometimes get 4.  At this point, I don't know why you get this extra value change -- and so I want to investigate it."

This is what I was trying to get at, sorry for not being more clear.  I do think that if you hold the mouse button down you should get more than one value change, as the value should change at regular intervals, much like the key repeat as was mentioned above.  That makes sense and I agree with both Evan and Jeff's comments.

It was the extra event in the vi that concerned me.  An event fired without the value having changed.  That is the part that I did not understand.  In the vi I posted, the number of events fired does not correspond exactly to the number of value changes in the "Value Change" example if you play with it. 

[Evan]

Ok I think I see what you are talking about... but I am not sure.  Is the issue that as you scroll around sometimes the Old and New value are equal.  Therefore the value didn't change?  If I hold the arrow down just long enough to get the 2 value changes to fire I noticed that the results are (old and new value)  0 and 1 then 1 and 1.  So the second value change never actually changed or one of the values isn't reported correctly.

[tst]

And while we're talking about continuous events, how about adding an option to events like mouse move that will allow us to limit the number of events?
For instance, fire an event only every 30 pixels or every 100 ms or fire a final event when the mouse hasn't moved for 200 ms.
Doing the first part in the code is relatively simple, but the end of the movement is more complex.