“Generate Trace for Received Message.vi” access scope change

[AndreaV-Lsi]

Hi everybody,

In the “Async Methods Actors” package, I override the “Actor.lvclass” method “Receive Message.vi” to be able to execute the Message’s Do.vi in an Async fashion. Until before the refactoring of the Actor Framework to make it more PPL friendly, I was emulating the parent method behavior by calling the “Generate Trace for Received Message.vi” if the conditional disable symbol “AF_Debug_Trace” was set to TRUE:

After the refactoring, the access scope of the “Generate Trace for Received Message.vi” has been set to Private.

I was curious about the rationale behind this decision. I also see that a new public-scope VI “Generate Custom Trace.vi” was added. Was this VI intended to address my use case, given the inaccessibility of the other trace generation VIs? As far as I can tell, I will not be able to reproduce the “<receiver type> <receiver ID> received <message name>” trace format that “Generate Trace for Received Message.vi” uses. Any suggestions are welcome

[niACS]

Yes, you're supposed to use Generate Custom Trace. Since Receive Message is dynamic dispatch, we can reconsider if Generate Trace for Received Message.vi should be private. I'm inclined to leave it so, since it is ONLY intended for use in Receive Message.

[AndreaV-Lsi]

OK then I will do just as you did in the Network Endpoint Actors

I would have preferred keeping consistency with the trace format of the AF, though.

Cheers and thanks for the prompt response.

Andrea

[AndreaV-Lsi]

The rational of my very personal preference is based on the consideration that if "Receive Message.vi" is dynamic dispatch with protected scope the author of the library intends to allow subclasses to extend the functionality of the base class. Given the change in the scope of the tracing VIs cannot extend the functionality because some part of the functionality will be lost. But admittedly that is a subjective point of view.