User interfaces and event structures

[Lee Robertson]

I am just learning to use event structures to improve operation of front panels.  At the moment, I am working on a tab strucrture we use to montinor/set program paramters.  VArious parametera are displayed on each tab as controls (not indicators) and are constanly updated sice they can be modified elsewhere by other pieces of code.  We controls are normally disabled via a property node so they behave more like indicators and the values are updated by writing to a local variable (I know this is evil but it works in this case).  There is a boolean on each tab that toggles between "monitoring" and "changing" modes (or states).  When toggles to "changing" (or setting) parameters the monitoring activities are suspended and the control are enabbled.  After making the desired changes the controls are either read and the changes implimented or get rest based on some other boolean controls, the parameters controls are then disables and monitoring resumes.  The issue is that many users fing the need to toggle between "monitorsing" and "changing" modes to be confusing.  I want to replace this switch with an event.  If the user clicks on any of the parameters controls in a tab, I want to go into changing mode rather than using the "monitoring"/"changing" boolean control.  All other asspects are handled as before.  My problem is than if I use a mousedown event to go into "changing" mode and the user clicks on several parameters to shift the keyboard focus to edit more than one parameter, these subsequent mose clciks get processed as new events when change mode is exited.  This means that as soon as it returns to "monitoring" mode it jumps immeadiately back to "changing" mode.  How should I structure the events to avoid this problem?

Thanks,

--Lee

[vivi]

you could say that if edit mode is on then you ignore the mouse down case. i believe that would fix your problem. tell me if it does not

[tjw2]

Lee,
Instead of using a "mouse down" event, use a "value change" event for each
of the controls. Then your program can switch to the "changing" mode
whenever the value of the control is actually changed.
TJW


"Lee Robertson" <x@no.email> wrote in message
news:1133532643609-295360@exchange.ni.com...
>I am just learning to use event structures to improve operation of front
>panels.&nbsp; At the moment, I am working on a tab strucrture we use to
>montinor/set program paramters.&nbsp; VArious parametera are displayed on
>each tab as controls (not indicators) and are constanly updated sice they
>can be modified elsewhere by other pieces of code.&nbsp; We controls are
>normally disabled via a property node so they behave more like indicators
>and the values are updated by writing to a local variable (I know this is
>evil but it works in this case).&nbsp; There is a boolean on each tab that
>toggles between "monitoring" and "changing" modes (or states).&nbsp; When
>toggles to "changing" (or setting) parameters the monitoring activities are
>suspended and the control are enabbled.&nbsp; After making the desired
>changes the controls are either read and the changes implimented or get
>rest based on some other boolean controls, the parameters controls are then
>disables and monitoring resumes.&nbsp; The issue is that many users fing
>the need to toggle between "monitorsing" and "changing" modes to be
>confusing.&nbsp; I want to replace this switch with an event.&nbsp; If the
>user clicks on any of the parameters controls in a tab, I want to go into
>changing mode rather than using the "monitoring"/"changing" boolean
>control.&nbsp; All other asspects are handled as before.&nbsp; My problem
>is than if I use a mousedown event to go into "changing" mode and the user
>clicks on several parameters to shift the keyboard focus to edit more than
>one parameter, these subsequent mose clciks get processed as new events
>when change mode is exited.&nbsp; This means that as soon as it returns to
>"monitoring" mode it jumps immeadiately back to "changing" mode.&nbsp; How
>should I structure the events to avoid this problem?
> &nbsp;
> Thanks,
> &nbsp;
> --Lee

[Lee Robertson]

Hi Vivi and Tom,

Thanks for your suggestions.  They center on what I have been considering.  In Vivi's case I have been trying to figure out how to ingnore (turn off) mouse evnts while in "change" mode or at least clear them just before I reenter "monitoring" mode.  For Tom's suggestion, I have the controls disabled so that writing new values to them dosen't cause all sorts of nasty things to happen -- but when they are disabled you can't change the value.

--Lee

[vivi]

if you use a case structure in your mouse down case and its case selector is controlled by a local var. then you set it false in the the changing mode and true when you go to monitoring mode. if true then you do your code normally but if false then you do not do anything

[Lee Robertson]

Hi Vivi,

That is sort of what I am doing now.  I have tried both case structures and sequences.  For example, I put a two frame sequence in a while loop.  The first frame has the event structure that looks for the mouse down event on a parameter control.  When it sees a mouse down event the event structure is "done" and execution moves on to the second frame which goes into "change" mode which then lets the user modify parameters, applys the changes, and then puts the parameter controls back into "monitor" mode.  The second frame is then done.  The sequence is done.  The while loop iterates.  Frame 1 of the sequence is executed again. The event structure now seems to process all the mouse clicks that were used to edit the parameter values in frame 2 of the previous while loop iteration.  In other words, you immeadiately get put back into "change" mode (frame 2) becasue the event structure sees a "que??" of mouse clicks to process. I know this becasue if I count the number of times I click on the parameter control in a single "change" mode session, the while loop interates that many times before the event structure in frame 1 of the sequence will again wait for a mouse down event (I can just the while loop iterate by exiting from "change" mode in frame 2 without clicking on any of the parameter controls).  I wish I could explain the problem better, I suppose I don't known the correct vocabulary.

--Lee

[vivi]

perhaps it would help if you showed us some of the code

[Lee Robertson]

Hi Vivi,

I have attached a code fragment to this post (at least I hope I have).  Run it (it is LV8), click on the lisit of motors which will put you in change mode, click on a boolean or two (hold) and change a few values (offsets), be sure to count the number of mouse clicks you need to do this.  Now click on "Update Parameters".  At this point apparently nothing happens but in reality you are in the next iteration of the large while loop (ignore the sequence at the bottom of the block diagram -- it just provides changing values for the motor position).  Click on "Dismiss Changes" the number of mouse clicks you used previously when setting the parameters.  Now you should be back in monitoring mode.  Note -- this is a contrived example and it is very lame.

--Lee

[vivi]

could you please put it in labview 7. i should of asked for an earlier version sorry.

[Lee Robertson]

Hi Vivi,

Here it is as LV7.1 (the only pervious version choice I had).

--Lee