Associating my EXE with a specific file extension type

[Chris Davis]

I was just trying to make my own version of the example work and after struggling for a couple of hours, I found the part I was missing. See my note about the code below.

REGEDIT      HKEY_CLASSES_ROOT\.TON = tonfile      HKEY_CLASSES_ROOT\tonfile = My Ton Files      HKEY_CLASSES_ROOT\tonfile\shell\open\command = "d:\tonfile\application.exe" -- "%1"      HKEY_CLASSES_ROOT\tonfile\shell\open\ddeexec = open(%1)      HKEY_CLASSES_ROOT\tonfile\shell\open\ddeexec\Application = application      HKEY_CLASSES_ROOT\tonfile\shell\open\ddeexec\Topic = System

Specifically the following line.

   HKEY_CLASSES_ROOT\tonfile\shell\open\ddeexec\Application = application

In this line, the "application" at the end of the line is referring to the executable's name without the .exe on the end. Since this article is linked in the wiki, I wanted to make that clarification evident for everyone.

[kai_n]

For some reason that does not work for me. I do have the registry keys set in the same way as in the code in the previous post, and I am using the fileLoader_JK01 for testing. Starting the application by double clicking a TON file does work, but if I try to open another TON file the application just gets into focus but nothing happens.

I am using LabView 8.51, scripting enabled.

Thanks for any help!

[LAVA 1.0 Content]

Could you show your event OS Open Document event code?

Ton

[kai_n]

I did not change the code from the example:

If I erase the "App.args" statement, not even opening the file for the first time works. But the exe ist started...

Did anybody try this with LabView 8.51?

[LAVA 1.0 Content]

I could not get this to work with 8.6

Ton

[LAVA 1.0 Content]

I could not get this to work with 8.6

Ton

[battler]

QUOTE(Jim Kring @ Mar 3 2007, 08:00 PM)

Allright, who is gonna buy who a beer :question:

I figured a little more out, setting the registry with this options:

HKEY_CLASSES_ROOT\tonfile\shell\open\command = "d:\tonfile\application.exe"HKEY_CLASSES_ROOT\tonfile\shell\open\ddeexec = open(%1)

You don't need the command line arguments, windows will launch the program via command, and will set up a DDE connection with (open(%1)), and the event is triggered!

Notice that the open\command does not include %1!

The whole code is:

<A href="http://forums.lavag.org/index.php?act=attach&type=post&id=5110">http://forums.lavag....pe=post&id=5110

Ton

I can't get the code! :-( The links just seem to take me to the main page. Please help!

QUOTE(nicolasB @ Oct 9 2007, 01:48 PM)

It's only available, if you have Scripting enabled.

You need to have this in your labview.ini:

SuperSecretPrivateSpecialStuff=True

Please read this first, if you are new to this topic: VI Scripting - Readme First

VI Scripting link doesn't work:-( Takes me to the main page again.

[Michael Aivaliotis]

VI Scripting link doesn't work:-( Takes me to the main page again.

[battler]

QUOTE(Jim Kring @ Mar 3 2007, 08:00 PM)

Allright, who is gonna buy who a beer :question:

I figured a little more out, setting the registry with this options:

HKEY_CLASSES_ROOT\tonfile\shell\open\command = "d:\tonfile\application.exe"HKEY_CLASSES_ROOT\tonfile\shell\open\ddeexec = open(%1)

You don't need the command line arguments, windows will launch the program via command, and will set up a DDE connection with (open(%1)), and the event is triggered!

Notice that the open\command does not include %1!

The whole code is:

<A href="http://forums.lavag.org/index.php?act=attach&type=post&id=5110">http://forums.lavag....pe=post&id=5110

Ton

Ton, are you able to provide this code?

Evening all,

I can't find any record of the "Application.OS Open Document" event.

Any ideas on where to find it?

Battler.

[Ton Plomp]

Sorry,

I can't locate the code anymore, but here is a VI in 8.6 with two OS.OpenDocument Events (filter and normal).

I did not get this to work with anything other than 8.2

Ton

8.6privateevents.vi

[battler]

Sorry,

I can't locate the code anymore, but here is a VI in 8.6 with two OS.OpenDocument Events (filter and normal).

I did not get this to work with anything other than 8.2

Ton

Thanks Ton.

From what I've read about VI Scripting I don't think using this OS.OpenDocument Event is a good idea (or even possible).

What is the best method for associating a custom file type with an application and being able to open the file when the app is both running and closed?

[Rolf Kalbermatter]

Thanks Ton.

From what I've read about VI Scripting I don't think using this OS.OpenDocument Event is a good idea (or even possible).

What is the best method for associating a custom file type with an application and being able to open the file when the app is both running and closed?

There are many ways and what is the best will depend on you. But the only one that does not involve tackling not properly working private LabVIEW methods, properties and events, or writing some bunch of C code to do the "right" © thing in a DLL and integrate that into your app, is to go about it like it is explained in the wiki. The advantage of this is also that it will basically work in all versions and platforms of LabVIEW that support the pass command line parameters feature. This is every desktop LabVIEW version since at least LabVIEW 7.0.

