Specify StyleSheet In SequentialModel

[chris86]

Hi,

I am using TestStand 2012 on a Windows 7 PC. I'm having trouble with dynamically specifying a StyleSheetPath (for XML report format) from within the SequentialModel. When specifying the path using Runstate.Execution.Report.StyleSheetPath, the correct style sheet is used when the report is displayed within TestStand on the Report tab of the completed execution. However, this style sheet is not saved to the report on disk. Instead, the report on disk uses the default style sheet as specified in Configure > Result Processing. 

What does work, is when I use Parameters.ReportOptions.RelStyleSheetPath from the ReportOptions callback in my client file (this causes the correct style sheet to be used both in TestStand and in the report on disk). Unfortunately this callback is empty within the SequentialModel, and does not seem to be executed unless overridden from a client file. 

We have a massive amount of client files, and adding the same ReportOptions callback to each of them is not ideal. I need a method for specifying the style sheet path once dynamically in the SequentialModel. Any help would be appreciated.

Regards,

Chris

[~jiggawax~]

If you want the default behavior to be the new stylesheet then implement it into the callback that is in the model.  That way, only those that override the callback will not get the behavior.  Everyone else, by default, will get the behavior.

In other words: In the Report Options callback put the code that changes Parameters.ReportOptions.RelStyleSheetPath.

Hope this helps,

[chris86]

Hi Jigg,

Unfortunately this does not work. I added steps to the ReportOptions callback inside the model file, and deleted the callback from my client file, so as to prevent the one in the model from being overridden. The code in the model callback is never executed, I added a popup just to simply verify this, and the popup never appears. 

Regards, 

Chris

[~jiggawax~]

You are correct.   I should have clarified.  The callback in the process model is just a place holder so that client files can override it.  You actually need to update the one in ReportGen_xml.seq.  That is the one that actually gets called if the client doesn't override it.

Hope this helps,

[chris86 · Accepted solution]

Hi Jigg,

ReportGen_xml.seq does not contain a ReportOptions callback. NI_ReportGenerator.seq does have the callback, and editing this does seem to work, thanks for pointing me in the right direction. 

Regards,

Chris

[~jiggawax~]

Awesome.  Glad it worked.  I forgot that they had changed it in the later versions of TS.

[chris86]

Cool... I will have to edit a local copy of NI_ReportGenerator.seq as we want it in our repository. Changing the default path to that file seems like a crazy endeavor as the path is determined dynamically in a bunch of different locations. Any ideas where I can set this up?

[~jiggawax~]

So you can copy the plugin and make your own with it's own name or put it in the public folder.  Because that is part of the plugin here is an overview of plugins:

http://zone.ni.com/reference/en-XX/help/370052M-01/tsfundamentals/infotopics/process_model_plugin_ar...

Any modifications should be moved to the public hierarchy.  In TestStand you have 3 main folders:

TestStand

TestStand Public

Cfg

TestStand is where all the native code resides

TestStand public has the same hierarchy as TestStand but contains only things you've changed

Cfg contains all the option and settings files

The way the search directories work is they look in public first and if not found there then look in TestStand.  So whenever I change something I just move it to the same hierarchical location in public then edit it.

[chris86]

I would prefer having the modified file in my custom project hierarchy, so I don't have to change the file in the TestStand Public directory every time we start a new project. That way, I would need to specify the custom path to TestStand somehow. 

[~jiggawax~]

Unfortunately, I think one of the rules for plugins is that they exist only within the plugins folder in either the public or teststand folder.  I believe this is due to the fact that they are called dynamically. 

This kind of outlines the rules:

http://zone.ni.com/reference/en-XX/help/370052K-01/tsfundamentals/infotopics/pmpcreatingplugins/

You can have a shared TestStand Public folder:

This document shows how to repoint the public folder location:

http://digital.ni.com/public.nsf/allkb/42A0D8B0DCEC64FE8625744F007F3A6D

 We have about 15 developers using the same public folder in our code repository.  It works out nicely because they all see the changes automatically.

Regards,