Closing references YES or NO

Hi all
My program contains a cluster with 120 controls (string, Boolean and number). Is it too much?
I need visibility or invisibly all controls during the program sometimes. In attachment is a simple example how it is work.
Is using block "close reference" better for LabView? Is my solution fastest or exist any better solution?
Is situation different with VISA sessions? Is possible to don't using block "VISA close"?
... LabView 7.0
Ivanek#
Attachments:
cluster references.vi ‏726 KB

Thanks for advice.
I tried it. Its working fine, but I forgot remember one thing. For example I need make visible 10 clusters and the rest must be invisible.
When I used "initialize array" its ok, but the rest of first array (5 elements) is grayed and I need make it invisible.
How to do it? I mean is any proper for changing size of array (initialized and grayed 10+5 elements).
Ivanek#
Attachments:
cluster references.vi ‏231 KB

Similar Messages

Guidance for closing references

I'm not clear about closing references in this case:
I have a reference to a control that is really a cluster of buttons.
I have a subroutine that reads each button and returns an array of booleans that says if the button has been pressed. In the subroutine I use the "Controls[]" property to get a control reference to each button.
Do I need to close each of the control references in the array from "Controls[]" before I leave my subroutine?
Thanks
Brad

Are you talking about ActiveX control ?
"Bmarsh" wrote in message
news:[email protected]..
> I'm not clear about closing references in this case:
>
> I have a reference to a control that is really a cluster of buttons.
>
> I have a subroutine that reads each button and returns an array of
> booleans that says if the button has been pressed. In the subroutine
> I use the "Controls[]" property to get a control reference to each
> button.
>
> Do I need to close each of the control references in the array from
> "Controls[]" before I leave my subroutine?
>
> Thanks
>
> Brad

Report generation toolkit and signal express user step : problem of closing reference in "Stop" event

Hi all,
I'm trying to make a package of Vis to easily make Excel reports with Signal Express. I'm working on LabVIEW 8.2.1.
I'm using the report generation toolkit, so I build a .llb from my project which contains all the hierarchy of my steps, but also the hierarchy of dynamic VIs called.
I have made some steps, like "Open Workbook", "Write Data", etc.
My steps run well, excepts one step : "Close Workbook".
If my "Close Workbook" step is firing on "Run" Signal Express event, I have no error, so my reference is properly closed.
But if my "Close Workbook" step is firing on "Stop" Signal Express event, I have an error "1", from "Generate Report Objectrepository.vi".
I feel that I'm trying to use a reference which has been killed in the "Stop" step...
I would like to know what exactly do Signal Express on "Stop" event and why my close function does'nt run well.
Thanks,
Callahan

Hi Callahan,
SignalExpress (SE for short) does the following on the Stop event:
1. Takes the list of parameters that SE found on your VI's connector pane, and sets the values that the user set from the "Run LabVIEW VI" configuration page, if any.
2. Then tells the VI that SE is running the Stop event by setting the Enum found on your VI's front panel. This in turn should produce some boolean values telling your VI to execute the Stop case.
3. The VI is then run, with those values and states.
4. SE checks to see if any errors where returned.
5. Since this is the Stop event, SE releases the reference to the VI which it possesses.
Questions for you would be, is the reference to your Workbook linked to a control on your connector pane, or held in a uninitialized Shift Register. If it's held in a Shift Register, SE would not be aware of it, and would not be able to affect that reference.
Hope that helps. Feel free to post your LLB if it doesn't.
Phil

Excel Get ActiveX References.vi and closing references -- grrr

