How do you turn off an event?

[Dave123]

Hi,

I'm developing a LV prog for a psychology experiment to record a participants mouse movements as they draw/trace an object. I've attaced the main vi and the few sub vi's.

I've used an event loop to capture when the mouse moves within a picture indicator on the front panel. If the mouse button is down a "line_to" the current coordinates is performed, if the mouse button is up then a "move_to" is performed. At the same time the coordinates of every mouse move (button up and down) is added to an array and at the end output to a file for analysis.

I've included a 'Record' button which at the moment will only allow lines to be drawn if TRUE. I'd like this button to also enable/disable the recording of the mouse coordinates. What's the best way to do this, is it possible to turn off the 'mouse move' event?

Also, I'd like to limit the number of coordinates generated to say every 100ms (10 per sec). What's the best way to do this without slowing the drawing of the following trace down? I tried adding a wait(100) in the while loop but it seems that the events buffered and just as many points are drawn and recorded but are slow to appear on the screen.


Thanks,
Dave.

[smercurio_fc]

You can't really "turn off" events. Events are generated by the operating system when a user or application does something and get passed into the application. It's up to the application (i.e. you) to either deal with them or ignore them. In your case you want to ignore them if a certain condition is true. It seems you already have this condition: whether or not the "Record" is true. So, just use it to determine whether you should deal with the event. One way is to simply use the question mark version of the events, e.g., "Mouse Move?", to determine if you should just discard them. Add these events and if the "Record" is false, set the "Discard?" output to true. Then, you won't see the corresponding "Mouse Move" event. You can also use the "?" events to control your accumulation rate. The events have a "Time" property which tell you when the event happen. Compare this to the previous event's time and determine if you should process it.

Tips

• Usually a button like your "Load Picture" has its mechanical action set to "Latch When Released". Then, to handle the user clicking the button you handle the button's "Value Changed" event. You need to place the terminal inside the event case so the value gets read and the control's state is properly changed.
• You should create your cluster that you have at the bottom as a typedef and use "Bundle by Name". You don't have to create a typedef if you just label each constant that you create to build the cluster. This will give you the ability to self-document what you're changing without having to place that comment about the cluster elements wherever you're messing with the cluster.
  

[Dave123]

Hi, thanks for your reply.

Unfortunately for the picture indicator there doesn't seem to be a "Mouse Move?" event. The only "?" events given for the picture are:
1. Key Down?
2. Key Repeat?
3. Mouse Down?

I need to record any movement of the mouse within the picture not just when the mouse down occurs.

Thanks for the other tips, I was trying to find an easier way to label the members of the cluster.
Why does LV come with these other button mechanical actions (switch until released) and events (mouse down) unless they can be relied upon to work?

Thanks
Dave.

[Ben]

A quick read sounds like Tons Dynamic Event Registration Nugget may help.

Ben

[smercurio_fc]

Well I'll be... I had never noticed there was no "Mouse Move?" event for the picture control. The explanation I had given was meant to be a generic response, so I was just assumed there was a "Mouse Move?" event. Just goes to show you: always check first before crossing the road. Hummph.

Ben, I'm not sure that he really needs to go down that road given the level of complexity of that route. What he has will work with just a few tweaks. He should certainly consider the method given in the nugget as a future "enhancement" and for his own education.

I made a few tweaks to your VI to get you closer to your goal:

• You can access the "Mouse" property of the picture control and it provides the coordinates you need. This eliminates the need of the "Convert" VI.
• Labeled the constants on the cluster and used bundle/unbundle by name.
• Added case for accumulating the mouse move events by using shift register as I mentioned.
• Added the "Move Pen" in the Mouse Down event so drawing starts at that point. This means you shouldn't need the "Move Pen" in the "Mouse Move" event.
  
• Couldn't figure out what you were doing with the initial zoom calculation, so I just hard-wired a value of 1. You'll need to look at this.

Take a look to see if this is closer to what you were trying to do.

