Event structure - Revision history

Eyesonvis: Note the behavior of front panel locking with subpanels.

2022-10-17T19:37:51Z

Note the behavior of front panel locking with subpanels.

← Older revision		Revision as of 19:37, 17 October 2022
Line 119:		Line 119:
	\|}		\|}

	This checkbox is ''checked'' by default. When unchecked, any additional events are put on the event queue '''after''' the current event finished executing.		This checkbox is ''checked'' by default. When unchecked, any additional events are put on the event queue '''after''' the current event finished executing.

			When an event case locks the panel, if the object that generates the event is in a subpanel, then LabVIEW locks the front panel that displays the subpanel.

	=== Limit maximum instances of this event in event queue ===		=== Limit maximum instances of this event in event queue ===

Q at 15:30, 25 June 2020

2020-06-25T15:30:00Z

← Older revision		Revision as of 15:30, 25 June 2020
Line 1:		Line 1:
	{{TOCright}}		{{TOCright}}
	{{LabVIEW Palette Object Information\|palette=Functions Palette/Programming/Structures{{!}}Structures palette\|palette2=Functions Palette/Programming/Dialog & User Interface/Events{{!}}Events palette\|type=structure}}		{{LabVIEW Palette Object Information\|palette=Functions Palette/Programming/Structures{{!}}Structures palette\|palette2=Functions Palette/Programming/Dialog & User Interface/Events{{!}}Events palette\|type=structure\|icon=Events Palette - Event Structure.png}}
	[[File:Event Structure - Components.png\|thumb\|Components of the Event Structure]]		[[File:Event Structure - Components.png\|thumb\|Components of the Event Structure]]

Q: Added info table.

2020-06-23T20:18:47Z

Added info table.

Show changes

Q: Q moved page Functions Palette/Programming/Structures/Event Structure to Event structure: Renaming to make it more in line with other palette items.

2020-06-23T18:29:32Z

Q moved page Functions Palette/Programming/Structures/Event Structure to Event structure: Renaming to make it more in line with other palette items.

← Older revision	Revision as of 18:29, 23 June 2020
(No difference)

Q at 18:15, 22 June 2020

2020-06-22T18:15:49Z

← Older revision		Revision as of 18:15, 22 June 2020
Line 206:		Line 206:
	[[Category:Event Structure]]		[[Category:Event Structure]]
	[[Category:Event-Driven Programming]]		[[Category:Event-Driven Programming]]
			[[Category:Events Palette]]

Logmanoriginal: Add to Structures Palette

2020-05-15T13:25:15Z

Add to Structures Palette

← Older revision		Revision as of 13:25, 15 May 2020
Line 203:		Line 203:

	[[Category:User interface]]		[[Category:User interface]]
	[[Category:Structures]]		[[Category:Structures Palette]]
	[[Category:Event Structure]]		[[Category:Event Structure]]
	[[Category:Event-Driven Programming]]		[[Category:Event-Driven Programming]]

Q: /* See also */

2019-09-02T03:43:05Z

Logmanoriginal: Remove "Under Construction" flag

2019-07-31T19:38:06Z

Remove "Under Construction" flag

← Older revision		Revision as of 19:38, 31 July 2019
Line 1:		Line 1:
	~~{{Underconstruction}}~~

	[[File:Event Structure - Components.png\|thumb\|Components of the Event Structure]]		[[File:Event Structure - Components.png\|thumb\|Components of the Event Structure]]

Logmanoriginal: Remove already covered content

2019-07-31T19:37:46Z

Remove already covered content

@@ Line 203: / Line 203: @@
 == References ==
 <references />
 [[Category:User interface]]

Logmanoriginal: Add FAQ

2019-07-31T19:36:04Z

Add FAQ

← Older revision		Revision as of 19:36, 31 July 2019
Line 182:		Line 182:
	* '''Never''' handle the same event in multiple event structures.		* '''Never''' handle the same event in multiple event structures.
	* '''Never''' place an event structure within another event structure.		* '''Never''' place an event structure within another event structure.

			== FAQ ==

			=== Why doesn't the event structure register local variable changes? ===

			This is a design choice. Local variables are often used inside an event structure to update values on the front panel. If an event updates the value of the same control that generated the event, it would result in an infinite loop if the event is also generated for local variables. To programmatically generate events for controls use a [[Property node\|property node]] for the '''Value (Signaling)''' property.<ref>https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019N6xSAE</ref>

	== See also ==		== See also ==
Line 195:		Line 201:
	* [https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/caveatsrecmndtnsevnts/ National Instruments: Caveats and Recommendations when Using Events in LabVIEW]		* [https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/caveatsrecmndtnsevnts/ National Instruments: Caveats and Recommendations when Using Events in LabVIEW]

			== References ==
			<references />

	{{cleanup}}		{{cleanup}}
Line 213:		Line 221:

	As noted earlier, it is possible to leave the Event Structures nested, but turn off the UI locking. This appears to solve the problem, but it isn't how I would do it. I think a much better solution is to combine the diagrams of two structures into one. The value change for hidden controls will not happen, but it doesn't hurt to have it in the list of things to watch for. Another option is to place them in parallel loops. This will let the first structure finish and go back to sleep.		As noted earlier, it is possible to leave the Event Structures nested, but turn off the UI locking. This appears to solve the problem, but it isn't how I would do it. I think a much better solution is to combine the diagrams of two structures into one. The value change for hidden controls will not happen, but it doesn't hurt to have it in the list of things to watch for. Another option is to place them in parallel loops. This will let the first structure finish and go back to sleep.

	~~== Why doesn't the event structure register local variable changes? ==~~
	~~The main reason for not sending events for programmatic value changes is to avoid feedback.~~

	A happens. In responding to A, you update B and C. If responding to B or C results in changing A, then you have feedback and your code will behave like a dog chasing its tail. Sometimes the feedback will die out because the value set will match what is already there, but often it will continue indefinitely in a new type of infinite loop.

	One solution to this is to utilise User Events. Then you either have the value change and the set local both fire the user event, or you can combine the event diagram to handle both and just fire the event when writing to the locals. Today, you can accomplish this with the queued state machine using the state machine to do all the common work and just having the event structure pass things to the queue.

	== Locking The Panel ==		== Locking The Panel ==

← Older revision		Revision as of 03:43, 2 September 2019
Line 188:		Line 188:

	== See also ==		== See also ==
			* [[EventStructure class]]
	* [[User events]]		* [[User events]]
	* [[Event Inspector Window]]		* [[Event Inspector Window]]