I'm new to ActiveX stuff, but eager to learn!
The "grrr" in my Subject line is a reference to how I feel about LabVIEW's documentation from time to time. I'm a dinosaur who came from text-based programming, and did a fair amount of C coding, so sometimes with LabVIEW I'm left with this awful feeling in the pit of my stomach like, "Good grief! How much memory must LabVIEW be hogging up in the background when I use this vi?" or "What happens to those variables (wires) in that subVI when it completes but doesn't close? What are their statuses when I come back in the next time?" or "What if I put a lot of elements into that array the first time and then started from element zero the second time and just put in a few? What has happened with the memroy that was allocated when there were a lot of elements?"
Today I'm stewing about this "Excel Get ActiveX References.vi," and what happens to the "ActiveX references" it generates each time I call the subVI in which "Excel Get ActiveX References.vi" lives. I think that at least one of the "ActiveX references" it generates when I call it is of the type Excel._Application. Then there appears to be an Excel._Workbook, and others. You see, I've used "Excel Easy Report.vi" to put some data into an Excel spreadsheet, and I want to tell Excel to do a "Save" on the open spreadsheet. I think ActiveX is the (a) right way to do that, so I'm wading into the ActiveX fray... But this "Excel Get ActiveX References.vi" says in its help file, "Do not close ActiveX references opened with the Excel Get ActiveX References VI. References must remain open until the report is closed. Otherwise the error 3001 will occur." Well, these Excel workbooks that get created by my VI could well stay open until after my LabVIEW VI terminates!
So (finally), here are some of my quesitons:
1) When I go through my subVI once, pointing to one workbook, I'll get one set of references "created" or "opened" or whatever you call it when ActiveX references spring into existance. Now, when I exit the subVI, is it going to automatically try to "close" those ActiveX references? I don't suppose so, since subVI's stay in memory until the calling VI closes.
2) Now, I come back into my subVI a second time. New workbook gets created, so I get new references. Ok, fine. Uh oh! What happened to those old references? I suppose that if I didn't somehow save them off, I've probably lost the ability to get them back (maybe I'm wrong, but I don't need them back), but is LabVIEW going to "close" those old references (from previous times through the subVI) because I can't get to them anymore? Won't that cause the dreaded error 3001? If LabVIEW is not going to "close" them, what in tarnation happens to them (the old C programmer in me creeping back out)?? Now it's some oddball, orphaned reference, floating out there, hogging memory, waiting to make something crash intermittently and be a debugging nightmare?
3) Now, here's the real scary one. I think I might dodge the "error 3001" bullet in questions 1) and 2), but now let's say the user closes my LabVIEW application while Excel is still open. All those workbooks are still open. Presumably, all those ActiveX references I was not supposed to close are still open. I really hope that LabVIEW is decent enough to close/erase/delete/blow-away (whatever the right word is) all those ActiveX references which were opened/created by "Excel Get ActiveX References.vi" when my program terminates. But, oh no! Won't the error 3001 come along then? I suppose I can just dump it in the shutdown error handling.
Well, thanks for reading my novel. I don't know what can be done with LabVIEW documentation to make it more satisfying to folks like me, but perhaps someone can weigh in on all my ActiveX questions here.
Thank you in advance,
Steve Brady
Solved!
Go to Solution.

You need to close EVERY ActiveX reference you open. If you don't you'll end up with some Excel processes running even after LabVIEW exits. You can see them in Task Manager.
I, personally, don't like the LabVIEW Report Generation Tool Kit for working with Excel. I don't think it's flexible enough. I have a growing library of VIs that I've written that open, manipulate, and close Excel. Some references I pass from VI to VI and some I close right after I use them. It all depends on what I'm doing. If I want to enter read or write data from/to a certain range I'll get the range reference, read or write the data, then close it right away because I have no use for it any more. On the other hand, when I open Excel or a Workbook I keep the reference until I'm done, which could be later in the program.
1) When I go through my subVI once, pointing to one workbook, I'll get one set of references "created" or "opened" or whatever you call it when ActiveX references spring into existence. Now, when I exit the subVI, is it going to automatically try to "close" those ActiveX references? I don't suppose so, since subVI's stay in memory until the calling VI closes.
2) Now, I come back into my subVI a second time. New workbook gets created, so I get new references. Ok, fine. Uh oh! What happened to those old references? I suppose that if I didn't somehow save them off, I've probably lost the ability to get them back (maybe I'm wrong, but I don't need them back), but is LabVIEW going to "close" those old references (from previous times through the subVI) because I can't get to them anymore? Won't that cause the dreaded error 3001? If LabVIEW is not going to "close" them, what in tarnation happens to them (the old C programmer in me creeping back out)?? Now it's some oddball, orphaned reference, floating out there, hogging memory, waiting to make something crash intermittently and be a debugging nightmare?
3) Now, here's the real scary one. I think I might dodge the "error 3001" bullet in questions 1) and 2), but now let's say the user closes my LabVIEW application while Excel is still open. All those workbooks are still open. Presumably, all those ActiveX references I was not supposed to close are still open. I really hope that LabVIEW is decent enough to close/erase/delete/blow-away (whatever the right word is) all those ActiveX references which were opened/created by "Excel Get ActiveX References.vi" when my program terminates. But, oh no! Won't the error 3001 come along then? I suppose I can just dump it in the shutdown error handling.
1) No, LabVIEW will NOT close those references. You need to make sure that happens.
2) You can save the references in a functional global or use a class but if you're not going to save them close them as soon as you're done with them.
3) Your user should not be able to close your LabVIEW application without it going through the shutdown routine you've created for your program. The ABORT button should never be exposed to the user and you should capture and discard the panel close event so your program ALWAYS shuts down is an orderly fashion. If you don't you will have fragments of Excel hanging around in your operating system and will have to kill those processes using Task Manager. That should only be a problem during development, not once deployed.
I used to program in C and Assembly many moons ago. You should have seen my first LabVIEW code. I go back and look at it just so I can see how far I've come in the last 12 years. I feel your pain.
Kelly Bersch
Certified LabVIEW Developer
Kudos are always welcome

