Injecting AF into OC (Old Code)

[Q7]

The fact that I have made 6 posts on here today should demonstrate the fact I am stuck... I would like to find an elegant way to begin using the Actor Framework while still using a QSM.

I curious who will have a response to this. I am trying to find a way to implement the Actor Framework into my project incrementally. Here's what I have in my brain:

Here is the general idea:

I have created an Actor class which is a clone of the nextGen AF. I already have all my "core" VIs being launched by a Launch Actor VI. The difference is that my Actor Core (bottom of pic) is empty for now. Instead, I have a QSM using the all too user friendly LapDog. It's messages are of my Messages.lvclass and in all the cases but one it is just a QSM. In the default case, however, there is a Do.vi that processes new messages sent in the AF philosophy.

The intent is to use the AF for new messages and messages that the AF works really well for (chains of messages especially, the type that gets people lost when looking at AF projects!). Hey, it's job security

Before I spend the next week in HEdoublehockeysticks staying up all hours to write all the messages, I would like to hear from anybody with comments. I figure there's no reason to use the 2011 AF for this as it will change in 2012 so I made my Actors "match" 2012 minus the fancy artwork. Hopefully it will be easier to update them in November...

[KuGr]

I am not very familiar with LapDog.  I did look at it some time ago and I follow LavaG where there is often a thread active on the subject.

That being said, it does not seem to unreasonable.  I am trying to think of downsides but can't quickly come up with any.

I am assuming the chains of messages are when one actor gets a message that changes its state and then it notifies another actor and so on? This is not specific to AF, just that AF has one single message processing loop vi that has lots of instances.  As I understand it, LapDog has a distinct message processing loop for each 'Actor'.  Only identical 'Actors' would share the same vi.  That is tough to tackle.  If you make the Do.vi non-reentrant you will serialize your message handling and might make debugging easier.  Do not use a Reply Message while inside a Do however.  You will lock up.

Once you change that, all of your Do.vi overrides have to be changed also.  Gets to be a pain with lots of messages.

Now you got me worried about AF-LV2012.

[Q7]

You're right, the changing of hundreds, maybe thousands of Do.VIs could be nasty. Plus I am missing out on the Message Maker tool by not usinf the official AF. I realized today, after finally implementing some of the above said plan, that making Do overrides is a pain in the rear without that tool.

Yes, LapDog has a message processing loop for each 'Actor'. Partly why I wanted to do away with my View and Model mediator loops in another post. It get's tough having so many Case Structures. Add to that the need for a string input instead of an enum. The elegance of the AF is all in that Do.vi. Sure, it takes a PhD to follow the messages through VIs but when you look at the project tree it is all right there. Dataflow?? umm...hmm...ok......but really, wanting to trace a complex, networked, multi-GUI, multi-instrument control program along a little orange wire seems a bit silly in this age anyway. Stephen and Allen still managed to find what may be the best way forward for a company stuck to that line. That's worth a seven figure bonus in my book. I'm talking to you Messrs. Berra, Medica, and Ms. Le. Give these guys their Millions!

If they don't let me know, we need a good programmer.

[AristosQueue (NI)]

jbjorlie wrote:

umm...hmm...ok......but really, wanting to trace a complex, networked, multi-GUI, multi-instrument control program along a little orange wire seems a bit silly in this age anyway.

Yes, in this age... but in a future age... 🙂 I've seen a sketch, and even a bit of prototyping, of a system that would let you follow messages like AF along the little orange wire. Years away, but much more than a pipe dream (pun intended).