Caller enqueuer goes missing

[PsyenceFact]

I have two actors derived from a common parent that are used to provide UIs for two separate tools.  In both cases they are launched as nested actors in the Actor Core of their parent, before Call Parent Method.  The caller enqueuer is stored in the private data for each of these UI actors and is set using Bundle By Name in Pre Launch Init.  I have checked in both cases that the enqueuer returns FALSE using Equals Not A RefNum from the Message Queue pallette.

If I then do the same check at the very start of the UI Actor Core, in one case I get FALSE as expected.  In the other case I get TRUE, i.e. caller enqueuer has mysteriously become not a refnum.  Everything else runs as expected, but I have to use Read Caller Enqueuer again in Actor Core in this case,

I have been through my projects with a fine toothcomb and can not find any differences between the two in terms of inheritance, scope, methodology, etc.  The only exception is that for the actor with the missing enqueuer, the enqueuer is the first field in its private data whereas for the good actor, it is the last.

I have also created a much more simple third UI actor but can not reproduce the issue.  I'm a bit unwilling to start again with the misbehaving actor as there's a fair amount of work involved.

Can anyone make any suggestions as to what may have happened to the missing enqueuer?

Andy

[Oli_Wachno]

Where exactly is the enqueuer stored?

Seems to me, you have the caller enqueuer both defined as a property of the parent class and the child class.

So PreLaunchInit writes to the property of the child the Actor Core parent call reads form the parents properties.

Is this possible?

[PsyenceFact]

Thanks for the reply Oli,

The enqueuer isn't stored in the parent class at all.  Not all children make use of it so I decided to put it in the individual child private data as required.

However, I am now revisiting the question of why I thought it shouldn't go in the parent class!

Andy

[Oli_Wachno]

After having a second thought (ans an espresso...)

why are you storing the caller enqueuer in the child’s properties at all? You can always get it from the Actor object by using the SubVI.

Not that it explains the behaviour you’re seeing...

BTW... what happens in the patent pre-launch?

[PsyenceFact]

Nothing in Pre Launch Init of the parent.

I really can't remember what logic compelled me to store the enqueuer in the first place and I think your suggestion of retrieving it as required is probably best, so Kudos for that!

You're right about it not explaining the original behaviour though.

Andy

[Oli_Wachno · Accepted solution]

Earlier you stated that the private data of the two actors only differ in the order of data elements in the cluster. Have you tried reordering on the misbehaving one to see if this changes anything ?

[PsyenceFact]

---

@Oli_Wachno wrote:

Have you tried reordering on the misbehaving one to see if this changes anything ?

---

Hadn't tried before but I have now.  Issue goes away !??!  Switch it back to the first element, issue comes back.  That's weird.

I haven't got time to pursue this further, and I'm going to use your suggestion of obtaining the parent enqueuer as and when I need it so I'll leave this for now.

Thanks for your input!

Andy

[Taggart]

While the behavior you are describing does sound odd ( if I understand your description correctly), I think the best solution is to use the framework as intended and not store the enqueuer in the child's private data and use the accessor VI from the Actor class. Not using it is simply confusing and causes you to carry around redundant data.  It's a code smell (although in this case it is more than a smell because it doesn't indicate a potential problem, it is a definite problem)

Just using the Actor accessor method will result in better cleaner code and will make future you (or whoever inherits this code) a lot happier.

Since any actor can always call the Actor classes Get Caller Method, I see no situation where storing the caller's enqueuer in the child makes any sense at all. If you do feel the need, then I would suggest you are not using the framework correctly or at least not as intended.  Then again I don't know everything, so if you have a specific use case I would be interested to hear it.