Button does not respond (with attachment)

[Dave123]

Hi,

I'm trying to develop a LV program for a psychology experiment to record a participants mouse movements whilst drawing or tracing a picture using the mouse.

My program uses an event structure to generate an event each time the mouse is moved or the mouse button is pressed or released. Upon each of these events the coordinates and button position is recorded to an array.

When they have finished drawing there is a button "Stop & Save" that allows the user to save the coordinate data to a file. This can then be opened by a sister program I'm developing that allows the movements to be replayed and shows where the mouse button was down and up.

At the start of the program there is the option of loading a background jpeg picture to trace over on the screen.

The program then waits for a 'Record' button to be pressed before moving on to record all coordinates there after until the 'Stop & Save' button is pressed.

The problem I have is that the record button does not respond. It doesn't even change state when pressed, even though at that stage it's just sat in a while loop waiting for it to be pressed before moving on to the event structure.

I attach the program for you to look at.
Any help/hints much appreciated.

Thanks,
Dave.

[JB]

Insert a delay - Wait (ms) with 100ms - in the loop. Without any delay, the loop will run as fast as possible, using 100% of the CPU ressources !

[cs42]

I'd use an event structure for the record button as well. Or even better, use the already existing event structure to capture the record button. Polling a button is almost always bad anyway...

[intvsteve]

Hi Dave,

I took a quick look at your VI and noticed a couple of problems.

The most subtle one is what happens when you have a VI that wants mouse events. The trouble that arises is that when we see that the VI has an event structure that wants mouse events, *all* the mouse events go there... So the 'Record' button never gets the Mouse Down event, even though we aren't executing the event structure.

I reworked the VI in LV 7.1 to entirely rely upon the event structure for handling the button press events. Also, I modified it to specifically only 'care' about mouse down, mouse up, and mouse move events directly on the Picture control.

Since I didn't have the subVIs, I pruned them out to get the VI running, etc. You should be able to put them back in. Hope this helps!

[Dave123]

Hi,

thanks JB I tried putting a wait for 100ms in the loop but it still doesn't work.

p.s. I don't know if it makes any difference but I'm on a Mac not a PC.

Dave.

[Dave123]

- many thanks Steve.

I thought it might be due to something like that. That's the problem with these very high level languages, you can't see what's really going on (I'm from a assembly/C level background). I (incorrectly) assumed that because the loop with the record button in it was before the loop with the event in they wouldn't interfere.

Just one question, maybe I'm missing something but why do you bundle and unbundle the value of the recording button into a cluster in the event loop?

Thank,
Dave.

[intvsteve]

I'll confess that the lack of response took me aback for a moment, too. 😉

As to why I do the bundle / unbundle through the event structure... It's a pattern I've gotten into the habit of using over the years. Rather than read / write locals for loop or other state data, it's convenient to use a shift register w/ the bundle in it to track the data. Then any eventual additions to the main loop can easily access / update that data, and the number of copies is kept under control.

For example, each time you drop a 'read' local variable, we must make a deep copy of that data for the diagram. Then, if you write it back into a control or indicator, another copy must be made. And, usually, between the front panel and block diagram, that requires a thread context switch.

So, as a further improvement to your VI, I'd suggest adding the empty array to that initial bundler outside the main loop, unbundle / modify / rebundle where necessary, and then unbundle it outside the main event loop when you finish.

This pattern even predates the existance of the event structure and local variables in LabVIEW. (*gulp* Man, has it been that long since I started using LV?!)

[Dave123]

- Cheers, will do, many thanks again.

[altenbach]

Your overall program design is higly flawed. This calls for a single state machine with an event structure that handles all FP events. All your locals can be handled by shift regsters. Get rid of that useless stacked sequence!

Frame 0: Initialization belongs to the left of the state machine. CoordinatesArray should initialize a shift register (no locals needed). Use a boolean shift register to set state to either recording or not. Event for "record, value changed" will switch the boolean to be used on the other states.

