Actor Framework Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

Events for UI Actor Indicators

Events for UI Actor Indicators is a set of wizards that allow you to quickly create UI actors from a template, and then add user events to handle updates to its front panel indicators.

 

Creating a UI Actor from Template

In your project menu, select Tools » Create Actor from Template...  You'll see the following dialog:

 

Create Actor From Template Dialog.png

Name your actor, and then click "Create Actor."  A new actor, cloned from the UI Template, will be added to your project. 

 

The new actor generally conforms to the pattern taught in Actor-Oriented Design in LabVIEW.  It comes configured to show front panel when called, actor core.vi already contains an event handling loop, and events are created and destroyed in Pre Launch Init.vi and a subVI of Stop Core.vi

 

(This tool supports creating actors from any template, not just the UI Template.  To add your own templates to the pulldown menu, create a subfolder in <LabVIEW>/Project/Create Actors From Template.  Name the folder "_<My Template Name>", and be sure to include the leading underscore.  Copy your template into the folder.  It will be available in the pulldown menu the next time you invoke Create Actor from Template.)

 

Adding Event Support to a UI Actor

Add an indicator to the front panel of your new actor, and right click on it.  Select "Add Event Support", as shown:

 

Add Event Support.png

 

The tool will add

  • a suitable event to the actor's attributes,
  • event creation code to Pre Launch Init.vi,
  • event destruction code to a VI called Destroy User Events.vi (which is called in Pre Launch Init and Stop Core), and
  • event handling code to the event structure in Actor Core.vi.

All that remains is for you to generate the event in an appropriate subVI.

 

The scripting code will tag any indicator for which it has generated event support, so you cannot generate code for the same indicator twice.

 

Notes

The scripting code uses labels on certain block diagram items to do its work.  Those labels are identified by comments; removing the labels will break the scripting code.  If your existing actors follow the general pattern of the template (create user events in Pre Launch Init, use an event structure in Actor Core, and destroy the events in Stop Core) you should be able modify your existing code to work with these tools by adding the appropriate labels.

 

Diagram cleanup still leaves something to be desired; we hope to address that in a future release.

 

Please feel free to post any comments or critiques here.  We'll answer as our paid work permits.

Comments
Active Participant Active Participant
Active Participant
on

It has been proposed that we extend this tool by generating a "Fire <name> Event" VI.  This VI would simply wrap obtain the event refnum from attributes and then generate the user event.  You would invoke this VI in your own code whenever needed.

 

If you think this would be helpful, kudo this comment.  If we get enough kudos, we'll consider adding the feature to a future release.

Active Participant Active Participant
Active Participant
on

There is a demo on YouTube:

LAF Q3 2018 - Auto generation of Actor Events

Member
Member
on

Idea?: I really like this tool, I've been using this for about a week now. One thing that would aid workflow is to have a 'Save Files Too...' control on the Create Actor from Template window like you do on the Create Actor window.

Member
Member
on

The right-click option "Add Event Support" does not appear when I right click on the newly added actor core front panel object.

 

I created a new project, and use the Tools>Create Actor from Template to create a new actor.

I then added a string to the actor core.vi front panel, saved the whole project and then attempted to right click on the newly added front panel string and select "Add Event Support" but the option does not appear.

I am using LabVIEW version: 18.0f2 (32bit)

 

I have also tried reinstalling package, restarting LabVIEW and even restarting my computer with no change in outcome.

 

Any thought as to what to try next?

Member
Member
on

Try adding an Indicator to the front panel.  The right-click option doesn't appear if you add a control to the front panel. 

Member
Member
on

Hi Jake77,

 

That's expected behaviour, typically we would only use user events to update indicators. If you want to update a control's value, I would suggest using VI server (property node) assuming you're only updating the control value once every so often.

Member
Member
on

Hi,

is it possible to use this on LabVIEW 2015? Could you please enable that?

Thanks

__________________
Engage! using LV2015
Member
Member
on

Hi

Found this plugin though Tom's LabVIEW adventure videos here: https://youtu.be/p--8oUMsZDE

 

Anyway installed with LabVIEW 2020 32 and 64 bit and while the Tools>create actor menu item is under tools, I can't see it when I right click a control on the actor core.

Any suggestions? - OK placing a new indicator seems to work. However controls copied across didn't work. Seems a bit weird. 

 

KiwiWires_0-1594677814534.png

 

 

Nick

Member
Member
on

Hi Nick,

The RCM will only appear for indicators. Typically we use user events to update indicators, if you want to update the value of the control I would add the control reference to the actor private data and use a property node.

 

Hope that helps

Active Participant Active Participant
Active Participant
on

Just a side comment, and from someone that doesn't use the AF, but having a message-style for updating indicators but a reference-style for changing controls seems a code smell to me.  Overly complicated, at least.  Why not use User Events to programmatically update controls?

Member
Member
on

Hi James,

 

My reasoning is (ACS might have other thoughts), as we're only updating controls and indicators in user-interface actors, references to each of the controls, indicators, panes, splitters, etc are already in the actor's private data to help with resizing, hiding (and all the other UI method stuff). Therefore, using a property node to update the value of a control doesn't add complexity. Using property nodes to update FPobjects is a very slow process but typically we only update control values 'every so often', so it's not an issue. Conversely, you might want to continuously update an indicator, and property nodes wouldn't be appropriate because of there inefficiencies - so we use user events.

 

For some controls, I will use a user event (and use a local variable in the event structure to update the control), but that has been when I'm updating the value in the control more than once per second or so.

 

So all in all, I'll use property nodes for updating things 'once in a while' and user events for continuous updates - that just happens to be controls and indicators respectively (for the most part). For me, this hasn't been an issue as I have scripting tools to create user events (this thread) and another tool to add FPRefs to the private data.

 

I'm not opposed to using user events for everything (and a local variable in the event loop for controls), I'd just have to modify the scripting tool slightly. Would you say this is a better approach?

Active Participant Active Participant
Active Participant
on

Ah, so your primary design is the big-bundle-of-control-refs in the message-handling loop, which you replace with User Events to the Event loop for indicators only for performance reasons.  Extra complexity for performance reasons I understand.

 

However, I personally would argue against the whole idea of bundling references and using them from a different loop than the one handling the events from those controls.  Though I know this is a common LabVIEW technique, it certainly isn't required.  Seems hard to read (difficult to tell where a control is affected) and I would worry about possible race conditions (due to two loops affecting the same reference).   Very non-Actor-Model to share references between loops.  And I've always wondered how one makes full use of the valuable "Filter" events in a design where the UI "heavy lifting" happens in a different loop than the Event Structure.

 

I would also say it seems a lot of extra work, but your scripting tools do cover that weakness.  

Active Participant Active Participant
Active Participant
on

Personally, I'd use user events to update the controls, both for consistency and to keep the methods that trigger the update out of the UI thread.  The latter reason makes me want to keep *all* references in the actor core override.

 

That said, it sounds like McQuillan does a lot more with his UIs than I ever get asked to do, so code organization and readability might win out over efficiency in his case.  At that point, I'd likely opt *not* to use user events to update indicators, for consistency, unless performance became an issue.

 

We teach both methods in the AF course.  I like events better, and I strongly encourage consistency in any choice, but McQuillan makes a strong case for "your mileage may vary."

Member
Member
on

Incredible package!

Here is a guide that I used to install the package, just go to the "On your PC without internet access" section

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PAQPSA4&l=en-US

----------------------------------------------------
Studying for CLA.
LabVIEW, inherit from social media habits!
Contributors