LabVIEW
Wait for User Event
@JÞB wrote:
You could TRY to inline an Event Structure that only has dynamic Events and timeout. I'd be curious if that is allowed.
This is what I intended (there is also a "Timeout" case) (tested in LV2023Q3):
I have the error message:
"Event Structure: This object is not allowed in a VI on which you enable inlining. Disable inlining or remove this object."
...even though User Events have nothing to do with the front panel...
@JÞB wrote:Uhmmmm.. as a rule ThisVI simply can't be deciphered when it is sucked into ThatVI by inlining.
Why couldn't "ThisVI" and "ThisApplication" (and also unwired VI/App prop/invoke nodes) simply reference the context of the caller VI (more precisely, the first parent that is not inlined) ? Is there a case where the caller context would not be determinable?
@JÞB wrote:
Nor can any Asynchronous Node [be inlined].
Actually you can inline "Call By Ref", "Start Async Call" and "Wait On Async Call" nodes, at least since LV2020.
Regards,
Raphaël.
@UliB wrote:
@ethanFHenry wrote:
Is there any way to wait for a user event and get the data put WITHOUT USING AN EVENT STRUCTURE? I'm using events because 95% of the time Event structures are easy and the natural thing to do, but sometimes it'd be helpful to just be able to wait for the event without the huge event structure. Thanks!
To avoid the huge event structure on your block diagram you can put the event structure in a SubVI.
One of the reasons LV NXG died a horrible death is because you can't do this in NXG.
@raphschru wrote:
@JÞB wrote:
You could TRY to inline an Event Structure that only has dynamic Events and timeout. I'd be curious if that is allowed.This is what I intended (there is also a "Timeout" case) (tested in LV2023Q3):
I have the error message:
"Event Structure: This object is not allowed in a VI on which you enable inlining. Disable inlining or remove this object."
...even though User Events have nothing to do with the front panel...
@JÞB wrote:Uhmmmm.. as a rule ThisVI simply can't be deciphered when it is sucked into ThatVI by inlining.
Why couldn't "ThisVI" and "ThisApplication" (and also unwired VI/App prop/invoke nodes) simply reference the context of the caller VI (more precisely, the first parent that is not inlined) ? Is there a case where the caller context would not be determinable?
@JÞB wrote:
Nor can any Asynchronous Node [be inlined].Actually you can inline "Call By Ref", "Start Async Call" and "Wait On Async Call" nodes, at least since LV2020.
Regards,
Raphaël.
While those nodes contain "Asynchronous " in the name...the nodes themselves are not Asynchronous.
ThisVI and ThisApp are easy to replace with controls that can be passed into the inlined code 😀 it even makes the inlined code more readable. Leaving the controls unwired even forces the caller to pass in the default "This"Ref. Easy peasy lemon squeezey. The only case where ThisRefs are not able to be determined is during the development of the code to be inlined - so out pops an error forcing a better solution. It could've probably been just a warning that explained that This would become That when inlined. NI chose to throw an error.
@Yamaeda wrote:
@raphschru wrote:
Isn't that exactly what Wait on Notifier does?
I would rather say, that's what "Wait on Notification with Notifier History" does (with "ignore previous" set to true), because the simple "Wait on Notification" does not work when calling the same node instance repeatedly with different Notifier references.
But even then, there are slight differences:
- The Event Registration refnum's lifetime is independent from the User Event refnum's lifetime.
- "Register for Events" works even if the User Event refnum is invalid, then the Event Structure will simply time out.
@raphschru wrote:
@Yamaeda wrote:
@raphschru wrote:
Isn't that exactly what Wait on Notifier does?
I would rather say, that's what "Wait on Notification with Notifier History" does (with "ignore previous" set to true), because the simple "Wait on Notification" does not work when calling the same node instance repeatedly with different Notifier references.
But even then, there are slight differences:
- The Event Registration refnum's lifetime is independent from the User Event refnum's lifetime.
- "Register for Events" works even if the User Event refnum is invalid, then the Event Structure will simply time out.
Yeah, this solution will not wait for events sent before this registration occurs, a Wait for notifier will
@paul_a_cardinale wrote:
Or you could try creating an Express VI that does it.
Yeah but an express VI wouldn't react to a data type change like an XNode can, or would it?
