How to display test progress in customized OI progress bar??

[>>>Srini<<<]

Hi all

From the deaf silence of group for my previous  question should i assume it is not possible to store/process the user configuration deatails in database instead of .ini file??

also please clarify me the following questions.

1. Is it possible to display the test progress in customized OI (like shown in the figure)

i used the method to get the number of steps.

axExecutionViewMgr.GetCaptionText(CaptionSources.CaptionSource_NumberOfSteps,true,""); ( but it returns null  i used it in precommand event of appln. mgr.)

but the teststand  should provide a event so that i can update the progressbar value according to number of steps/ steps completed in UI right??

2. The functionality of ABORT will abort the current execution. but when i say restart it should restart from step that is being aborted. but the current  restart functonality provided in test stand restart from very first step of sequence. is there any way to achieve this?.

3. I try to run sequence file programmatically using the following code

NationalInstruments.TestStand.Interop.API.Engine eg= axApplicationMgr.GetEngine ();

NationalInstruments.TestStand.Interop.API.SequenceFile s =eg.NewSequenceFile ();

s.Path ="D:\\Program Files\\National Instruments\\TestStand 3.1\\Examples\\Demo\\CreateDeleteUsers\\CreateDeleteUsers.seq";

eg.NewExecution (s,"CreateDeleteUsers.seq",

null,true,0,null,null,null);

but it show the following error

An unhandled exception of type 'System.Runtime.InteropServices.COMException' occurred in TestExec.exe

Additional information: Unknown function or sequence name 'CreateDeleteUsers.seq'.

have i anything missed in the code??

Thanks in Advance

Srini

[SachaE]

Hi,

  not entirely sure which programming language you're using, but there's a large bunch of shipping operator interfaces with TestStand, so that should get you going on how the setup works (i.e. automatically loading and running a sequence file is done with calls to GetSeqeunceFileEx, not NewSequenceFile.) so the shipping operator interface code should give you a roadmap.

Also the TestStand Help has a large section on writing an operator interface with the TestStand 3.x ActiveX manager controls.

As far as a placeholder for when a step has executed, and you want to update a progress bar, then you'll have to calculate from the sequence how many steps there are in each of the step groups (from a sequencefile handle you can get the particular sequence (such as MainSequence) and then find the number of steps (method for this from the sequence object) then on each step, find out if it's a sequence call step type. If it is, then see if you can track through to the next sequence etc etc. This usually involves a little recusrion since it's like browsing through a tree structure. That would give you a total number of steps. Working from the sequence display control will only tell you your mainsequence (or whatever the current view is) so you could work with that, but if you have a seqeuncecall step in there that takes 20 minutes to run, and your mainsequence only has 5 steps in it, then the progress bar won't be particularly effective at displaying how far through you are.

Then put in a callback in the process model of processmodelpoststep. After ever step in a client sequence executes, you can increment a counter and make postuimessageex from a thread object (Runstate.Thread).

Your operator interface code would then pick that up as a user message, with an event code you specify (use 10000 and above) and you can take the number from the message (UIMsg object) and update your custom progress bar accordingly.

If you have sequencecall steps that are dynamic (i.e. using expressions to calculate which sequence / seqeuncefile to run with) then the tree approach isn't going to be that great for you, since you'll have to rely on that being one step, rather than lots of them, and that would really throw out your calculations and post step actions, (would be generating more and more of them that you've initially calculated there are steps going to be called), in which case you might want to put the callbacks as SequenceFilePostStep callbacks so that they only get called by steps in your approriate sequence files. (This would mean dynamic calls would have to be calling separate sequencefiles.)

Restarting from a particular step requires storing that step index somewhere - very difficult when it comes through a calling chain.

I'd recommend writing to the runstate.sequencefile object set to make a permanent record of the call chain at each point, and place a statement step to perform a goto (but not the actual "Goto" step type at the start of each sequence you're calling (something like a statement step that says Runstate.NextStepIndex = locals.count).

Hope that helps.

Thanks

Sacha