Events for UI Actor Indicators

[justACS]

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:

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:

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.

[justACS]

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.

[justACS]

There is a demo on YouTube:

LAF Q3 2018 - Auto generation of Actor Events

[McQuillan]

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.

[crcragun]

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?

[jake77]

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

[McQuillan]

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.

[KiwiWires]

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. 

Nick

[McQuillan]

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

[drjdpowell]

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?

[McQuillan]

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?

[drjdpowell]

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.  

[justACS]

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."

[CDuck]

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

[code-lux]

How are the indicators tagged? How can I remove the tag?

I noticed that when I copy an indicator where the Event Support has been added before, it´s not possible to add Event Support to that copy.

Edit: I found that the tags are written by Tag:Set Tag Method - so it's clear how to change it by scripting...   But is there an other way to see and change tags? Is there a way to copy without tags?

Path to script: C:\Program Files (x86)\National Instruments\LabVIEW 2020\resource\plugins\PopupMenus\edit time panel and diagram\Events for UI Actor Indicators Support

I did not find the code that decides whether add Event Support is shown in the menu...

Found a bug: An array of string indicator shows add Event Support on FP but not on BD.

The Pre Launch Init.vi from the Template leads to an Error when used with Monitored Actor. The reason is that the Call Parent Class Method is in a Case Structure and Monitored Actor requests that children MUST Call Parent Class Method. Is there a drawback in leaving away this Case Structure?

[HarryS2021]

How can i generate the event in an appropriate subVI  automatically.

[Taggart]

@Allen,

we should put this on VIPM.IO now.

Do you want to? or should I?

[jcopetre]

@Sam, @Allen--really neat package you all have put together. Thanks for pushing it out into the wild. I don't seem to find it on vipm.io however; can you guide me in please?

[justACS]

@jcopetre Sadly, it's not available there yet, which is something I need to fix.

I have another package I intend to publish on vipm.io before GDevCon NA.  I will look to get this one up there around the same time.  Feel free to harass me if I haven't done so by August 1st.

I want to get the Git repository public-facing as well.

[justACS]

The repository is now publicly facing.  I still have some admin work to do, like make a proper Readme file, but at least you can get to the source directly now.

I plan to post the package to vipm.io in the coming weeks, which will require reworking the package build specification a bit.  I'll change the license to Apache 2.0 at that time as well.

The repo is here:  https://gitlab.com/justACS/events-for-ui-actors.git

[justACS]

This package is now available on VIPM.io:  https://www.vipm.io/package/events_for_ui_actor_indicators/

[Morefun]

I love this package,THX!

[DeAnmoN19]

Hello,

I like to use this tool. It is awesome! I am using this tool with MGI Panel Actor in my projects. 

I would like to see the saved files wherever I want. The tool is not letting me. It saves the application folder. Sorry, I am addicted to working with virtual folders. So, it would be an amazing add with a right click, on library.

[justACS]

I'm glad you like the tool.  Sam and I are rather fond of it, and I use it on all of my AF projects.

If you haven't already, you can change the template to inherit from the MGI Panel Actor, and everything just works.  Note, however, that you will have a redundant stop event.  Use the MGI event and ignore the extra one.

It would be relatively easy to change the tool to include a save location.  I'll make a note, though I can't say when I'll get to it.  That said, there are a few other updates I'd like to make.

If I recall, your new actor comes in a library, so I'm not sure why you would want to add it to a different library.  In any event, that's quite a bit more work, as I'd have to convert the tool to a project provider, a non-trivial task.  And adding an actor to a virtual folder is something we were not able to work out when I was at NI, for really obscure provider-related issues.  (I'm perfectly willing to write project providers, but they are something of a black art, with all sorts of interesting and undocumented pitfalls, so I'm not really considering it for any of my side projects at this time.)

Now, change of subject.  You mentioned you are using MGI's Panel Actor, which is a fabulous add-on to the AF ecosystem.  However, it relies on MGI's Monitored Actor, which has great functionality but adds a required ancestor to your actor hierarchies.  You might consider the Actor Hierarchy Inspector .  It offers the same functionality without the need to inherit from Monitored Actor.  You can still use the Panel Actor; just change it to not inherit from Monitored Actor and it works fine.

[DeAnmoN19]

Mr.Allen,

Thanks for your response. 

I don't want to add it to a different library, I want to create an actor using your tool, which will occur where the virtual folder that I want. But I can handle it drag and drop. I haven't seen any problem using the other topics you mentioned above with the Panel Actor for now. 

Regards.

[AWilcox]

I recently discovered an issue with the toolkit's Actor Core UI template that creates the possibility of deadlocking the event handling loop. The only exit condition for the event handling loop is for it to receive the "Stop" event, but that can only happen if the Register for Events node executes successfully. If the user modifies the VI so that there's nodes or subVIs that run before the Register for Events node, any error generated in those nodes/subVIs will prevent the "Stop" event from being registered and the event handling loop will get stuck in an infinite loop.

The simplest fix for this seems to be wrapping the event handling loop in a Select Case structure whose case selector is wired to the Error Out terminal of the Register for Events node, with the loop in the "No Error" case.

[justACS]

Thanks for pointing this out.  I'm considering some other revisions to the basic template, and will work in a fix at that time.

In the mean time, you can copy and modify the existing template, and access your new template from the "Create Actor from Template" tool.