Disabled button fires events to event structure

[rrawer]

Hi all,

I was trying to disable a Button on the frontpanel by using its enabled property while the event was executed. The ide wa not to create more events of this buttopn while its fucntion was executed. However thsi did not work.It was creating events even though it was greyed out.

I troied two different versions:

1) in the event case of the button (value changed) in a sequence I first dispalbned the button, execuded the code and then enabled it again
    Result: All events were generated even though the button was greyed out

2)  in the event case of the button (value changed) in a sequence I disbaled the Button and then started a second event. The Second event executed the code and then enabled the Button egain
   Result: Even though the Button was greyed out events were generated

3) in the event case of the button (value changed) in a sequence I first dispalbned the button, execuded the code and in the timeout event I thenenabled it again

   Result: No additional events were generated

it seems that the enable state of the button is analysed at teh time when the event is execute din teh event case but not at the time when it was created?

So I Tried the Time Input of the case expecting that it woudl give me a time stamp of the time when the key was pressed - but instead it gave me the time point when teh event was executed...

Teh only othe rsolution was to set teh cursor to busy (however I dont want to see the changed cursor during the busy cycle)

So how can I make shure that no additional events are fired during the time teh code of the Button s executed?

Thanks for any help,
Rainer

[altenbach]

It would help if you could attach some illustrative code instead of lenghty and complicated descriptions. Thanks!

What is the mechanical action of the buttons? What are the exact event configurations (lock panel, etc.). What is your LabVIEW version? How long do the event cases take to complete?

I typically stay away from micromanaging the front panel objects via property nodes. There are probably better ways.

[sth]

If you disable a front panel control (ie the button) you cannot click on it and a value changed event will not be generated.

If you disable a front panel control (ie the button) and then do a "value change with signalling" property inside a VI then the value will change and the event will occur.

The time stamp from the event case left hand property is the time of the event not the time of execution.

If you ask for the timer value inside the event case it will be the time of event case executing.

If you can find a violation of any of these statements, post some example code since I have found all of them to be valid and expected behavior.

From your post it may be that you have a race condition in disabling/enabling the button

[rrawer]

to altenbach:

• The evet takes about one or two seconds - I checked the behaviour as shown in the attached examples with LV 8.5, LV 2010, TV2011, LV2012 - allways exactly the same behaviour.
• It does not make any difference weather you use switch when pressed or latched when pressed.
• It does not make any difference weathe ror not you tag "Lock front panel" for that event

to sth:

> If you disable a front panel control (ie the button) you cannot click on it and a value changed event will not be

generated.

This is my experience so far as well, but if you disable and enable the control within the same event it does not work (see attaced example 1) and 2). It only works if you do the enable in the timeout event.

> The time stamp from the event case left hand property is the time of the event not the time of execution.

> If you ask for the timer value inside the event case it will be the time of event case executing.

In the attached exampel this is not the case. The time differecne between the Time input on the left and the Tick count

placed in the event is 0 for all events generated whil the button is supposed to be disabled.

As I wrote before, the explanation I have for this behaviour is that the events are generated by windows weather or not

the button is disabled and they are queued to the event cue. Only when the event is handeled LabVIEW tests weather

or not the button is disabled and ignores the event in case it is disabled. If the Disabling and enabling is done

withim the same event the button pressed events are added to thw event queue and the button is set to enabled before the  next event (button pressed while it shoul be disabled) is handeled. When that event is handeled the button is enabled again (by the original event) and therefore the evenet is not ignored (because by the time of execution of the event the button is enabled again).

If the button is enabled in the timeout event instead of the button change value event all event in teh queue are executed before teh timeout event. At their time of execution therefore the button is steill disabled. Only then the timeout event enables the button again.

If the vi is set to busy (sand clock) this is activating actually a windows function/property and no events are queued to teh event queue by windwos. Therefore no button change event is added to teh queue.

Funtciomn of the 3 attached Vis (LV 2010):

Run the Vi, then press the Test button once - when it is greyed out click it a few more times. The test button value

changed event has a 2 second delay. You will see the event counter increase, and you will see the time difference

between the time property on the left of the event and the tick count vi whci is displayed in the waveform chart.  

• DisableButton 1: Disable and enable are ste in teh same event  
• DisableButton 2: The button is disabled then a second event is called to do the work and then enable teh button again
• DisableButton 3: The Button is disabled in button change value event and it is enabled again in teh timeout event.

[billko]

You should probably take some courses or do some tutorials here to learn how to program in LabVIEW correctly.

[apok]

---

@billko wrote:

You should probably take some courses or do some tutorials here to learn how to program in LabVIEW correctly.

---

I agree...your code is something left to be desired. I do not know what you are trying to prove by putting timers into an event structure, let alone using flat sequences. You will defeat the purpose of the event structure in user interface design?

note: I will try to use the spell check more often

pressing the ok button will increment the counter and disable/gray it out. Timeout set for 5 seconds and will enable the button, no matter how many times you have pressed it within that time...it will not increments unless enabled. I may be assuming here what you are trying to prove ?

[Todd_Lesher]

It certainly is interesting that events can queue up while the button is disabled. I agree with the folks who say that the "disabled" property node should be used outside of the event structure.

[altenbach]

You need to set the event to not lock the front panel and everything works as expected.

Here's a quick rewrite of the first VI that gets rid of some of the sequences and local variables clutter.

Seems to work just fine: If you triple click the button, only one event is generated as expected.

(Yes, if the front panel is locked until the event completes, events keep accumulating. I think we discussed that in the past, but I don't remember where. EDIT found it!. The logical explanation for this behavior is in this post)

[rrawer]

> I do not know what you are trying to prove by putting timers into an event structure

this was just an example for a time consuming task. In the original application I am wating for hardware to stop which takes between 0.5 and 2 seconds. I didn't want to use the set busy vi because I don't want to have the Windwos look and feel since the application is running on a dedicated embedded hardware.

Putting the enable property into the timeout was one of the solutions I already mentioned - but if the application is running on a system with limited resources running at its limits it could take some time before the timeout is executed. Therefore I'd prefere another solution...

[rrawer]

to apoc:

Thanks - you are correct. I wasn't aware of that the Lock front panel property actually only delays the execution of the events - I thought they would be ignored which explains why I didn't expect the behavior...

Just one remark to the code you posted - the Delta t was not designed to show the time between the two events but to show that in the case posted originally the time property on the left of the event structure did not give me the point of time where the button was pressed but the point of time the event was actually executed (due to the tagged Lock front panel property...)