Frame 1: "Clear" and "stop" need to be inside their own events. Running it parallel to the event structure is a no-no! Do you really want to record mouse movements on the entire FP or only on the picture area?

Frame 2: Why waste an entire frame on this? Here you clear it and in the next frame you prepend the cleared string to your data. Makes no sense.

Frame 3: An autoindexing FOR loop would be the right choice. A single formating operation can handle multiple values.

Frame 4: Writing the "coordinate string" seems useless, since you just cleared it two frame earlier. You are writing an empty string to a file! Right? Why invert the "canceled?" output, just swap the cases instead.

Frame 5: Unecessary! Once the VI runs out of code, the VI will stop automatically. The "stop" function also does not "close the program window" as you seem to indicate with a diagram comment. Check the online help.

Message Edited by altenbach on 05-22-2007 09:23 AM

[Dave123]

---

@altenbach wrote:

Your overall program design is higly flawed. This calls for a single state machine with an event structure that handles all FP events. All your locals can be handled by shift regsters. Get rid of that useless stacked sequence!

Frame 0: Initialization belongs to the left of the state machine. CoordinatesArray should initialize a shift register (no locals needed). Use a boolean shift register to set state to either recording or not. Event for "record, value changed" will switch the boolean to be used on the other states.

Frame 1: "Clear" and "stop" need to be inside their own events. Running it parallel to the event structure is a no-no! Do you really want to record mouse movements on the entire FP or only on the picture area?

Frame 2: Why waste an entire frame on this? Here you clear it and in the next frame you prepend the cleared string to your data. Makes no sense.

Frame 3: An autoindexing FOR loop would be the right choice. A single formating operation can handle multiple values.

Frame 4: Writing the "coordinate string" seems useless, since you just cleared it two frame earlier. You are writing an empty string to a file! Right? Why invert the "canceled?" output, just swap the cases instead.

Frame 5: Unecessary! Once the VI runs out of code, the VI will stop automatically. The "stop" function also does not "close the program window" as you seem to indicate with a diagram comment. Check the online help.

Message Edited by altenbach on 05-22-2007 09:23 AM

---

Hi, thanks for your reply.

The reason for the main stacked sequence was to get some order to the program, my programming background's text based and as such I like to think of a program running in a list/sequence order. LabView seems strange when you've been used to programming in asm or C. Does anyone know of any books or online documentation for people migrating from text languages to LV? - I haven't found any.

"Frame 2: Why waste an entire frame on this? Here you clear it and in the next frame you prepend the cleared string to your data. Makes sense."
- The string 'CoordsArray' is cleared to make sure it's empty before chars concatanated to it in the next frame. Call me old fashioned but is it not good practice to clear out any junk in a variable rather than just assuming it's empty?

"Frame 3: An autoindexing FOR loop would be the right choice. A single formating operation can handle multiple values." - not sure what you mean by that?

"Frame 4: Writing the "coordinate string" seems useless, since you just cleared it two frame earlier. You are writing an empty string to a file! Right? Why invert the "canceled?" output, just swap the cases instead."
- No, it's not an empty string since in the previous frame the coordinates array is converted to numbers and concatanated to it. Trust me, it generates a file with lots of data in so no way is it an empty string!!
- Yes, you could just swap the cases instead of inverting the 'canceled' output but sometimes it reads better to say 'if NOT cancelled then DO theTask, ELSE DO nothing' rather than 'if cancelled DO nothing ELSE DO theTask'. Not sure if that makes sense but I guess it's just personal prefference there.

"Frame 5: Unecessary! Once the VI runs out of code, the VI will stop automatically. The "stop" function also does not "close the program window" as you seem to indicate with a diagram comment. Check the online help."
- I wasn't sure how that one would work. I wanted the final exe version to close the program window when the program comes to the end, what's the best way to do that? In the past I think I used the 'Exit' function but this would annoyingly quit LabView at the end of each trial run whilst still in the development stage.

Thanks,
Dave.