Property Loader Results Including File Loaded

[LVB]

I am looking to do some reporting and validation on the items loaded by a property loader step.  I would like to determine the following:

• Path of the file that was used to load properties?
• This could be multiple locations due to search directories.  I am currently using an expression of "<File>.txt".
• List of items that could not be imported?
• The Result container of the step has NumPropertiesRead and NumPropertiesApplied.  How can I determine which items were not loaded?

Any advice is appreciated.

Thanks!

[RaviShrigiri]

You can do the following :

The source code for property loader :

C:\Program Files (x86)\National Instruments\TestStand 2012\Components\StepTypes\Database\TSDBComponents.cws

and the file limitloader.c

You can modify this for your additional validations.

[Norbert_B]

To add some information:

The path for the file is generated in TS, so you have access to that directly in your execution. The most simple approach to log this is using "Additional Results".

The property you want to log is in the PropertyLoader step the lookup "Step.File.Path".

Regarding the matching/mismatching property values, you have to adopt the property loader step itself. Before going down the road, Sun is suggesting, i recommend you to create a copy of the default step type and change the copy. DO NOT MODIFY the original PropertyLoader Step Type!

thanks,

Norbert

[LVB]

---

@Norbert_B wrote:

To add some information:

The path for the file is generated in TS, so you have access to that directly in your execution. The most simple approach to log this is using "Additional Results".

The property you want to log is in the PropertyLoader step the lookup "Step.File.Path".

---

When I log the Step.File.Path as an addditional result, I do not see the full path that was resolved by TestStand.  The value is the same as the edit time "relative path".

Thanks,

Brian

[Norbert_B]

Brian,

ok, then you only inserted a relative path there. A relative path relates to the path of the sequence file. So it is possible that you write an expression as additional result querying the sequence file path and the adding the relative path of the property loader file path.

The problem could be that the relative path steps up a directory level ("../<filename>") which will be an effort to implement a "path parser" as expression. Possible, but worksome.

Norbert

[LVB]

---

@Norbert_B wrote:

So it is possible that you write an expression as additional result querying the sequence file path and the adding the relative path of the property loader file path.

The problem could be that the relative path steps up a directory level ("../<filename>") which will be an effort to implement a "path parser" as expression. 

---

Norbert,

Thanks for the response, it seems the best approach would be an Expression to locate the limit file and pass that to the property loader as a variable.  My understanding is the property loader uses the search directories to locate the file if it is not next to the sequence file.

Is it possible for TestStand to resolve relative paths in an Expression?  I haven't seen any examples of this and most suggestions are to use a code module or string manipulation expressions in TS.

Brian

[Norbert_B]

Brian,

OK, i have to correct something:

If going for Step.File.Path, you expect the property loader step to load a static file. The path information can be relative though.

If going for "Evaluate(Step.File.FileExpr)", you can use a dynamic expression to build the file name/path. This can be relative, too.

If a path is relative, TS starts looking for the file using the search directories (expect it is already loaded, incomplete list):

Sequence File folder

Workspace File folder

TS Public folder

Public TS Components folder, including subfolders

You can configure those search directories, but keep the list short as loading times can be effected significantly, esp. when including network drives.

Obviously, the DLL of the property loader step takes this information and builds the complete path internally. At least, i have never seen the complete path in TS itself when debugging. So in the case you really need the complete path, you should follow Sun's suggestion to analyze and adopt the TSDBComponents project using LabWindows/CVI.

Norbert