Opening/closing References in TS-engine does not work as expected, so creating memory hooks. Any solutions?

Hi!
As my project had grown beyond the point where I could keep a global overview, I tried creating atool that dynamically creates a kind of hirarchy for my TS libraries. It runs quite well for a small test setup, but crashes due to missing memory for the whole project. Any ideas?
A short description: I do all coding in LV7.1.
* Firts I open an automation refnum to TS.Iengine and invoke the method 'GetSequenceFileEx' with the path to my main seqfile, Flags = 0 and conflicthandler_Error.
* Than I use that sequencefile object to invoke the method 'Getsequence' with an index of 0 (assuming this beeing the 'MainSequence').
* For the returned sequence object I invoke the method 'GetNumSTep', which is fed into a For-Loop. Inside that loop, the very same object reference is used to:
- invoke 'GetStep' with the loop index
- with the step object i get some proiperties like Name, some expression and bolean values. If the step 'can_Specify_module', I invoke 'GetDescriptionEx', before the step object is closed (cvlose reference vi)
- I also invoke 'Parameters' on the step object. The parameter reference is used to access the property 'getLocation', which than is used as lookupString to access the property 'GetNumSubProperties', which I take as number of parameters of that step. Finally the parameters reference is closed
* The reference to the sequence object is closed after the for loop.
I fianlly get an array of description for all steps in the sequence file, in the order they are called from mainsequence there.
This array is used to recursively add a similar subarray for any subsequence call in it, until all calls are resolved (using a while loop that runs until the loop counter reaches the number of steps in the step description array).
The array is than scanned for 'typical' errors of mine like wrong parameter number at subsequence calls, missing/misspelled subsequences andf so on.
The LabVIEW execution accumulates more than 1 GB of RAM. LabVIEW itself reports just some 100kB of used RAM. So I assume the difference is RAM used by TS as a child process in LV. What can be done?
A vi with this code is provided (AS IS!).
Attachments:
SeqFileAnalyser.zip ‏192 KB

Hello Lul,
I tried out you tool and took a quick look at it and it ran fine. I did notice that LV memory grows during execution but only a few kb with a standard demo from TS (the increase is about the same size as the file being saved at the end). This is expected bahavior since results are being stored in memory during execution. When it is done, my mem goes back to about what it used to be before running. 1 GB of Mem seems to be very very very high! Did you expect it to be like this? How big is your txt file being created? Is the VI you posted exactly what you are using or do you have additinal loops that make the VI run continuosly and save to txt after multiple runs? I did not see any critical issues with your VI but I also did not go into your code in debth.
As long as you close all your TS references in LV, you should not havbe any mem leaks.
If you expect big fiole to be created, your PC will use up all RAm then use Virtual mem, the size for Virtual mem can be set in the Control Panel in Windows, usually tough, the system can set it dinamically, this might help you avoid crashe.
Hope this helps
Nick

Closing references

