Problem with updating ring text and parallel processing

[gnunesjr]

Hi all-

I am writing a LabVIEW application with multiple VIs running in parallel.  One of these VIs makes a call to dll (supplied by a vendor and required to monitor the hardware that is this application's reason for being) which then sits in memory and runs continously.  It is truly impressive what you cannot do with LV if a synchronous node is permanently parked in operation!  One of those things that you can't do is use the "file open" dialogs (or anything else that involves calls to the Windows API).  So I wrote my own (see the attachment).  Basically, it launches a VI which reads the files from a directory and uses a property node to put the file names into the strings of a ring control.  When I launch this VI on its own, it works beautifully.  When I call this VI from a dummy VI, it also works fine.  When the VI is called from the heart of my application, the contents of the ring variable have not been updated with the file names...the first time you make the list drop down, the ring contains only the "default" values.  If you release the control, and drop it down a second time, everything is as it should be.  Not fatal, but annoying, and it gives my program an unprofessional feel.

If you are still with me...  If you look at the VI, you will see that I put the file names into an array, as well as into the ring property node, and then I use the ring to index the array.  It seems to me that the "right" way to do this is put the strings into the ring control, and then use the ring control to index its own strings property.  Unfortunately, this does not improve the situation...

Any ideas on how to "trick" the ring into updating when the front panel opens, rather than after it's been poked a few times?

Much thanks
-gn

[SergKr]

Quick correction attached. Your vi first reading strings from  strings property and then updates the strings and values property. Dataflow....

[gnunesjr]

Thanks.  I tried exactly your proposed solution (see the second paragraph of my post).  I agree that it is the manifestly correct approach.  It also does not work (when called from within my application.  I still have to drop down the ring list twice to see the correct list of file names).

[Ben]

Hi Gnunesjr,

The problem with your original version of the code can be seen by running your VI in execution highlighting.

If you watch it, you will see that LV reads the strings to be used in your second loop before the first loop is done and the strings are written.

This is a clasic "race condition".

Sergey already showed you how to enusre the first loop completes before the second loop runs.

If you are still seeing that problem after using Sergey's solution, then your app must be taking a long time to read all of the files and populate the ring.

See below.

In this mod of Sergey's code I disable the ring before the list operation and I do not enable it until after the string selections are written.

Does this work for you?

Ben

Message Edited by Ben on 04-05-2006 07:59 AM

[SergKr]

Additionally to Ben explanation, there could be the situation imagined, when an update of the front panel control coming asinchronously with block diagram code flow. The behaviour you see may happen in the case when the data from the first call of the dialog remains in ring until the next dialog call updates it (if fron panel remains in memory and depends on the other options as well).  You may try to force this update checking "Synchronous display" option for ring control. In this case all changes of the control values in diagram will be synchronized with front panel updates of the control. To add power to the process add value property and wire, say, 0 to this property before entering while loop.
Another option could be to change dialog code itself. May be attached will help.
I cannot reproduce the behaviour you see, so your mentioned behaviour depends on calls context of your main program. No idea. Just experiment with advices given and look into your program structure again.

Couple links:
http://zone.ni.com/public.nsf/websearch/74ECB57D3C6DF2CE86256BE30074EC47?OpenDocument
http://zone.ni.com/devzone/conceptd.nsf/2d17d611efb58b22862567a9006ffe76/732cec772aa4fbe586256a37005541d3?OpenDocument

[SergKr]

OOps..Sorry, for duplicated attachement. Lost one.