NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Changing the type of a step does not change associated code module

I created two custom step types, StepType1 and StepType2, each of which has C++ code module defined: StepType1 calls Function1 and StepType2 calls Function2 in my C++ DLL. I disabled "Specify Module" for both step types because I want them to be hidden to the user. I also have Edit substeps for both step types so that the user can edit some specific properties of each step type. Now I create a step of StepType1 using sequence editor and bring up step properties dialog by right-clicking the step and select "Properties..." menu. In "General" tab, I press "Change Type" button and change step type to StepType2. The step type is changed from StepType1 to StepType2, and the dialog for editing StepType2 is displayed if I want to edit this step. So far so good. But when I run this step, it calls Function1 rather than Function2. So changing step type does not change associated code module which is obvously wrong for my custom step types. Is there any property I have to set when I create my custom step type so that when a step of this type is changed, the associated code module is also changed? If not, then is there a way to disable the "Change Type" button in the step properties dialog for the step type that I do not allow users to change type because I know it won't work due to code module problem?
0 Kudos
Message 1 of 6
(2,962 Views)
I've found a workaroud for this problem. When we change the type of one step to another type in sequence editor, the code module remains unchanged, but all the substeps are changed. So I created custom substep for both custom step types, i.e., StepType1 and StepType2. Give these two custom substep the same name, say, "IndirectCodeModule".  Each custom substep calls original code module function, i.e., Function1 and Function2. Redefine the code module of both custom step types to call a new function "ExecuteCustomSubstep" exported from the DLL. This function obtains step object from input parameter sequence context and calls API "ExecuteCustomSubstep". This API takes substep index as input parameter. It's not difficult to get step type of the step and retrieve  a substep named "IndirectCodeModule" and therefore get the index of this custom substep. Now both step1 of StepType1 and step2 of StepType2 will  call function "ExecuteCustomSubstep" when they are executed, but "ExecuteCustomSubstep" will invoke "Function1" for step1 and will invoke "Function2" for step2. When we change step1 from StepType1 to StepType2,  the code module will still invoke "ExecuteCustomSubstep", but "ExecuteCustomSubstep" will in turn invoke "Function2".
0 Kudos
Message 2 of 6
(2,952 Views)

Hi,

Just to add to this, you can use the PostSubStep instead of the code module.

 

Regard

Ray Farmer

Regards
Ray Farmer
0 Kudos
Message 3 of 6
(2,914 Views)
Hi Ray, thank you very much  for the answer to my question. This will work since changing step type will changing substeps of the step type as well. Here I  have a few issues to bring up for further discussion.

1) If the custom step already has a post-substep to call, and we create another post-substep to invoke the code module, then which one will be executed first? I guess it depends on which one appears first in the list  of post-substeps. So if we use post-substep to invoke code module, this substep must be put at the top of all post-substeps.

2) Logically, the code that implements the functionality of a custom step type should be invoked as the code module of the step. For example a custom step type that executes a Perl script file has code module to call Perl API to invoke the script file, and a custom step type that executes a Tcl script has code module to call Tcl API to do the job. For these two custom step types, we hide the code module to prevent  users from changing it. When we change a step from Perl type to Tcl type, we expect that TestStand is responsible for changing the code module behide as well. Do you think it is a legitimate requirement?

3) My current implementation uses the way I described in my last post. Every custom step type that has a hidden code module calls the same function ExecuteCustomSubstep in the same DLL, which in turn calls API ExecuteSubstep that invokes custom substep, and custom substep of different step type will call different functions in different DLLs. Can you see any problem with this implementation? Or should I change to use post-substep?

Your comments are greatly appreciated.

maplebridge
0 Kudos
Message 4 of 6
(2,907 Views)
Maplebird,

Using the PostSubStep, as Ray suggested, is the preferred method for designating a code module for a StepType because of what you discovered by changing the step types.  The code module is not changed because for the default behavior, if you change the step type, you do not want the code module to change.  In answer to your other questions:

>> 1) If the custom step already has a post-substep to call, and we create another post-substep to invoke the code module, then which one will be executed first? I guess it depends on which one appears first in the list  of post-substeps. So if we use post-substep to invoke code module, this substep must be put at the top of all post-substeps.

This is correct, the PostSubSteps are executed in the order they are seen in the list.

>>
2) Logically, the code that implements the functionality of a custom step type should be invoked as the code module of the step. For example a custom step type that executes a Perl script file has code module to call Perl API to invoke the script file, and a custom step type that executes a Tcl script has code module to call Tcl API to do the job. For these two custom step types, we hide the code module to prevent  users from changing it. When we change a step from Perl type to Tcl type, we expect that TestStand is responsible for changing the code module behide as well. Do you think it is a legitimate requirement?

As mentioned above, the default behavior is to maintain the currently selected code module.  The preferred method is to use the PostSubStep if you want to designate a specific code module as the only callable code module.

>>
3) My current implementation uses the way I described in my last post. Every custom step type that has a hidden code module calls the same function ExecuteCustomSubstep in the same DLL, which in turn calls API ExecuteSubstep that invokes custom substep, and custom substep of different step type will call different functions in different DLLs. Can you see any problem with this implementation? Or should I change to use post-substep?

This method will work.  However, it may be easier to simply use the PostSubStep.  You will also avoid TestStand developers changing the module if you do not want them to use a code module.  You should Designate the Adapter to None, which will not allow a Module to be specified for the Step.  Many of the standard Step Types in TestStand use this method so that one module is always specified and cannot be altered.

Regards,

Tyler T.
0 Kudos
Message 5 of 6
(2,902 Views)
Tyler,

Thank you very much for your comments and suggestions.

maplebridge

0 Kudos
Message 6 of 6
(2,887 Views)