Feature Request: Automatically increase call chain index by 1 when Logger is running from a Packed Project Library

[DanielAllis]

We have made hard coded changes to our local code to increase the call chain index by +1 to avoid getting the packed project library included in the call chain. I'm not entirely sure how to implement this in a clean way, so before I invested a bunch of time I thought I could submit here to see if there was any interest.

[DanielAllis]

Did a little looking after posting this and found that there is a VI property "IsInPackedLibrary" that could be used to conditionally set the call chain in the following:

• Debug.vi
• Error.vi
• Fatal.vi
• Info.vi
• Trace.vi
• warn.vi
• Catch Error.vi
• Mask Errors.vi

Alternatively, this property could be read the first time manager.vi is called and added to the uninitialized shift registers. Each time the "Log" state is used, the call chain string can be stripped by one level. This would require that levels of the call chain would need to be passed to the MGR, so it would still touch all the VIs above.

I'm not as familiar with the overhead associated with reading this VI property, so not sure if one is better than the other. Surely making the change only in one place has it's advantages.

[volks73]

Thank you for the feature request and some investigation.

@DanielAllis Is the IsInPackedLibrary a VI script only property, i.e. is it blue or yellow in color on the block diagram?

If it is a VI script only property, then it cannot be used for the library because that is only possible in the development environment. Otherwise, that property would make it relatively easy to change the call chain index.

Is there a chance another user would want to include the PPL in the call chain? If so, then maybe a configuration for the call chain index can be added as part of the Logger initialization/configuration steps.

[DanielAllis]

@volks73 the property node is supported in the runtime environment (yellow banner).

That's a good question. What about grabbing two-levels of the call chain and concatenating if the logger vi is called from a PPL? This would always ensure both the calling VI and the owning PPL would be included if Logger is called from a PPL.

[volks73]

@DanielAllis After a very quick review of the listed VIs and the current Call Chain implementation along with thinking about implementing this feature to accommodate the widest number of use cases, the easiest implementation would be to change the 0 constant to a control and make it an optional terminal on the logging VIs. This would allow the developer to specifically select "where" to start the call chain. However, this would mean that every instance of the logging VIs (Info, Trace, Warn, etc.) would need to have a value wired to it if it is different from the default. The solution would be to have the terminal's default value be -1, which indicates that the call chain index should be obtained from the configuration, i.e. the Manager FGV (same one used for level, verbosity, etc.). This way a global call chain index can be set by the developer during initialization, but if a specific call chain index is needed for a specific log message, the global configuration can be overwritten.

Would this implementation work for your PPL environment?

[DanielAllis]

I believe the changes you mentioned should work fine with one caveat. The Catch Error.vi implementation has a call chain index that is one greater than the others. At one time I knew exactly why, but now I can't remember.