And I think you have all the information necessary to come up with a working solution in a day or so. So get started and show us the code, when you do not get any further.

Rolf Kalbermatter

[Ton Plomp]

I have tested this in LabVIEW 2009 and it seems to work!

Ton

[Ravi Beniwal]

<cite>QUOTE(Jim Kring @ Mar 3 2007, 08:00 PM) </a></cite>

...

Ton

I guess there is reason why this trick didn't make it into mainstream.

It works great most of the time (and it feels good to see your application open when you double click on a file). But the OS got really mad at me once and decided to keep opening new instances of my LabVIEW application. I had about 50-60 instances open within a few seconds. I had to shutdown the computer to make it stop.

Has anyone else had this experience?

[asbo]

Did you select 50-60 associated files and try to open them all at once? On a related note, I know that Win7 won't let you "multi-open" over a certain limit (which is pretty annoying sometimes).

[Ravi Beniwal]

Did you select 50-60 associated files and try to open them all at once? On a related note, I know that Win7 won't let you "multi-open" over a certain limit (which is pretty annoying sometimes).

Sorry about the lack of clarity in the earlier post. I tried to open only 1 file. If I had selected 50-60 files, tried to open them and the OS opened them, that would be the intended behavior that one wouldn't complain about.

[asbo]

Hmm. Sounds like a LabVIEW bug, rather than an implementation bug. Any chance you can repro it?

[GregSands]

Did you select 50-60 associated files and try to open them all at once? On a related note, I know that Win7 won't let you "multi-open" over a certain limit (which is pretty annoying sometimes).

See here to get around this annoyance.

[Rolf Kalbermatter]

Hmm. Sounds like a LabVIEW bug, rather than an implementation bug. Any chance you can repro it?

I'm not sure I would undersign this as a LabVIEW bug. LabVIEW doesn't instantiate new executables but the Windows shell does. For some reasons the shell thinks that the launching of the command has failed and seems to retry it in an endless loop. This looks more like a flaw in the handling of launching an executable than in LabVIEW itself, especially since the spawning of new processes seems to happen so quickly that LabVIEW hasn't even gotten a chance to already be loaded into memory and start doing anything at all, that could influence the Windows shell in such a way.

[asbo]

That could be true - I was looking at it from the perspective that LabVIEW wasn't properly acknowledging the launch and Windows was launching it again. Thinking back, though, I've never actually seen Windows retry a command like this, especially many times. On the contrary, I have seen it display a dialog stating that the command failed with particularly slow-launching on multiple occasions. Not I'm not sure where the blame may lie. Without a repro, it's very tough to guess.

[Ravi Beniwal]

Hmm. Sounds like a LabVIEW bug, rather than an implementation bug. Any chance you can repro it?

Like most other such weird issues, the application worked fine for a few days after I first built it, but (I don't know what happened and..) now it consistently displays this behavior. I'll try it out on other computers and share the experience.

[Ravi Beniwal]

It happens only when I enable multiple instances of my exe using the "allowmultipleinstances=true" attribute in the INI file.

If I allow only a single instance, all file open messages from the OS show up in the instance of the application that I have open. So now I have an event structure with the "OS Open Document" and a "Timeout" in my main event structure's Timeout case. For what it is worth, it is working fine.

[Rolf Kalbermatter]

It happens only when I enable multiple instances of my exe using the "allowmultipleinstances=true" attribute in the INI file.

If I allow only a single instance, all file open messages from the OS show up in the instance of the application that I have open. So now I have an event structure with the "OS Open Document" and a "Timeout" in my main event structure's Timeout case. For what it is worth, it is working fine.

Without that ini token the executable may still get started by the Windows shell, but one of the first things LabVIEW does on starting up is to try to connect a different (same version) LabVIEW instance (through DDE communication) and if it finds it it will simply pass any command line commands to that instance instead and quit gracefully.

[Mike Le]

I'm experiencing the same "infinite instances" problem that Ravi observed. Does anyone know if there's a way to get both features (allowMultipleInstances and OS Open Document) to work together nicely?

My application has had OS Open Document for several months. The addition of multipleInstances is a late request by the enduser... it would require serious re-architecting to get the desired behavior with a single instance.

Thanks.

[gemotech]

Hello,

I know this an old discussion, but I'm trying to open associated files with my standalone application.

 

I used the OS Open Document condition to get the file content and it works very well on my development PC (where is installed LabVIEW). But that doesn't work on another PC where I proceeded to the installation of my standalone application.

 

I generated the application with LabVIEW 2011 and I tried to add SuperSecretPrivateSpecialStuff=True in my application INI file without any change. The application is opened and focused at each double clic on an associated file.

 

Do you have any idea to solve my problem? Is there any "instruction line" to add to my INI file?

 

Thanks in advance and best regards,
Gerald