Unexpected UI actions (Dialog with Event Structure)

[Marg]

I have constructed a screen to display data to a user, and to call an edit screen if the user is authorized to do so. Both screens are in the form of dialogs using event structures. Much of the time they act as I intend, but not always, and even performing the same steps in the same order doesn't always give the same results. Sometimes the returned data is incorrect, and sometimes the screen acts as if I have hit the button multiple times.

The display screen shows a listbox with test names and symbols. Check marks indicate the tests already completed. The selection is supposed to be set to the first unchecked item in the list. (All this seems to be OK.) If the user is authorized, they may call the e
dit screen to alter the list of tests in limited ways:
move items up or down in the list (change the order), uncheck them (so they will be re-done), or delete them entirely.

I am new to LabVIEW, so there is probably a fairly obvious problem with the event handling and/or initialization, but I'm confused. The

[Mads]

Too much code to fix it all for you, but I can give you some comments;

- In e.g. an event that fires when a button value changes, do not read the button by wiring to the terminal, read the value from the NewVal terminal of the event case. The button may no longer have the value that it had when the event fired...

- You do not really need to set the canceled value to false in all the events, you leave the terminal to default in all the cases except the one for the cancel button...again, read the button using the NewVal.

- The "EditPerformed" indicator can as the code is now be set to true and then falsely set to false again if the user hits the edit button multiple times, but cancels the edit tha last time...(you still want to flag the previous changes don't
you?). You can fix this by only changing the flag if the flag is to be set to true...(use a case). OR use a shift register and only change the value of the shift register if it really should change...(are you familiar with the use of shift registers?).

- When you read or set values do it by wire (if necessary use a shift register to hold the current value), if you can't do it by wire...use locals, not the value property. In this case it's all user interface and simple controls/indicators so it's not that bad...but as a general rule avoid using the value property, it's the most inefficient way of doing it memory and speed-wise. Using a wire or shift register prevents race conditions though...that might be an issue here, haven't studied the code well enough to see those though.

[Marg]

Thank you very much for taking the time to give such constructive advice. I have been making some of the changes you suggested and hope to vanquish the bugs soon.
I am confused by a couple of things though:
1) I read the value of the buttons directly in order to reset them, as is done in the examples shipped with LV7. Since they are set to latch until read under the options for mechanical action. I thought that this meant the state would be known, but perhaps I misunderstood. I am adding cases to check and compare oldvalue and newvalue in case that is part of the problem.
2) I based my handling of the listbox on the listbox example that came with LV7, since I didn't see any way other than the property nodes of handling individual parts of the listbox conte
nts (the symbols, and item names). Again, I have most likely misunderstood something, but it looked as if I could only handle the listbox selected item through the local variables and shift registers.

Thanks for pointing out the EditPerformed problem.