Reducing the number of messages for a UI Actor

[drjdpowell]

AristosQueue wrote:

That's pretty much a no-go in the AF since the actor data is all up in the parent's Actor Core and the framework rules it out from being anywhere else -- no one else but that loop can dequeue messages from the queue.

I thought you'd have that escape route guarded .  Still some options for the foolish, though.  Make a child of Message who's Do.vi method posts itself to a User Event, and have a "DoForReal.vi" method, called in the Event Structure, that is overridden in child messages.  The Parent "Actor Core" becomes the message forwarder, and is passed a dummy Actor object that just contains the User Event (the real Actor object is entrusted to the Event Structure loop). 

[AristosQueue (NI)]

drjdpowell wrote:

Still some options for the foolish, though.

Not necessarily foolish. But you're not really going to solve the root problem... you're going to have an Event Structure that gets a message in the event data. You have a local copy of the object that gets passed into the Do.vi. Inside that Do.vi it can't do anything to the Actor Core VI *unless* you've packaged a bunch of user event refnums inside the local copy of the object. But... hah... if you've done that... why didn't you just package those same event refnums into the *real* object that you passed to the call parent node? Then you could have just used those user events in the first Do.vi.

This whole thing gets lots LOTS easier if we just had interfaces, and I realize that lots of folks are chaffing against that limitation. I wish I could do something to alleviate that itching but my hands are tied for now by other project priorities. In the meantime, fighting against the lack fo interfaces by making more arcane code sometimes feels like you've made things better, but in my observation, it rarely actually makes things better. It just moves the bubble under the plastic.

[drjdpowell]

AristosQueue wrote:

Inside that Do.vi it can't do anything to the Actor Core VI *unless* you've packaged a bunch of user event refnums inside the local copy of the object.

In that case I might drop the Command Pattern for these UI messages; instead of a "DoForReal" dynamic dispatch method, I'll have various static "Read" methods, and do the calling of Actor-object methods directly in the Event case.

It's too bad there isn't a way to make Events and Command-Pattern Messages interoperate more closely; they seem very analogous to each other.