This question has been posed before and beaten to death ... and I've spent the good part of an hour perusing the discussions ... however ... I'm not satisfied with most of the conclusions. And the last discussion occurred last January, so there just might be some newer info out there ...
I have a vi that opens an ActiveX class, and this reference filters down with invoke and property nodes 12 levels to get the data that I need. At this moment I am only closing the original ActiveX reference, but I'm sure I need more. Instead of doubling the screen size of the block diagram with all of the Close References I tried to create an array with all the references and would close them all in one For Loop with one Close Reference ... but when I connected reference #2 I get a class conflict.
Has this been easier to work with in LV 8.2? Or do I have to plop down a Close Reference for each and every invoke/property node? That sounds brutal! But I need to be certain that I'm doing everything I can. Thanks in advance
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell

Thanks, Darren. Yours would be the definitive bottom line. I figured I would do this just to be safe. I ended up putting a row of Close References, one above each property and method. I was concerned with any one of them closing too soon, so I just sent the laste error cluster from the last property node back up and all the way to the left to the first close reference, then just daisy-chained that error cluster through all the Close References so they close all at once but only after I get the data. It's not a bad looking solution and my block diagram isn't any bigger, either. I don't have the ActiveX components here on my laptop at home so I'll have to wait until Monday to see if it works, but I don't see why it wouldn't. Thanks again.
PaulG.
"I enjoy talking to you. Your mind appeals to me. It resembles my own mind except that you happen to be insane." -- George Orwell

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

Change Topology without Closing Reference

Hello All,
Wondering if I should be able to change the topology of a MUX (reinitialize) without closing the reference? I have a application that loops through the basic initialize, connect, disconnect sequence for the NI-Switch functions, and the topology changes for each loop. I think my reference is getting lost, because it becomes invalid after several loops. Do I need to close the reference before I reinitialize with the new topology? I would prefer to not have to close it every time, because I have "cleanup" steps that close all of the references outside of the loop. Working with PXI-2527, LV 2013 and TS 2013. Thanks in advance.
GSinMN
Solved!
Go to Solution.

Hekki GSinMN,
This KnowledgeBase Article should answer your question. The last line reads, "When changing the topology, you have to close the present session if one is open, and reinitialize the card with the new DriverSetup selected."
Jonathan L.
Applications Engineer
National Instruments

Closing references to front panel objects

