Mechanical Action & Event Case

[Tomi Maila]

We can specify Mechanical actions for buttons such as Latch when released. The value of the button is reverted when the control value is read. However when using event structure with value change event with latch when released button, the value of the button doesn't revert back to original when reading the new value terminal of the event structure. Instead the control needs to be placed inside the event structure.

Does anyone know why does the reading of the new value input not revert the state of the button? I've been wondering it for ages. In general the control BD terminal cannot be used to read the value of a control within an event structure as in general there may be multiple value change events in the event queue and the control terminal always returns the value of the latest value change and not the value change being handled by current event case. If the events are not properly handled in order, a state of the program may become inconsistent with the user actions. Instructing users to use the latching button terminals withing event structure guides users to bad programming habits that may result in bugs when used with fastly varying controls.

[Yair]

QUOTE (Tomi Maila @ Apr 30 2008, 11:53 AM)

Does anyone know why does the reading of the new value input not revert the state of the button?

Because that would contradict the established behavior and can have problems of its own?

For example, what happens if you use a value change events in two event structures? When should the button latch?

How about if you have two event structures and you're also reading the button in a third loop?

In general, you don't have to tell users to use the booleans. They can just place them in the event case and not use them. This is also useful when double clicking a control because it takes you directly to the event handling code.

[Aristos Queue]

0) Because reading the FP terminal has always been the trigger to unlatch the boolean.

1) Because sometimes you only want to react to the value change event and not reset the value back until later

2) Because if reading the terminal and reading the even both set the value back, sometimes the terminal would get read first and then you'd have a value change event already in the queue for a value that isn't the new value.

3) Because the event structure follows the same rules as reading the Value property or reading a local variable -- the only thing that unlatches is reading the FP terminal.

[Rolf Kalbermatter]

QUOTE (Tomi Maila @ Apr 30 2008, 04:53 AM)

Does anyone know why does the reading of the new value input not revert the state of the button? I've been wondering it for ages. In general the control BD terminal cannot be used to read the value of a control within an event structure as in general there may be multiple value change events in the event queue and the control terminal always returns the value of the latest value change and not the value change being handled by current event case. If the events are not properly handled in order, a state of the program may become inconsistent with the user actions. Instructing users to use the latching button terminals withing event structure guides users to bad programming habits that may result in bugs when used with fastly varying controls.

Also if you use latch when released I never had the need so far to not use the latest value really. Other latches I have almost never used.

Rolf Kalbermatter