LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
TCPlomp

Add a native File Open event

Status: New

For modern application development we need better methods to detect wheter our application is called to open a file.

Currently the only help NI gives is based on command line parameters. And we need to jump through loops to get it working to react on opening a file when the program allready runs.

 

This is a major showstopper in creating professional applications.

 

LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.

 

 

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
4 Comments
battler.
Active Participant
I would agree with that.
deyyoung
Member

This needs a lot more attention than it has gotten!

dadreamer
Active Participant

@TCPlomp wrote:
LabVIEW 8.2 had a hidden event for getting this event, which unfortunatly doesn't work in later versions.

Actually it is not true, I have just tested "OS Open Document" event on LV 2011 and 2014 and it run like a clockwork. To achieve this you should just have proper registry keys set, it has been posted here, for example. That thread also contains alternative method of DDE interception, so you would have small additional functionality: your application may know if it's exe file is being double-clicked when it's already running. And, of course, it works with file associations as well.

Mads
Active Participant

The OS Open Document event works yes, but one important thing to note is that if the application was built with the "Pass all command line arguments to application" key checked the OS Open Document event is never triggered 🙁  I incorrectly concluded that the event was useless the first time I tested it as this is not documented anywhere.

 

This issue can be a show stopper in cases where you want to be able to launch the app with additional/other arguments in some cases, e.g. to trigger some special behaviour. We do that to allow system administrators to disable some features in the application depending on the user's access, or point the application to an alternative configuration e.g..

So one idea would be to fix this to ensure that command line arguments are still supported *and* preferably also add file associations to a separate page on the installer build setup where you can more easily ask the installer to establish associations, assign file icons etc...