Closing a step reference

Hello
What is the proper method to use to close an open sequence step reference? I can't seem to find one under any of the object classes methods.
thanks

If you are using Object Reference type Property Objects to store references, then there is no need to set those variables to nothing or null. When the variable leaves scope (i.e. when the sequence or execution finishes), TestStand will automatically release the references.
This is one advantage to using the TestStand API from a sequence, you don't have to worry about closing the references, because the Engine will do it for you.
Josh W.
Certified TestStand Architect
Formerly blue

Similar Messages

Do I need to close an opened step reference?

Hello,
I am programmatically renaming a step by getting a reference to the step using method "GetStepByName". Do I need to then close this reference after I am done renaming the step? If so, how? I do not see a corresponding close. Thanks
David Jenkinson

This is going to be specific to the environment you are using to get the reference. If you are doing this in a TestStand sequence, the reference will be automatically closed when you the variable goes out of scope. If you are using LabVIEW, you will need to use the Close Reference VI. In CVI, you will need to use the CA_DiscardObjHandle method. In C++, if you are using the StepPtr class, you do not need to do anything. In C# or VB.NET, you do not need to do anything since it will be automatically cleaned up by the garbage collector.
Allen P.
NI

Closing ADODB sub reference outs in VIs? (LV 8.5.1)

I had a question about closing references to items I have not explicitly opened.
e.g.
I create an ADODB connection object.
From that, I create an ADODB command object.
One of the Command properties is the Parameters reference. I do a parameters.Refresh and using count, I loop through a For loop getting Item references. For each Item reference, I get a parameter object.
One of the properties in the parameter object is a Properties reference. I do a refresh on that and then go into another For loop. For each Item reference, I get a property node.
OK, now that I've gone through getting/setting information, I need to start working my way out. The last property node had an item reference out from the properties node. Should I close that? The properties node itself had as a reference out, should that be closed? The Parameter node has a reference out, should that be closed? Finally, the Parameters node has a reference out, should I close that?
The command and connection nodes I explicitly opened, so I know I need to close them. But these other references, should I be closing them, or do I only need to close the references I explicitly created?
Thanks, Bob

"intp56" <[email protected]> wrote in message
news:[email protected]..
> I download LabSQL, it looks pretty close to what I want.
>  
I'd suggest to use it, and to send them your additional code in return if
you're alowed to do that... Or suggest what you are missing to the project,
so they can add it in later versions.
> I'm looking for a VI that queries a stored procedure to determine what the
parameters are, then creates a LabVIEW cluster with the correct datatypes.
The idea is to call that first to create the Parameters object, then use it
later, particularly for DML operations. (Say insert rows from a LV table.)
I've tried using ADO recordsets to insert large datasets, and found it's
performance to be lacking or unacceptable. I can insert several 1000 records
per second with successive calls to a stored procedure where I specify ahead
of time no result set.
Not sure how ADO does this. I vaguely recall something about it. I think the
values are send item by item, and I think there was a faster way to send the
data by using a variant that directly accepts an array... It's been a while
since I've messed around with that, and I might not have succeeded to get it
working. Googling for "ADO large data sets" or something might give some
clues.
> If I really have lots of rows to insert, then I've found it better to
prepare a file, move it to a place where the database can see it, and BULK
INSERT it asynchronously and report the results back later.
Can't imagine that this is the best way to do it, but it's a good
workaround.
> BTW, I liked the tip that any reference WIRE needs to be closed, that
gives me a nice rule to know what I need to closed.
But even if there is no wire comming out of a reference property, you still
need to close it. So: every "green" read property should be closed.
Regards,
Wiebe.

Release step reference acquired by GetStepByName

Hi,
I get a reference to a step object by calling GetStepByName. The help says, "release reference to object when you are done". However it is not told how to release it. I cannot find a function like ReleaseStep in the API. Same holds for GetSequenceByName. Is there a global function for releasing such objects?
I use GetSequenceFile in the same application and I can release its reference using ReleaseSequenceFile. However, there is not an equivalent function for releasing step and sequence references, or at least I couldn't find it.
I am currently working on customer site and appreciate any quick responses.
Cheers..
S. Eren BALCI
www.aselsan.com.tr
Solved!
Go to Solution.