Short version of my question: are programmatically generated references to front panel objects (controls, etc.) automatically disposed of when the VI exits?
More details: I'm recursively retrieving references to all the controls on the front panel. (I say recursively because I'm also getting the individual controls from clusters, subclusters, and so on.) I then return an array of control references, which does not include the references to clusters--only standalone controls or the actual controls themselves contained in clusters.
Do I need to explicitly close the references to clusters that this VI generates, or is it unnecessary since the VI will run briefly, return an array, and then exit?
Or another scenario: in a subVI I open a reference to the parent VI. Do I need to close that reference at the end of the subVI, or is it pointless because the reference will be disposed of when the subVI exits anyway?
(I did find this article, which I think addresses my question, but I'm not sure.)
Thanks,
peppergrower

http://forums.ni.com/ni/board/message?board.id=170&thread.id=159571&view=by_date_ascending&page=1
Jean-Marc
Jean-Marc
LV2009 and LV2013
Free PDF Report with iTextSharp

Again closing references and reentrant vi-calls

Hello,
i create a static-vi-reference that is then opened in a loop for 10 times in parallel. At the end i wait for all are finished. Then i close the reference that was created from "Open Vi reference".
Question 1: Do i also have to close the reference that is coming from "Static vi reference"?
(This 10x opening happens each second).
Question 2:
Currently the vi that is used as static vi-reference is set in VI-Poperties + Execution to "Shared clone reentrant execution".
What about all the subvis that are called in there? Do i also have to set them to "Shared clone reentrant execution" or is this done automatically?
Question 3:
I have the effect that everything seems to run fine but the CPU and memory increases
After starting the program 50 MB RAM and CPU at 15%
Then i can be seen that there are cpu-peaks from time to time, Seems as this are the parallel-calls.
Then cpu goes higher and higher up to 72% and ram goes to 230MB (after 4 hours)
Is ther something that can be changed in this mimic? There is nothing else running that can eat my cpu und ram.
Thx

OnlyOne wrote:
Question 1: Do i also have to close the reference that is coming from "Static vi reference"?
(This 10x opening happens each second).
No
Question 2:
Currently the vi that is used as static vi-reference is set in VI-Poperties + Execution to "Shared clone reentrant execution".
What about all the subvis that are called in there? Do i also have to set them to "Shared clone reentrant execution" or is this done automatically?
They are not changed automatically. If you want everything inside of that VI to run COMPLETELY independent, then you need to set the reentrancy for all of those VIs. If you want them to share information, then non-reentrant VIs is a good way to do that. So it all depends on what you want the individual subVIs to do.
Question 3:
I have the effect that everything seems to run fine but the CPU and memory increases
After starting the program 50 MB RAM and CPU at 15%
Then i can be seen that there are cpu-peaks from time to time, Seems as this are the parallel-calls.
Then cpu goes higher and higher up to 72% and ram goes to 230MB (after 4 hours)
Is ther something that can be changed in this mimic? There is nothing else running that can eat my cpu und ram.
I'd have to see what else is happening inside of your code. This could be any number of things, usually having to do with building arrays.
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

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.

Closing control[] reference

If I have a main VI that calls sub-VI's, and I pass the control[] refereces of the controls in the main VI to the sub-VI. Should I use a for loop to close the control[] reference? And should I close the control[] referece in the main VI or the sub-VI?

My understanding of what you are doing is building an array of the control references in the main vi to pass to the sub-vis. Is this correct? If so, why not bundle the references instead? This way you could easily pull out the required reference by name.
Aside from that, if you are passing references to the front panel objects you shouldn't need to close them at all. The following links should be useful in helping you to understand when to close references:
http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=506500000008000000834C0000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=closing+references&USEARCHCONTEXT_QUESTION_S=0
http://www.ni.com/devzone/lvzone/dr_vi_archived4.htm
Hope that helps.
John

Unsaved Changes in File:[File name] Save before closing?

Hello!
FM 9 on Win 7 Pro.
I am a long-time FM user.
I am trying to open files that I could successfully open before I left work yesterday. I can open FM, and open FM books. When I try to open an FM in a book, or an FM file not in a book, I get this message:
"Unsaved Changes in File:[File name] Save before closing? Yes No Cancel.
It doesn't matter which one I pick (Yes, No, Cancel), FM next shows this message:
FrameMaker 9 Application has stopped working. Windows can check online for a solution to the problem.
Check online for a solution and close the program
Close the program.
View problem details
It doesn't matter what file I try to open (recently worked on files, and files I haven't touched for some time). Same messages, no matter what.
I have tried to update the book (the update seems to happen), saving the changes, and then try to open. Same error messages. I had hoped that updating the book would clear any possible cross-reference problems.
I have tried several re-boots, nothing works.
Help!
Thanks in advance for any and all help!
Terri

Since its happening with every file, my suspicion is that your application data is corrupted. Try this:
close down framemaker.
delete the following directory: C:\Users\[user]\AppData\Roaming\Adobe\FrameMaker\
reopen framemaker and see if the problem is reproducible.

Do i have to close reference after open?

Hello,
i have one vi that Opens & Starts 10times in a loop the same vi (see picture).
This vi is running very fast and is restarted each second by the calling vi.
Currently there is no "Close reference" at the end of all. Is this needed?
If yes: What is the consequence when running the vi without it?
My current problem is that the CPU usage rises although the program is always doing the same.
Can this be the result of a missing "Close Reference"?
Thx

Neos wrote:
why are you calling your vi in a loop every time.
Can't you put the while loop inside the called VI.
i do not see wait anywhere in loop so CPU usage will be high.
and yes you need to close references you opened.
He is calling different clone instances of his VI. That is why it is in a loop (a new instance each iteration). I'm just not sure why they just didn't use a FOR loop. The second loop will wait for each instance to complete, so no need to worry about CPU usage.
And yes, you should really close your references.
Closing References in LabVIEW
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines

Project File File References

Does JDeveloper 9.0.4 use absolute or relative file references in its project (.jpr) files, or is it a mixture of the two? I've heard conflicting stories but have personally only ever seen relative references.

Yes, I've tried this and have gotten a clean compile. However, the .dll is associated with third party software intended to add controls to a form. The form does not display in Designer though (extensive stack trace errors) which made me wonder
whether there is a downside to this approach.

Closing references YES or NO

Similar Messages

Maybe you are looking for