flag to prevent sequence from being used as callback override

[warren_scott]

Imagine this as a scenario:

you write some code to work with the standard out-of-the-box process model. 

Then you need to later run this code using a different process model (or changes are made to whatever process model you are using).  With this new process model / changes to your existing process model you happen to have a new callback sequence, and that callback sequence happens to be named exactly the same as some other sequence in your client sequence file (that you wrote with no intention of it being a callback override). 

Now, when you try to run your client sequence file, you will either get errors because the callback parameters do not match up (for this random sequence that wasn't supposed to be a callback override).

Granted this can be avoided by having good naming conventions for sequences in your client sequence file and any process model callbacks you add, but sometimes you are not in control of one or either of those.

I suggest adding a property of a sequence that flags it as "not available to be used as a callback override" -- this way you can configure all your "never intended to be a callback override" client sequence file sequences as such, and you won't end up in this trap. 

Something like this:

[dug9000]

Is there a reason why it's not practical to use a longer name or a uniquifying prefix to make your callback names less likely to be accidentally used somewhere else? It seems like it would be a lot of work to go through a bunch of old files and have to set this setting on them. Or did you mean something different than that?

-Doug

[warren_scott]

We have internally decided to name all of our custom callbacks as "Company_Callback_XXXXXXXX" (been doing this for several years now) so we know they are ours, and that it is a callback (specifically to help get around this problem).  The namespace-prefixing works for process model stuff, but we can't reasonably require users to use some other fancy naming standard for sequences in their client code. 

The problem is we can't necessairly expect this naming standard to be followed on every process model that is coded by all other people (think trying to get code running on another different process model).  This is not helped any when NI has very loose naming conventions for it's out-of-the-box callbacks, and comes up with new callbacks like "fill in the blank something about report paths -- don't want to break BETA guidelines" that is a very generic name.  If we don't have protections against what should be allowed to be used as a callback override and NI releases process model changes that include new callbacks with similarly generic names, we are going to cause user problems sooner or later.

On swapping from one process model to another -- this is a difficult problem, and in some cases it flat out cannot be done depending on how different the processes are, but that's probably why there is configuration to require specific models, or just use whatever model the station is configured for.  Ideally we want to be able to know "sequence XXX is expected to be a callback override" and "sequence YYY is not expected to be a callback override".  Then at some time (maybe sequence analyzer) we can see whether for the current model, everything matches up (whether we have sequences we expect to be callback overrides but will not be used because the active model does not implement those callbacks, or we have name conflicts that the model wants to run as a callback but are flagged as not allowed), whether callback overrides have matching parameters).  Right now we kinda have this by naming all of our custom callbacks "Company_Callback_FOO", and making sure that any sequence called "Company_Callback_XXX" has a green icon next to it, but it falls short for things like "PreUUT" -- that one relies on people having enough knowledge about TS that they know that PreUUT is a "out-of-the-box" callback.

[WireWeaver]

I'm declining this idea due to lack of community support.