How to contnsly access the subvi

[paulrobinson]

Hi yamaeda,

       Thanks for your reply but i already tried using this actually if you look the code once again you can see that i used event structure for file path control(value change option), if i do as you said what is the point in using boolean control, here i just did what you said but when i press the boolean button instead opening the file path window it shows the one button dialogue box or may be i did wrong as you've said, i have attached you a vi once again go through it.

 Thanks once again,

Regards,

Paul

[Yamaeda]

Yes, i see my answer was stressed. As you're not writing anything to the file you just want to select one for later, right? Then use an Open/Create file instead. The False case is just a file path passthrough.

/Y

[paulrobinson]

Hi yamaeda,

  Sorry for asking you the same question here, but i tried that too still no luck, did you tried yourself?

Thank you,

Regards,

Paul

[Bob_Schor]

Sorry, but you really do need to go back and review some Basic LabVIEW, as well as give some thought to the design of your Project (I recommend that you learn a bit about State Machines).  Here are some specific "problems" (= misunderstandings):

• An Event Loop using Boolean Controls (in LabVIEW) usually uses a "Latch When Released" mechanical action on the Boolean Controls, with the Control being placed inside (but usually unwired) its Value Changed Event.  What this does is to "turn off" the Control when the Event "fires", turning it into an effective Push Button, but one that triggers an action.  If 98% of LabVIEW Developers "do it that way", you might as well do it, too, as this will make your intent clear.  [Note that you can program Boolean Events using other code, as you have done, but it makes it unclear to LabVIEW "experts" ...]
• In my experience, a Good Practice for Event Loops is to have only one Event handled at a time.  In particular, I don't think you want a File Path Value Change Event doing the same thing as the Specify Path Boolean.
• Some of your Controls are invisible, yet you have Events for them.  Are you turning Visibility On and Off?  You need to be careful, as this can make the code pretty obscure and hard to follow.
• You have a bunch of buttons on the Front Panel.  Is the order of pressing immaterial?  The only button that seems to have an "order rule" is Quit, which causes the Program to exit (hence is the last button to be pressed).  Is it legal/logical to "Process Window", then "Prompt User", then "Specify Path"?  [I don't know -- it is your Program and your "task" ...].
• If there is a single "Task" with three parts, namely "Specify Path", then "Prompt User", then "Process Window" (I might have the order wrong, as I haven't closely inspected all the code), you could have three VIs, "Specify Path", "Prompt User", and "Process Window" that all have Error In/Error Out, sit sequentially on an Error Line, "Do One Thing" and output something for the next VI in the Chain, then exit.  You could use the Error Line to "flag" a bad input (i.e. the user Cancels instead of choosing an Input File) with subsequent VIs detecting the Error and doing nothing, and you could use a User-Define Error, say 5001 with the message "User Cancelled", to inform the User, or you could have a Boolean Output called "OK so Far" that, if false, would cause a Message to be displayed and the subsequent code skipped.  You could also use a State Machine (hmm, what's that?) ...

Bob Schor