TestStand uses COM objects and GetStepByName function return a COM object.
"release reference to object when you are done" should be done by using IUnknown::Release function of the COM object.
Sequence file object reference returned by GetSequenceFile is a special case where you need to call both ReleaseSequenceFile and IUnknown::Release function.
However, in many languages, there exists a smart class which acts as a wrapper for the underlying COM object.Ex: CComPtr. These smart classes will do the work of calling Release function and you dont have to expliclity call IUnknown::Release.
Also note that, if you are using GetStepByName, GetSequenceFile or GetSequenceByName in TestStand expression and storing the reference in an instance of Object Reference type variable, you need not call IUnknown::Release function since TestStand automatically calls IUnknown::Release for you.
- Shashidhar

Question on closing Front Panel references

I'm manipulating controls on the Front Panel of my VI. In doing this, I open a slew of references (to the VI, to the Front Panel, to its Panes, and to the objects on the Front Panel). Normally, before exiting the VI, I carefully close them (in LIFO order, of course), but a question has arisen:
I want to "export" a series of references to Boolean controls for use in succeeding VIs. No problem, while enumerating the controls (see above), I simply identify the Boolean references and build them into an array that I pass out. First question -- does anything "go wrong" if I also do a "Close Ref" in the main loop (after adding the reference to the array, of course)? [At present, I'm only doing a Close Ref on the non-Booleans]. Logic says this should be OK, as the Close Ref is mainly doing "garbage collection", and I've done a "copy" operation in building my array, but to a persistent structure.
Second question -- in my "cleanup" routine, I noticed I was "double-disposing" of the references, that is, I did a Close Ref on my array of Boolean References, but also was enumerating the entire Front Panel (as I did when I opened it) and disposing of the references that it found. Again, this should be no problem, but (in principle) I'm doing a Close Ref on two references to the Boolean control. It occurs to me that this is not really logical either -- I should be able to simply "abandon" the array of references -- although it takes up memory that can be "reclaimed" for other uses, the fact that it is an array of RefNums is a "so what" -- the contents of the array could have been a numeric or other "solid" data type.
Does this make sense? To summarize, what I'm trying to do is to "extract" some RefNums to Front Panel objects for later use. In the "extraction" process, I must open (and create references to) multiple objects, including RefNums to my "objects of interest". What I think I can (and should) do, once I've copied the RefNums I need, is to dispose (Close Ref) all of the RefNums that I opened during the extraction routine, and do something equivalent when I do the subsequent "cleanup" (which undoes any modifications I made as part of the extraction).
Comments welcome.
Bob Schor

I usually store the ref. at the beginning of my program, in Functional Globals, and i close them when the program does not need them any more.
I think this is the right approach. And it is simple

Step-by-step reference material

Adobe 8 Prof., Windows XP Pro, I am completely new to forms design and Adobe. Have converted a WORD doc (multi page employment package)to a PDF form in LiveCycle thats close to what I want, but fields out of seq and Submit by Email only returns XML data and would like the full form complete
with data. Is there any good, simplified, reference material that a complete novice could use to at least get the basics of form design? Thanks.

You have to create the search help exit for the search help 'PRPM'.
Follow the below link to create the search help exit.
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee52446011d189700000e8322d00/frameset.htm
Thanks,
Srinivas

Opening/Closing Queue Reference By Name

I'm curious if opening and closing a queue reference to put information onto the queue, using the queue name -> obtain queue -> enqueue -> release queue(Non Force) is problematic. I thought i saw a thread a long time ago that opening/closing a reference to a queue over and over could lead to a memory leak, even if the original queue never was released. Obviously, i'm ignoring the general pass the wire(by value) correct labview way.
Instead of opening/closing using the queue name i could also wrap the queue reference in a FG after originally creating it and work on the reference that way. Ignoring the "right way to do it" are there still downsides, other than programing correctly, to open/closing queue reference's in this fashion such as memory leaks.

PaulG. wrote:
I have never heard of any unwanted consequences of repeatedly opening and closing any reference. The trick is to make sure a reference gets closed when no longer needed. I don't see any reason not to implement queues the ways you describe. I've done all three and haven't had any issues that I know of. If opening and closing a queue reference repeatedly caused a memory leak that would be considered a bug.
I have to disagree here. A couple of years ago I was using a DAQmx Write with "autostart" option set to TRUE in a loop (ca. 100ms timing) to constantly make sure, that in application standby my Digital Outputs kept the values they ought to have. This reproducibly caused a blue screen on Windows after 6 hours of the program running in standby. As it turned out, LabVIEW was using a new reference to the task for every call of the Write, because with autostart set to TRUE it had to create the task beforehand and close it afterwards. After the mentioned peroiod of time, LabVIEW ran out of reference numbers, as the support explained to me.
Of course, even LabVIEW Help says to avoid using autostart=TRUE with DAQmx VIs in a loop, but only because of the overhead the repeated Create and Clear is consuming. Naturally, I have learned that the hard way now.
So - Create the reference once, use that same reference all the time (FG is fine, I think - I use this method for obtaining my logfile reference all over the place!) and close it only, when you don't really need it anymore.

Closing references out of order?

I am filling a tree control from a Sub-VI, and I would like to use the DeferPanelUpdates property while I do that. I would like to put the DeferPanelUpdates property node in the sub-vi so the main vi's block diagram isn't cluttered with it. So since I already pass a reference to the tree control, I get it's OwningVI, and the FrontPanel from that.
The help for OwningVI says to close the reference to it when you're done using it. But since I get the panel reference from it, do I have wait until I close the panel reference before closing the VI reference? I'm just not sure when I am "done" with the VI reference, if you know what i mean...
Also, do I need to wire all the error terminals on the property nodes? If the tree refnum is invalid, would OwningVI and thus FrontPanel also return invalid refnums? If that were the case, I could just check the last property node's error terminal.
Any ideas?
BTW, I found out about DeferPanelUpdates on one of Darren's Nuggets. From there, there is a link to a thread about when to close references. It didn't say anything about what to do about references obtained from other references though.
Thanks,
John
Attachments:
tree-vi-panel-refs.gif ‏11 KB

Good question, John. In your case, it is safe to close the VI reference at whatever time you wish. In my experience *with VI Server* (these suggestions may not apply with other reference types, like ActiveX), if you get references as properties from other references, you can close them in whatever order you wish. The only time it would be bad to close the VI reference first would be if you obtained it from an Open VI Reference function, and that was the only reference open to the VI. If you close that reference to the VI, then there are no other references to it, and the VI is not in memory (assuming you don't have it open)...at that point, any subsequent property reads/writes would return an error.
As far as your question about error chaining, you should definitely wire the errors...there are many reasons you could get errors from property nodes...invalid references, trying to set some properties while the VI is running, certain properties that don't work with objects configured a certain way...don't ever skimp on your error handling, *especially* with VI Server!
When I work with VI Server and a bunch of different class properties, I find it helps to keep my error chain straight, and route reference wires accordingly. It helps me keep with the program flow better...here's how I would have wired the diagram you gave above:
Hope this helps, and I'm glad you discovered my nugget about Defer Panel Updates. When doing code reviews of UI applications, that is probably the recommendation I've given the most times over the years...
-D
Message Edited by Darren on 01-23-2007 10:31 PM
Darren Nattinger, CLA
LabVIEW Artisan and Nugget Penman
Attachments:
straight_error.png ‏8 KB

Why does opening and closing FPGA references increase Windows XP handles by 3?

Hello.
We run a test system here that uses TestStand to communicate
to a number of Labview VI modules which in turn communicates to a
PXI-7833R FPGA. Everything has been working fine except after a long time running Labview would get an out of memory error. I discovered
after a particular VI was run 100,000 times, the number of handles in Windows XP Task
Manager grew to about 370,000. The number of threads and processes remains stable and normal. Closing Labview removes all the excessive handles.
I tried an experiment to create a standalone VI (ie: no TestStand) which simply opens the FPGA VI reference then closes the reference. This is repeated 4 times in the same VI. The number of handles in Windows XP Task
Manager increased by 12 each time the VI was run. No errors. This indicates closing the FPGA reference might not be working.
Why does this happen? Is there a way to avoid it? The version of Labview is 8.5.1.
Appreciate any help here. Thanks.
-Dave

could be related to this known issue--
FPGA FIFO reset behavior—When you use an FPGA target
emulator, FPGA FIFOs reset when the VI is stopped and then started
again. When you use an FPGA target with Interactive Front Panel
Communication, FPGA FIFOs do not reset when the FPGA VI is stopped and
then started again. To reset the FIFO, right-click the FPGA target in
the Project Explorer window and select Download
from the shortcut menu. When you control an FPGA VI using Programmatic
FPGA Interface Communication, use the Close FPGA VI Reference function
with the Close and Reset shortcut menu option selected or the Invoke Method with the Reset method selected to reset FPGA FIFOs
see Knowledgebase
Also remeber to load the FPGA Read/Write VI's dynamically from testStand and dump them after. Thechange to the data type causes the vi to need to recompile so it can't stay in memory if you need different types of data.
Message Edited by Jeff Bohrer on 10-27-2009 02:21 PM
Jeff

Steps for Period end closing

Hi All,
Can any one please provide me with the actual steps towards Period end Closing and year end closing for Financial Closing.By step I mean steps in order i.e which step will be followed by which one.
This is urgent
Pinee

Hi
http://www.sap-basis-abap.com/fico/sap-fi-month-end-and-year-end-activities.htm
First you will have to close the Posting period in the Materials Management side. To do this use the T.Code MMPV and give the period that needs to be Opened. Once this is done you will not be able to Post any Material Documents in the previous period.
Now at the Financial side you need to open the next period and at the same time you need to close the Previous period. This can be done in T.Code OB52
here is the list for FI/CO year end closing check list:
now i am sending one document with T.codes
CLOSING ACTIVITIES
1 Execute Report for Inter Company Activity & Journal Entries
2 Open posting period for next yr (T.Code: OB52)
3 Run Business Area's Assignment report. (T.Code: F.50)
4 Review list of recurring journal entries (T.Code: FBD3)
5 Execute Recurring Entries for A/R, A/P, G/L (T. Code: F.14)
6 Process Parked A/R, A/P, G/L accounting documents (T.Code: FBV0)
7 Final Cutoff for the Maintenance of Fixed Asset- Add Transfer and Retire (T.Code: ABUMN)
8 Run Depreciation in Test Run and post (T.Code: AFAB)
9 Verify Display Log for Depreciation Test Run (T.Code: AFBP)
10 Capitalize AUC Assets if needed (T.Code: AIAB, AIBU)
11 Enter Payroll Data to SAP (T.Code: CAT2)
12 Verify Depreciation Balances with GL balances (T.Code: ABST2)
13 Post Depreciation (T.Code: AFAB)
14 Execute Asset History Report, and retire assets if needed (T.Code: S_ALR_87011963, ABAVN)
15 Adjust specific depreciation areas if necessary (T.Code: ABCO)
16 Reconcile AM sub ledger with GL (T.Code: ABST2)
17 Check Bank Data (T.Code: S_P99_41000212)
18 Review AR Open Items (T.Code: FBL5N)
19 Review AP Open Items (FBL1N)
20 Execute Pending Invoices(T.Code: MRBP)
21 Clear Open Item for GRIR, freight (T.Code: F.13)
22 Reconciliation of Financial Documents and transactional figures (F.03)
23 Open new CO Posting Period: (T.Code: OKP1)
24 Compare current (cost estimates) with last current price (Moving Avg) (T.Code: OKBH)
25 Update current cost price to material master price field (T.Code: CK11N, CK24)
26 Process Freight charges, Match SD freight to actual (T.Code: V-31)
27 Review Internal Order Postings(T.Code: OKSA)
28 Settle All Orders (T.Code: KO88)
29 Verify All Post Goods Issue have been Invoiced (Billing Due List) (T.Code: VF04)
30 Review SD Billing Doc from prior month that have not yet been released to accounting (T.Code: F.2D)
31 Reconciliation of MM movements in Transit Intra-SAP to Non SAP
32 Reconcile PI Inventory with SAP (T.Code: MI07)
33 Perform Manual Adjustment if needed (T.Code: F-02, FB50)
34 Verify balance of the GR/IR account (T.Code: MB5S)
35 Post Accruals and Deferrals (T.Code: FBS1)
36 Clearing of Cancelled Documents (T.Code: F-03, F-32, F-44)
37 Check Profitability Segment Adjustment (T.Code: KISR)
38 Aging Report-Reconcile GL balances with sub ledger balances AP (T.code: FBL1N, FBL5N, FBL3N)
39 Check the check run numbers (T.Code: FCH1, FCHI)
40 Bank reconciliation Data (T.Code: FF67 & FEBA)
41 Enter Tax Journal Entry (T.Code: FB41)
42 Reconcile GL balances with sub ledger balances AR/MM/AP (T.Code: F.03)
43 Display Balance Sheet Adjustments (T.Code: F.5F)
44 Post Balance Sheet Adjustments (T.Code: F.5E)
45 Post Foreign Currency Valuation (foreign exchange) (T.Code: F.05)
46 Check generic cost centers for posting with wrong accounts
47 Correct wrong postings on generic cost centers
48 Check Validation dates for Cost Centers, Cost Elements, CO area (T.Code: GGB0)
49 Check COGI--for both month end and year end
50 Doubtful receivables (T.Code: F104)
51 Verify In-transit Inventory
52 Reconcile PA to G/L (T.Code: KE5U)
53 Post Cost Center Assessments and Distributions (T.Code: KSU5 & KSV5)
54 Run CO-FI Reconciliation to balance (T.Code: KALC)
55 Run BW reports P&L and Balance Sheet
56 Maintain CO yr variant (T.Code: KCRQ)
57 Fiscal Yr Balance carry forward AP/AR/AM (T.Code: F.07,
58 Fiscal Yr Balance carry forward CO (T.Code: CXS1)
59 Fiscal Yr balance carry forward FI (T.Code: F.16)
60 Fiscal Yr balance carry forward PCA (T.Code: 2KES)
61 Set Document number ranges - FI - new year (T.Code: OBH2, OBA7)
62 Set Document number ranges AP/AR - new year (OBA7)
63 Generate Financial statement Reports (T.Code:OB58) OR (T.Code: FSE2)
64 Change Fiscal Year For Assets (T.Code: AJRW)
65 Year end Closing-- Asset Accounting--final for year end (T.Code: AJAB)
66 Close CO Posting Period : (T.Code: OKP1)
67 Close Prior A/R Posting Period (T.Code: OB52)
68 Close Prior A/P Posting Period (T.Code: OB52)
69 Close Prior MM Posting Period (T.Code: OMSY)
70 Reverse accruals and deferrals for the new month (T.Code: F.81)
71 Reconciliation of Financial Documents from old fiscal year and new fiscal year (T.Code: FNSL)
72 Load Balances, Budget Data for Cost centers, sales
73 Update Retained Earning Account , balance carry fwd (T.Code: F.16)
Month end closing Activities
1. All the expenses including amortization, prepaid expenses, Preliminary expenses and accruals have been booked.
2. Complete Bank Reconciliation (T.Code: FF67)
3. Make sure that Sum of Inter company balances is Zero
4. Suspense Accounts should be cleared regularly.
5. Ensure that all documents related to MM & SD have been entered in system. (T.Code:F-22 & F-43)
6. Ensure that all billing documents are released to accounting.
7. Calculate Overheads on all process Orders (CO43)
8. Technically complete all process orders which are fully processed (CORM).
9. Calculate Variance (KKS1)à (Relevant only if Standard cost is calculated).
10. Settle all process orders which are technically complete (CO88).
11. Close All settled Process Orders
12. Close MM period (Transaction Code: MMPV).
13. Carry out GR/IR clearing (F.13) transaction
14. Depreciation Run (AFAB) has been carried out for the month
15. Close FI Posting period after the month end closing activity is over (T.Code:OB52)
Year end closing Activities:
1. Calculate production work in progress on process orders which are not technically complete. (CO88).
2. Carry out Assessment cycle for Cost Centers.(T.Code: KSUB)
3. All month end closing Activities should be carried out.
4. Carry Forward Balances to next year
(With TC: F.16 we can carry forward the balance to next year.
With TC: OBH2 copy the number ranges to next year
Open next year periods by selecting the Posting Period Variant.
then test by posting the transaction in F-02)
Hope ths helps
Please reward points
Sunil

Close reference needed for step object reference open? If so, how?

Hello,
We are using an activex method call to open an object reference to a step and programatically rename it. This is done many many times during our test run, thousands. We ran into an "out of memory" problem we had never seen before during a 72 hour test run, and in hunting down any possible memory leaks, I am wondering if a corresponding close is needed for the step reference open we are doing, and how. I have hunted around the different methods/properties, and can't seem to find if there is a step reference close. I have attached the specify module screen of the activex call which opens the step reference.
Thanks for any replies
David Jenkinson
Message Edited by david_jenkinson on 06-11-2007 05:07 PM
Attachments:
step reference specify module.png ‏25 KB

Hi David,
Setting a reference to nothing in TestStand will close it. However, if you are assigning a new value to the local it also frees the memory associated with the original value, making it so you don't need to assign it to nothing. I don't believe the source of the leak is in this step.
Test Engineer - CTA

LabVIEW prompts to save the vi when closing the reference

In our application, we - Open vi reference - finding its execution state - closing the vi reference. While closing, LV prompts to save the vi, how to avoid it. I can see option to enable LV prompt, but no option to skip it. We use 0x20 for now to avoid the loading dialog.
We appreciate your input
Thanks
Sas
Solved!
Go to Solution.

I have seen this in the past with scripting VIs and I tried to resolve it but couldn't. So my solution was just to supress the dialog temporarily. Darren posted over on LAVA a VI that does this.
http://lavag.org/topic/17845-silently-close-a-scripted-vi-with-unsaved-changes/#entry107546
I believe this just calls the private method App.UnattendedMode
Unofficial Forum Rules and Guidelines - Hooovahh - LabVIEW Overlord
If 10 out of 10 experts in any field say something is bad, you should probably take their opinion seriously.

UCCX 8 - Dramatic change in the Create File Document step that is used by the Create XML Document step in order to read an XML file

/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
For the last 5 years (and in IPCC3.x/4.x,UCCX/5.x/7.x) I've used the same basic subflow to read a XML document that contains holiday dates where the queue should be closed. I've re-used this script on 20+ client installs and it's always worked. The structure of the script allows you to pass the path and filename of the XML document as parameters to the subflow. (The document is in the repository)
I loaded this script in UCCX 8.0.2 recently and it crashed with a Java.IO error. It looked like it was trying to read the file system directly and not the repository. (In the Linux appliance model this kind of makes sense but why is the step trying to read the file system directly?)
So I open a TAC case (SR# 615243125) and TAC tells me that the method of using the Create File Document step is not supported anymore and that I should specify the filename directly in the Create XML Document step
The problem that I see (aside from having to edit all my scripts that use XML files) is that the Create XML Document step is looking for the input to be a type DOCUMENT and not a type STRING. This seems to imply that I have to hardcode the document in each script that I deploy for a customer. When it was a string it was easy to construct the full file path from parameters and pass to the subflow.
Questions to the group
#1 Am I missing something here?
#2 Do you assume that you'll be able to load a script that worked fine in UCCX 7 into UCCX 8 and that it should completely function when you're doing everything according to the step reference documentation.
#3 Cisco didn’t document this in any way that I can find.
#4 How can you use the Create XML Document step in a fashion that would let you construct the path of the file and the filename previously in the script so you could pass it to a subflow ? It would seem this functionality has been killed in UCCX 8
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
(Background)
Create File Document Step
The input filename is a STRING, could be an explicit path and filename in the repository or a variable that represents that path and string
The output of this step is a DOCUMENT to be used in the Create XML Document step
The string FILE_FullPathHolidayFiles references en_us\folderName\documentName.xml
The document was properly uploaded into the repository only, NOT trying to directly read c:\foo\blah…
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Table Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0in 5.4pt 0in 5.4pt;
mso-para-margin:0in;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
The create XML document input can only be a type DOCUMENT

#1 Am I missing something here?
You are mixing two different issues together here.
The Create File Document step is indeed not needed or supported for creating an XML document. That is why there is a unique step; to trigger XML parsing within the MIVR subsystem.
Accessing the file system is restricted to a single folder within the VOS model (i.e. 8.0+). This folder is not backed up, replicated, or cleaned up automatically. It was intended to give developers some FS access as a temporary swap location only.
#2 Do you assume that you'll be able to load a script that
worked fine in UCCX 7 into UCCX 8 and that it should completely
function when you're doing everything according to the step reference
documentation.
Assume nothing; read the documentation and attend one of the dozens of partner training sessions that CCBU put on advising of the upcoming changes.
#3 Cisco didn’t document this in any way that I can find.
You're right, I guess, on the Create File vs. XML Document step. AFAIK Cisco never wrote a notice into the Step Reference Guide explicitly stating that you cannot use the Create File Document although the documentation seemed pretty clear to me without it. File system restrictions are documented in the 8.0 release notes.
Scripting and Development Series: Volume 2, Editor Step ReferenceUse the Create XML Document step to create a logical document that maps a document to another document variable (where the document has already been pre-parsed as an XML document and is ready to be accessed by the Get XML Document Data step).Use this step before the Get XML Document Data step to obtain data from a document formatted using the Extensible Markup Language (XML).
#4 How can you use the Create XML Document step in a fashion that would
let you construct the path of the file and the filename previously in
the script so you could pass it to a subflow ? It would seem this functionality has been killed in UCCX 8
No it hasn't; just concatinate a string to build the Source Document parameter the step needs. Example: "DOC[" + myFilePath + "]"

When do VI and queue references become invalid?

Hi all,
I have a fairly complicated problem, so please bear with me.
1) I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs"). If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type. (The VI does other things too, but for simplicity only this is important.)
2) The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign". This VI effectively stores the references. The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
3) VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values). The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same. The VI ref can become invalid or not, depending on small changes, but is always reproducible. I assume there must be some similarity between VI and queue refs. After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes." In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ?? So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does). I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid. Anyone still following? This didn't solve the problem though. If I reproduce the same scenario using only one instance of the template VI, it works just fine. Furthermore, the VI and queue references are never closed, to aid analysis of the problem. Can anyone shine some light on what happens when a template VI terminates? Could this be the problem?
Unfortunately I cannot include the code.
Thank you whoever is able to make sense of this.
Christie