As for your comment regarding the button mechanical action: there's nothing inherently "unreliable" about the other mechanical actions. They do serve a purpose. However, if you notice that when you plop down one of those rectangular buttons, the mechanical action is defaulted to "Latch When Released". That's because you want the button to behave so that the user can click the mouse and hold it down over the button, but the button doesn't register a value change until the user lets go of the mouse while cursor is over the button. In this case it's intended to simulate a single-shot. The "Switch Until Released" means the state changes as soon as you click it, and it stays that way until you let go. The way you're using it the effect is the same, and there's nothing inherently "wrong" with it. It's just not the common way of doing it. If you prefer your method, and it work, then by all means use it.

[Dave123]

Hi, many thanks for your reply and program mods.

Sorry, I forgot to attache the loadJpeg.vi last time, I've included it this time.
The zoom factor calculations are used to scale the loaded jpeg. If the larger of the jpeg's two dimensions is smaller than the picture window (which is square) then it is scaled up but if larger then it is scaled down. This makes the loaded jpeg fill the picture window without overflowing. Hope that makes sense.

I see you made a modification in the mouse move event such that the current coordinate data is only added to the array if the event time is 100 greater than the previous event time. Looking at a generated results file there are few data points stored, certainly not ten per second. For example on result file shows times of:
X Y MouseDown Time
48 366 FALSE 22734045
112 231 TRUE 22734603 (difference = 558)
120 230 TRUE 22734805 (difference = 202)
411 231 TRUE 22736418 (difference = 1613)
438 337 TRUE 22737106 (difference = 688)
141 334 TRUE 22738129 (difference = 1023)
110 226 FALSE 22739394 (difference = 1265)
104 314 FALSE 22740028 (difference = 634)
125 327 FALSE 22740265 (difference = 237)
125 332 FALSE 22740541 (difference = 276)
132 326 TRUE 22740912 (difference = 371)
405 223 FALSE 22743018 ( ... and so on .....)
101 240 FALSE 22743531
130 234 TRUE 22744054
436 333 TRUE 22745009
436 335 FALSE 22745364

As you can see the difference between the times is nowhere near consistant. Is the time produced in the time terminal of an event in milliseconds or other - I can't seem to find it specified anywhere. Assuming it's in milliseconds, it's taking a long time before it stores another coordinate. I know the cpu has other things to process but surely a millisecond by todays computing standards is a looong time and it should be able to get back in time to catch the next coordinate after 100ms?

Any thoughts much appreciated.
Dave.

[smercurio_fc]

The problem isn't the computer, but rather the premise. If the user is moving the mouse slowly, as one would while tracing, then you probably won't get a mouse move event that often. You could have a mouse move occur 500 msec or 1.5 seconds after the last one, especially if the user is concentrating on where to move the mouse. Consider that the average human's reaction time is about 0.6 to 0.7 seconds. This is also affected by the resolution of the mouse.

If you want to record every 100 msec regardless of whether there was a mouse move, then you need to put that bit of code in the "Timeout" case, which will get called whenever there's no events. You would need to check to see if the mouse is in the picture control since the "Timeout" event would get executed whenever.

[parthabe]

---

@smercurio_fc wrote:
Well I'll be... I had never noticed there was no "Mouse Move?" event for the picture control.

---

Ya, smercuruio... ! For that matter, No control has a "Mouse Move?" event.

[mikeporter]

Alternately, you could have the mouse move event on the picture control, but only have it store a new datapoint if a timer started when the last datapoint was saved, has expired. This way, if someone just sits there and jiggles the mouse or if they have trembling hands (like Parkinsons' patients), many events will be fired, but they will only do something every N-msec - whatever you set the timeout to be. My sense is that we need to draw a distinction here between voluntary and involuntary reaction times. Twitches can occur much faster than deliberate motion.

Depending upon how steady a given patient's or subject's hands are this timeout could even be tailored to work with them. Longer timeouts would smooth-out the drawing, shorter ones would more closely follow the precise movements of the hand.

Mike...

[Dave123]

- thanks smercurio_fc, I see what you mean but if I take out the delay part and let it record every mouse move it generates 1000s of results for a similar little drawing. The few results I listed above were with the mouse moving continuously, I'm sure there were far more generated than that but for some reason they don't get recorded.

Thanks,
Dave.

Message Edited by Dave123 on 06-02-2007 08:50 PM