assciate file

[tbd]

Hi det,

      Forgive me for pushing this "brute-force" idea a bit further - not sure whether it made sense before.  Compile both Supervisor.vi and Worker.vi (attached.)  Associate the "special" file-extension with Worker.exe.  When you double-click on the special file, Worker will run just long-enough to send command-line args to Supervisor.  Supervisor stays open all the time.

...but I can't figure out how you've been able to get the filename in your application the first time!?  What version of LabVIEW are you running?  How are you getting the name of the "special" (associated) file?

Cheers.

[detted]

hi P.J.,

    Thanks for the workaround.  It should work. 
    I use LabView 6.1 for building applications, for the small size of run-time library.    There is a "get command-line" vi (attached originally from NI.com) for retrieving a command line string.   In LabView 8.2, there is a "command line properties" built-in in the "application properties.

te

[Donald]

---

detted wrote: ... The OpenG looks interesting.   However I am not ready for it yet ...

---

Just in case it was missed in the long thread linked by Avi: Jean Pierre Drolet did post an example in  Reply 17 of 22  (myx.zip  ... complete with readme and BLD files) of his method ... and it's in LV6.1.    Has worked like a charm for me for years and I'm not that bright.  Kudos for JPD.

[tbd]

Hi detted,

      I'll redo the VI's in 6.1 later.  Worker extracts the Command-line args using VI-properties, but it returned the name of the associated VI - not the "special" file that was clicked-on (Thank you for the CIN! - - )  Worker then tries to open/use a TCP/IP connection to send a string to Supervisor.  If it succeeds, it quits immediately, if not, it uses "System Exec." to launch Supervisor, then loops (once only!) to resend parameters.  Supervisor has a "Listener-loop" that waits for connections, reads a string (length bytes first) then closes connection.

Cheers,

Bill

[detted]

Bill,

    Your workaround works very well.   Thanks again for the idea.   This is how I do (with some pain):

1. write and build an "loader.exe"(A) in LabView 6.1
2. the program(B) itself only works in vi form, not an exe.
3. the A catches the command line parameters
4. A uses "open VI reference", "Run VI", delay little for the VI to load, and "set Control Value" to pass the Parameters to B, then close itself.
5. associate the A with the desired extension. 

    The pain:  I have LabView 6.i, 6.1 and 8.2 all in the same PC.   The 8.2 changes some behavior of all other versions.  Though the above scheme work perfectly in VI form.   The "loader.exe" can't be built in 6.1.  It reports some kind of "non-executable or incomputable VI" error.  My first reaction was the 8.2 screwed my system up, for I have built many applications with 6.1.   So on a different PC, I nuked the National Instruments stuffs, and reinstalled clean the 6.1 and application builder.  Everything is working fine. 

    I are still disappointed with the 8.2 (developer suite).   Besides the huge run-time library, the installation was a joke.   I can't count how many times the installers prompted me for a S/N. Almost every module asked for the S/N.  (I was swearing while installing).  It makes you feel NI googles public domain, collect them and put them together on many CDs.   I originally got 14 CDs.   Then an update gave me another 11 CDs.  The process repeated.  

det

[tbd]

Hi detted,

---

@detted wrote:

[ my name snipped ;^) ],

    Your workaround works very well.   Thanks again for the idea.   This is how I do (with some pain):

1. write and build an "loader.exe"(A) in LabView 6.1
2. the program(B) itself only works in vi form, not an exe.
3. the A catches the command line parameters
4. A uses "open VI reference", "Run VI", delay little for the VI to load, and "set Control Value" to pass the Parameters to B, then close itself.
5. associate the A with the desired extension. 

    The pain:  I have LabView 6.i, 6.1 and 8.2 all in the same PC.   The 8.2 changes some behavior of all other versions.  Though the above scheme work perfectly in VI form.   The "loader.exe" can't be built in 6.1.  It reports some kind of "non-executable or incomputable VI" error.  My first reaction was the 8.2 screwed my system up, for I have built many applications with 6.1.   So on a different PC, I nuked the National Instruments stuffs, and reinstalled clean the 6.1 and application builder.  Everything is working fine. 

    I are still disappointed with the 8.2 (developer suite).   Besides the huge run-time library, the installation was a joke.   I can't count how many times the installers prompted me for a S/N. Almost every module asked for the S/N.  (I was swearing while installing).  It makes you feel NI googles public domain, collect them and put them together on many CDs.   I originally got 14 CDs.   Then an update gave me another 11 CDs.  The process repeated.  

det

---

      It sounds like you're well on your way to becoming a LabVIEW Authority!     I have 8.2 installed on a (slow) PC along with LV6.1, but didn't know that 8.2 changed the behaviour of other versions!  This sounds like something NI might want to fix - can you characterize the affect LV8.2 has on LV6.1?  The only potentially dangerous feature I've noticed is that the default-directory for a LabVIEW file dialog is the last directory used in whatever version was last run - making very easy to open the wrong (older-version) VI under newer IDE.  See: this thread!

I know what you mean about 8.2's run-time library taking a long time to load - having just distributed my first 8.2 application to multiple PCs.  Guess I'm lucky, not using any special Modules.  Still we only need to install the 8.2 RTL once, yet we may do many compiles - and 8.2 compiles are very fast!

Cheers.

[detted]

Bill,

    Just a LabView user with opinions, not a programmer.  I assumed you are associated with NI.  It is not the 8.2 per se, but the run-time lib and particularly the installers/package in the Developer suite.   If you haven't, give the "suite" installation a try.

    It would be ok to delete my posts, if inflammatory.   thanks for the helps.

det

p.s. the scheme didn't work out in exe form, for the "loader.exe" can't be unloaded from the memory, while the "program.vi" is running.

[tbd]

Hi detted,

      Sorry for not saving to 6.1 already - yet it sounded like you had a working variation.  The scheme I described, using a TCP/IP exchange worked (tested repeatedly) though my "worker.vi" didn't incorporate the call to your CIN...   If this scheme develops a problem when CIN is included, perhaps there's a CIN resource that needs to be "closed" or unloaded?

Will post later (in 6.1) if only to make tools more readily available than .zip files (in other threads.)

Inflamatory?  Don't think so.  Maybe my attempt to compliment was too patronizing(?) - I'm clumsy at IO with people.

Cheers.

[tbd]

Hi detted,

Here are the two VIs - in LabVIEW 6.1.

Cheers.