nt_inv-flash command

Syntax

 nt_inv-flash file.reference item.name{(options}

Parameter(s)

Best practices

How you use this, and the related tools/features, depends on your application.

Caution should be taken when using this command under any conditions besides the most simple case of a single, isolated program. Thoroughly read and understand this help topic as well the linked topics.

For example, consider if your application consists of a main program that calls sub1, which calls sub2, which calls sub3. If sub1 and sub2 are updated, what will be the consequences if a user starts running a new version of sub1, but continues to run the old version of sub2? A situation like this might occur if sub1 is invalidated and a user loads the new version, but then calls sub2 before it can be invalidated.

A similar situation using this same example might be a user running sub2, when sub1 and sub2 are invalidated. The user then returns to sub1 and calls sub2 again without returning from sub1. Now the user will be running the old version of sub1 and the new version of sub2.

You have to determine how your application's changes must be applied and run, otherwise it might abort.

Continuing with the same example: If the number of parameters sub2 takes is changed and if the old version of sub1 tries to call the version of sub2, it will abort. Common and named common variables also require this type of caution. Did you change the number of common variables or their order?

Finally, if your application uses triggers, then the same best practices apply. However, it is important to remember that the life of the trigger subroutine is dependent on the files that use the trigger.

By default, the latest version of a trigger is only picked up when it is first run and remains cached until all files referencing the trigger are closed. When a file is closed is dependent on your application, as well as settings such as set-remote-close and Load Trigger at Each File Open.

Example(s)

 nt_inv-flash bp testprogram

See also