Implementing the State Pattern in Actor Framework

[AristosQueue (NI)]

I cannot answer that. No NI employee can tell you how to interpret the EULA. That would be giving legal advice without a law degree and is illegal. And our lawyers cannot advise you because you are not their client; you are, in fact, among the people they cannot say anything to because you'll likely be our opposition in court. The only thing I can do is tell you to abide by the terms of the EULA which you agreed to. You have to make your own decisions from there.

Isn't that a complete crap answer? I have had a moderate education in this stuff over the last few years and have come to truly loathe our legal system in this respect. It essentially requires me to treat customers as the enemy.

I cannot tell you whether it is legal or not. I can say that I -- personally -- want customers to help with the development of AF and I've done everything I can to facilitate that, and I would personally cheer such developments (although I would beg that you occassionally post the results of your development back onto ni.com so I and NI can share them). But my personal feelings have no bearing on whether that development might or might not be violating the EULA. Your call.

The best part of this horrific system? You could hire a lawyer and ask, "Can I do this under this EULA?" And the lawyer cannot answer that question! What they can give you is an educated opinion about what is *probably* legal under the EULA. The only way to know whether a given action was legal is to get a judge's ruling in court after your lawyer and our lawyer presented arguments about interpreting the EULA. And at that point, you face the punishment if you guessed wrong, which is why sentencing takes into account intent. But it seems really backwards to me. Apparently it is really hard to get an answer about whether an action will be legal.

Frustrated yet?

[St3ve]

What a can of worms! I may get my stone tablet out and start with that instead; oh wait, it's rectangular with rounded corners... someone pateneted that!

[AristosQueue (NI)]

Patents? Oh... we've just been discussing licensing for copyright. We haven't even started talking about patents and trademarks! Or trade dress. Trade dress is a fun topic -- trade dress is a legal term of art that generally refers to characteristics of the visual appearance of a product or its packaging that signify the source of the product to consumers. Trade dress is a form of intellectual property. You can completely avoid all of the patents, trademarks and copyrights and still hit against trade dress by using a common type font, or the same general color scheme. A good example would be if everyone in the world is using a 10 pixel banner across the top of their VI icons to denote module -- a pretty common practice. I release a series of libraries over years where all of my banners are at the bottom of the icon. My libraries get a good reputation in the community... everyone recognizes my icons because my banners are at the bottom. Then you release a new library -- doesn't duplicate any of my functionality, doesn't copy any of my code, doesn't use any of my glyphs, doesn't match any of my connector panes even -- with your banners at the bottom. Depending upon just how strongly "banner at bottom" has become associated with me and my reputation, you might be liable for violations of trade dress.

[greatwall]

Hi,

Thank you for your great work.

I am learning this state pattern, and try to add a "report" state in to the example. but I can't return to idle state except the "send idle transition" button is pressed.

if I doesn't add "update from process.vi" like running state, how to automatecally return to idle state. not stay report state.

Thanks in advance.

[dostini]

I've been playing around with the state actor and have had some success with it. I'm at the point now where I'm looking at refactoring some old code to use this. The old code is a "Test Module" actor, which is a parent object (inheriting from Actor.lvclass) in a plugin architecture, i.e. it implements common behaviour and actual test modules inherit from it to do their things.

In the State Actor pattern implementation, I have a Context actor with the various States inheriting from the Context - these actors comprise the "Test Module" ancestor.

My problem comes when considering how each concrete Test Module will inherit from it to do useful things. The only half-way useful way I can think of is that each module implements children of each Test Module State object (i.e. a child module would be comprised of a bunch of objects that each inherit from the varioius Test Module State objects).

I'm having trouble conceiving of how to economically implement common module-specific code in these modules. For example, Stop Core.vi: the Context object would implement Stopping behaviour that's common to all modules, but each module would need to have identical Stop Core.vis in each module's State object so that it would implement its own specific stopping behaviour regardless of which state it's in. That also applies to Substitute Actor, Handle Last Ack core, Handle error and Receive message. And those are just the Actor methods!

What am I missing? Any insight would be greatly appreciated.

[dostini]

Ah yes: what I'm missing is Delegation.

Oh dear...

[aa82]

I've come across a sticky issue when using the state pattern design within the actor framework. I have created my own finite state machine actor instead of using the one below for extension purposes, but how I change state is practically identical. However, I am running into curious type issues with the call parent node.

The issue that I am seeing occurs anytime you call the "Change State.vi" method in a dynamic dispatch VI with the call parent node. If you do so, you'll get a message like this:

VI Errors: This dynamic dispatch VI does not unconditionally invoke the Call Parent Method node.

Block Diagram Errors: Call Parent Method '<method name>': Run-time type not propagated from dynamic input to Call Parent Node

From what I can tell, none of the problems described in the "Details" section of the help window apply.

To easily see this, simply create a "Pre Launch Init.vi" method override in the "State Actor.lvclass" class and then call the "Change State.vi" method within this VI. You'll then see this error. I have found no way of getting rid of this error, and I don't completely understand it. Using the Pre Launch Init.vi" method to set the initial state is a nice way to handle the finite state machine initialization, which is a way to not require the calling VI to know the initial state of the FSM. This issue prevents this (as well as in the "Actor Core.vi" method) and also prevents any call parent node existing in a child state's dynamic dispatch VI.

Any thoughts on how to resolve this? Is this simply a limitation of LabVIEW? Is this a bug?

Should I post this question in the Actor Framework discussion forum?

Thanks!

[AristosQueue (NI)]

---

@aa82 wrote:
Any thoughts on how to resolve this? Is this simply a limitation of LabVIEW? Is this a bug?

---

It is not a limitation of LabVIEW. It is an optional setting deliberately enabled on that particular method.

When that setting is enabled, then all overrides must include the Call Parent Node (CPN). That call cannot be inside any structure nodes and it must be wired with the dynamic dispatch wire (look for the gray background behind the wire... that gray background has to connect to the dynamic dispatch input terminal of the CPN).

That setting is something like "Require overrides to unconditionally call parent" ... I forget the exact name of it... you set it in the Class Properties on the particular method in the ancestor class.

[AristosQueue (NI)]

To be clear, I don't know who wrote your Change State.vi or why they turned that option on. It isn't part of the core AF. Depending upon the architecture of your system, it *might* be safe to turn it off, but you'd need to ask your architect.

[aa82]

Did you try what I mentioned?

Install the state pattern actor (version 1.1.0.10). Place the "Change State.vi" method in either the already created "Actor Core.vi" method or in a newly created "Pre Launch Init.vi" method. This is all you have to do to observe the error. It isn't about the require override method to call the parent node setting. It's why is this error being generated? Why does the call parent node prevent a change of subtype in the VI it's located in?