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