LabVIEW version of TestStand OI

[mrbean]

As a start, I'm trying to modify the 'Configure' menu.  I'd like to add a selection ("ATE Registration") that opens a dialog allowing the user to enter a number of paths, part numbers, etc. that are associated with the Test Station (the ATE) itself.  Would this require that I touch the VI "TestStand - Execute Menu Command" VI?  If so, what do you recommend?

[Dennis_Knutson]

Just to mention an alternative to doing all of this modification of code, you can easily add menu items to the Tools menu. Just select Tools>Customize. You can add a sequence to run, a sequence file, or command (exe). Creating a sequence file that calls the VI that makes the modification is probably the simplest. You've already got a sample sequence and VI and if you go this route, you don't have to modify the OI at all and you can run everything in the TestStand sequence editor and not just the OI.

[AllenP]

Another alternative solution is to add a Configuration Entry Point to your process model.  This sounds like a perfect use case for it.  You may be interested in this document:

http://zone.ni.com/devzone/devzoneweb.nsf/Opendoc?openagent&A14414191631C58D862567F5006774F6

[mrbean]

Anytime you are going to modify any NI-provided source code or configuration file, you need to copy the folder to a ../user directory.  I understand this.  However, does anyone have any good way of tracking changes via configuration management?  Our source code resides on a network drive (that all share through CM).  The NI apps (TestStand, CVI, LabVIEW) all seem to look in certain directories for various customizations (i.e. StationGlobals.ini, users.ini, etc).  Must these files reside in their respective directories (i.e. C:\Program Files\National Instruments\TestStand 3.5\Cfg) or user directories, and if you desire a modification, how can those configuration files be shared amongst all users?

[AllenP]

The User Components directory is defined in the Search Directories of TestStand.  You can change these if you wish by going to Configure >> Search Directories.

Many of the other configurations can be changed by going to the Configure >> Station Options, and going to the Preferences tab.

Hope this helps!

Allen P

NI

[RayFarmer]

Hi,

this application note maybe of some help to you, although its refers to the Full Operator Interface.

http://zone.ni.com/devzone/conceptd.nsf/webmain/9796C70D7C40C309862570AD005AEB56

regards

Ray Farmer

[mrbean]

I read and tried the steps outlined in the Configuration Entry Point  article you pointed me to.  I opened the SequentialModel.Seq, and added my 'ATE Registration' option.  It appears just as planned.  I have a few questions.  (1) Where (in the .seq) are the other Configure options (i.e. Adapters, Station Options, Search Directories, External Viewers)?, (2) Does the addition of another option affect the CommandKind_DefaultConfigureMenu_Set that is passed to my Full OI - Rebuild Menu Bar.vi, (3) I sent this in another post, but how can I test for user privilege and grey out all Configure options (except this new one I added) if the user is not the Administrator, (4) If I pass in several individual commands, instead of CommandKind_DefaultConfigureMenu_Set as mentioned above, but the SequentialModel.Seq shows the Configure Report, Database, Model, and my new option (ATE Registration), who has precedence? 

[Patrick_P.]

Hey Mr. Bean,

Only the last three options under the configure menu come from the process model as configuration entry points.  You can see this if you check what CommandKind_DefaultConfigureMenu_Set actually contains.  Again detailed information on each of these is located in the help under CommandKinds Enumeration.

CommandKind_ConfigureAdapters
CommandKind_ConfigureStationOptions
CommandKind_ConfigureSearchDirectories
CommandKind_ConfigureExternalViewers
CommandKind_Separator
CommandKind_ExecutionEntryPointInsertionMarker
CommandKind_ConfigurationEntryPointDefaultMenuInsertionMarker

As you can see the first couple of menu entries are the adapters, station options, etc.  The Command that actually inserts the configuration entry points is the CommandKind_ConfigurationEntryPointDefaultMenuInsertionMarker.  This inserts Report Options, Database Options, Model Options, and any other configuration entry points you have created.  If you add another configuration entry point, the default configure menu set isn't going to change at all, but it will still insert it because of the last command which inserts all configuration entry points.  

I'm not completely sure what you mean by who has precedence, but it would be possible to put in your own commands instead of passing in the default.  All of this is done in the rebuild menubar in the menu activation event case in the operator interface.  For example, you could put just CommandKind_ConfigurationEntryPointDefaultMenuInsertionMarker instead of passing the default command set.  This would only have your configuration entry points located underneath the Configure menu.  

Regarding permissions and disabling certain menu items, user permissions will do this for you. User permissions automatically allow or disable certain menu options depending on which permissions you select.  If you want to completely remove certain options from the menu based on user permissions, you could do this as well.  It would be possible to check who the current user is and create different menus according to which user is logged in.  One method of checking the current user is to get the Userdata property from the application manager.  You can convert this to a TS.User type, and then get various properties such as the login name or privileges from there.

Message Edited by Patrick P. on 06-02-2006 03:52 PM

[tadk]

>It would be possible to check who the current user is and create different menus according to which user is logged in.  One method of checking the current user is to get the Userdata >property from the application manager.  You can convert this to a TS.User type, and then get various properties such as the login name or privileges from there.

I have tried converting UserData to type TS.User, and it does expose user properties, but these properties do not seem to have any values.  If I connect the error cluster to the variant I am using to do this, I get one of those 'undefined errors at Type mismatch'  -2147352571 which also locks up the machine.

[Patrick_P.]

Hey tadk,

The method I posted was not actually the preferred method for getting the current user.  The best way to do it is to use the application manager, get a reference to the engine, and then from the engine get the current user.  This way you don't have to do any kind of data conversion.  From here you should be able to check login names or privileges.