Christie wrote:
Hi all,
I have a fairly complicated problem, so please bear with me.
1) I have a reentrant SubVI (let's call it VI "Assign") that has an input cluster of (VI ref, queue ref) (let's call the cluster type "Refs"). If the VI ref is invalid (first execution), the VI ref and queue ref are assigned values and are passed on as an output cluster of same type. (The VI does other things too, but for simplicity only this is important.)
2) The VI that calls VI "Assign" (let's call it VI "Store") is not reentrant and has a local variable of type "Refs" that is wired to the input and output of VI "Assign". This VI effectively stores the references. The references returned by VI "Assign" are always valid right after the call, but after the problem condition described below, they are invalid at the start of all calls before they are passed to VI "Assign".
3) VI "Store" is called by multiple non-reentrant VIs, so the local variables of VI "Assign" retain their values (Has been tested and verified to retain their values). The VI causing the problem in this case is a template VI of which multiple copies are launched (let's call it VI "Template").
The problem is that the moment an instance of VI "Template" is closed, the queue reference becomes invalid, although the actual variant value of the reference remains the same. The VI ref can become invalid or not, depending on small changes, but is always reproducible. I assume there must be some similarity between VI and queue refs. After spending some time researching, the Labview help states for the Open VI Ref component "If you do not close this reference, it closes automatically after the top-level VI associated with this function executes." In this case I assumed it means that the moment the reentrant VI "Assign" finishes, the references will get cleared ?? So I made a non-reentrant VI (let's call it VI "NR Assign") that only assigns values to the references and VI "Assign" now calls this VI (It effectively does what I described VI "Assign" does). I keep this VI alive by using it in a VI which never terminates and since it never terminates, the references should never become invalid. Anyone still following? This didn't solve the problem though. If I reproduce the same scenario using only one instance of the template VI, it works just fine. Furthermore, the VI and queue references are never closed, to aid analysis of the problem. Can anyone shine some light on what happens when a template VI terminates? Could this be the problem?
Unfortunately I cannot include the code.
Thank you whoever is able to make sense of this.
Christie
All LabVIEW refnums do get deallocated automatically when the top-level VI in whose hierarchy the refnum was created goes idle (stops executing). You will have to make sure that the creation of a refnum is done inside a VI hierarchy that stays running for the entire time you want to use that refnum.
Rolf Kalbermatter
Message Edited by rolfk on 06-27-2007 11:52 AM
Rolf Kalbermatter
CIT Engineering Netherlands
a division of Test & Measurement Solutions

Stories and GOPs - Open or Closed

Hi All,
I'm currently working on a DVD which is going to make use of stories to play different versions of the main feature (one version playing a concert with interceding documentary sequences and one where the docs are skipped). I have been trying to figure out if closed or open GOPs are best to use.
I've always used closed GOPs in the past under the impression that it gave a higher quality image but I've come across some posts on other forums saying that open GOPs give a better end result.
I also thought that closed GOPs gave better accuracy fro stories etc but this also seems to be not the case according to some posts I've seen.
Any advice people have is greatly appreciated.
John

Hi John
Open and closed GOPs refers to how your encoder encodes your MPEG stream. Closed GOPs will reference frames withing the GOP only. Open GOPS will go reference frames outside that GOP for a more efficient encode. Its been said that Open GOPs gives a better encode. You'll have to do some test to find out what you think. It all depends on the source material your using.
When you create a story, it just references the original cell number for the new title so whether you used Open or closed GOPs won't make a difference. It essentially a virtual title.

Closing a step reference

Similar Messages

Maybe you are looking for