Actor Framework Pallete Additions

[LVB]

I thought that I would suggest a few items to add to the Actor Framework pallete for 3.0.7.

The "Get Queue For Sending To Self" and "Get Queue For Sending To Caller" should be visible on the pallete.  These are commonly used when overriding the Actor Core with a user interface.

[AristosQueue (NI)]

There has been some dispute internally about how to handle this. There are no cases of VIs that curently ship with LV that are non-public members of classes being in the palettes. Putting protected scope VIs on the palettes is arguably strange behavior.

The precedent is wide open... anyone else have an opinion on adding these two VIs to the palette? Or on adding protected VIs in general?

[justACS]

I can see the argument for it, though.  The mission of the pallete is to provide ready access to VIs we need during development.  When writing in AF, we are either writing message classes or children of the Actor class.  We *intend* for people writing child actors to use the queue accessors, so putting them on the pallete aligns with the missions of both the palette and the accessors themselves.  IIRC, the only other protected methods are method cores, which are all intended for override, and thus should not appear on the pallete.

Perhaps a separate subpallete, named "protected" to empasize their scope, would be in order?

[Daklu]

niACS wrote:

The mission of the pallete is to provide ready access to VIs we need during development. 

Agreed. Anything we reasonably expect users will need should be on the palette. I've put protected method on the "Advanced" palette, along with a few other odds and ends. Personally I prefer a glyph to emphasize scope because I think it also helps when reading the block diagram.

[dougku]

I like the solution offered by Daklu.  Palettes give a lot of information, including what is available for the developer.  The glyph gives information beyond what will be available from quick drop.

I think palettes should contain access to the Vis needed for development.  What about tools?  How does the developer know to use the message creator?

[AristosQueue (NI)]

Assuming all goes as planned -- and those of you who read my posts regularly know how loathe I am to promise features for future LV versions -- the Actor Framework will ship as part of vi.lib in LV 2012. If it does (and it is in there now, making its way through the alpha and beta testing processes), those two VIs will be in the palette. Adding them to the palettes was a good suggestion.

> What about tools?  How does the developer know to use the message creator?

At this point, my only answer to that is "read the documentation". The framework itself cannot reasonably be tackled without some amount of reading, so I'm fairly confident that if the Message Maker is mentioned there, that will suffice. I hope. 🙂

[dougku]

Terrific!

Having the Actor Framework available in LabVIEW with standard documentation will certainly enable users to know about the tools.  Moving into a LabVIEW release is of tremendous importance because it will allow beginning LabVIEW programmers to use the Actor Framework without having to install and manage additional addons.  First learn how to make a LabVIEW class and then how to make an actor.  Then learn how to implement and maintain actors within existing actor frameworks.  All very simple for the end user, and force multiplying for the application architect!

The evolution of the Actor Framework has been extremely fruitful to watch.  I have gained much insight into developing an API, designing a software addon for distribution, correct use of projects, libraries and LabVIEW scripting, useful commenting, project documentation, effective communication with the community, using VIPM, and more.  Thank you for the great "tutorial".

I will be interested to see the examples included with the release.  I have found that new users typically view the examples as a starting point.  I think that the actor framework has tremendous benefit for new and advanced users.  Now there is a crossplatform framework that can be a starting point and reference for so many different types of applications.

Thanks