Dynamic dispatch of Actors

[London]

Hi All,

I am preparing for CLA exam and practising to use actor framework. I really appreciate if you can help out with following grey areas in my understanding.

Scenario is, there is a machine accessing a keypad - I have to develop a soft keypad to simulate the hardware.

So, in my thought process there is a root actor called ATM Controller at the top level. Then Keypad API actor nested to ATM controller. One of the requirement is, user should be able to switch between simulated keypad and physical keypad easily. Therefore I have designed Keypad SIM (simulated keypad) and Keypad PHY (physical keypad) Actors nested to Keypad API. They are also INHERITED from Keypad API. Please see the Actor tree attached. Keypad SIM broadcasts an abstract message (a string) upon pressing the key "E". 

Following are the list of issues I am having!

1. First, I was testing Keypad API & its nested actor - Keypad SIM (by launching Keypad API as the root actor). They did communicate i.e abstract message from keypad SIM was received at Keypad API. but when I closed the root's panel, it gave a fatal error by continuously poping in & out the Actor Core front panel on the screen. Soon as I changed inheritance to both inherit from Actor Core, (without being parent & child) it worked well. Any explanation?

2. Then I added the top layer, ATM Controller as the root actor and setup the Keypad API to send an abstract message (string). Now when I launch ATM controller, only that and Keypad SIM should popup and as I press the key "E" it should pass the string to the ATM controller via Keypad API (although it's front panel is not popeped out). But this abstract message is not received by the root actor. Could you please check the attached project and advise where the problem might be?

3. I am going to implement a method to control the "Simulation?" Boolean. so that ATM Controller can easily switch between software and hardware. Is this approach correct?

Many thanks in advance

[cbutcher · Accepted solution]

Hi London,

1. I'd say you want your two children to inherit from the Keypad API, but you shouldn't try to launch a Keypad API. Instead, you should launch either the SIM or PHY Actors as nested Actors of the ATM Controller. They both implement the interface exposed (via message) of the Keypad API, but you don't have to launch a (potentially abstract) Keypad API Actor.
2. It seemed to work fine for me, once I changed all of the Actor Core VIs (and one other VI - I don't remember which) to be shared-clone reentrant. This should have been the default for the overrides, did you manually create them? There were edit-time (compile) errors for me when I opened your project (perhaps a problem with saving and uploading?).
3. I don't *think* you have to be able to switch between simulated and physical setups at runtime (edit time is fine), but I haven't taken the CLA exam, so... maybe wait for a response from someone holding the certificate!

The code seemed to work ok following my changes in 2, but I suspect it may be more complicated than you really need to meet the requirements (or indeed, more complicated than required for a real application fulfilling these requirements). I didn't read closely through the Keypad API yet, but that's my feeling from a quick look.

As a side note, the New Value > Cluster to Array > Boolean Array to Number is really clever (I'll keep this in mind next time I want to find the value that changed in a cluster) but the handling code is pretty verbose. You could have done the following instead (I made C element 10 and left E as element 11, making 0 go from 10 to 9 in index):

I had to add a Quotient and Remainder to get rid of the "10" for 0, but otherwise it was fine. I suppose if I made the 0 the 0th element, and then removed the +1, that would be unnecessary (but I didn't think of that until I started typing this...)

[London]

Hi CButcher,

Many thanks for your response.

I revised LVOOP theory and now I understand your point - I can just call the child implementation from the root actor.

Thanks for your tip about the cluster handling code.