How to assign file extension to exe.?

[battler]

Hi all,

I managed to follow the instructions found here:

http://digital.ni.com/public.nsf/allkb/9538A36E218F10A4862571A8005EF6C0

Now when I double-click on my custom file (i.e. file.abc) it opens my application. From there I can use the command line interface to open the file.

This is fine when my application is closed. However, I want it to work when my application is running. My application contains an event structure. I was told that I could probably doing it by using the DDE server functions.

Would anybody be able to help me to find the relevant information?

Thanks very much.

Battler.

[Kurt Friday]

I had a poke around and found some info on implementing DDE into your LabVIEW application. I had a little play with it and you can create a simple DDE server and a client to pass data to each other.

I dont know if this is the best way to tackle the problem but one solution might be to create one executable that is a DDE client that is registered to your file extension, as per your article. The client messages the file path to the DDE server which is your main application. If the client can't connect to the DDE server then it assumes that the server is not open so it opens it using the command line, once open it can message into it.

You could also achieve the same using TCP.

Again there may be a better way of doing this.

[battler]

Thanks for your response.

As you say, perhaps I could register a separate application (App2) to my custom file extension with command line arguments enabled.

When a custom file is double-clicked App2 would need to either:

1. If App1 is not running - Open App1 and pass the filename with custom extension; or

2. If App1 is already running - Send the filename. An event would need to be triggered in App1.

I like the sounds of TCP/IP as opposed to DDE. How would this work? How would an event be triggered in the event structure upon receiving TCP/IP data (i.e. filename)?

Nice thinking.

Cheers,

Battler.

[Kurt Friday]

Thanks for your response.

As you say, perhaps I could register a separate application (App2) to my custom file extension with command line arguments enabled.

When a custom file is double-clicked App2 would need to either:

1. If App1 is not running - Open App1 and pass the filename with custom extension; or

2. If App1 is already running - Send the filename. An event would need to be triggered in App1.

I like the sounds of TCP/IP as opposed to DDE. How would this work? How would an event be triggered in the event structure upon receiving TCP/IP data (i.e. filename)?

Nice thinking.

Cheers,

Battler.

Take a look at some of the TCP client/server examples, that should point you in the right direction. In your main which will also a TCP server have a loop that listens for a connection. When a connection is found and message received poke it into a user event which is registered to your event structure.

[jgcode]

Thanks for your response.

As you say, perhaps I could register a separate application (App2) to my custom file extension with command line arguments enabled.

When a custom file is double-clicked App2 would need to either:

1. If App1 is not running - Open App1 and pass the filename with custom extension; or

2. If App1 is already running - Send the filename. An event would need to be triggered in App1.

I like the sounds of TCP/IP as opposed to DDE. How would this work? How would an event be triggered in the event structure upon receiving TCP/IP data (i.e. filename)?

Nice thinking.

Cheers,

Battler.

I am pretty sure VIPM would do something like this, with their VIPM File Handler.exe

You may like to ask on their forums for info too?

Edited August 19, 2009 by jgcode

[Antoine Chalons]

There was a thread on LAVA 1.0, see here and an article on LabVIEW Wiki.

Hope this helps

[Ton Plomp]

Have a look at this LabVIEW wiki topic.

There is even a specific event, that only works in LabVIEW 8.2.

To get a good working solution, JKI has implemented a small loader executable that is registered with the extension. This (fas-loading) application sends the actual file path to VIPM via TCP/IP or something else.

Ton

[Kurt Friday]

There was a thread on LAVA 1.0, see here and an article on LabVIEW Wiki.

Hope this helps

Nice find, thought there would other ways to do this. LVShellOpen.exe solution is very close to what I'd proposed.

[battler]

Have a look at this LabVIEW wiki topic.

There is even a specific event, that only works in LabVIEW 8.2.

To get a good working solution, JKI has implemented a small loader executable that is registered with the extension. This (fas-loading) application sends the actual file path to VIPM via TCP/IP or something else.

Ton

Thanks heaps.

I can't get the code. Where do I get it? The links seem to be broken. Any ideas?

Nice find, thought there would other ways to do this. LVShellOpen.exe solution is very close to what I'd proposed.

Were you able to get the code? Thanks.

Have a look at this LabVIEW wiki topic.

There is even a specific event, that only works in LabVIEW 8.2.

To get a good working solution, JKI has implemented a small loader executable that is registered with the extension. This (fas-loading) application sends the actual file path to VIPM via TCP/IP or something else.

Ton

JKI software. Is the application downloadable for free from their website? What is the name of the application? Thanks:)

Thanks heaps.

I can't get the code. Where do I get it? The links seem to be broken. Any ideas?

Were you able to get the code? Thanks.

JKI software. Is the application downloadable for free from their website? What is the name of the application? Thanks:)

I want to be able to write the code myself;-) Are there any example VI available? Cheers. Battler.

[Rolf Kalbermatter]

It's considered friendly to mention cross posts to other boards even if they are on the "dark side".

I can't get the code. Where do I get it? The links seem to be broken. Any ideas?

During a recent crash all of the content got lost and had to be restored from backups. This broke many links. The admins can fix them if they know where to look exactly but this is manual work so be kind and give them the exact information about what is broken and some time to fix it.

JKI software. Is the application downloadable for free from their website? What is the name of the application? Thanks:)

VIPM is the flagship software from JKI. So they are not likely giving out the source code for that. But once the links are restored you should get the examples you need.

But the principle is not so complicated. First you have a tiny little LabVIEW EXE file that gets assigned the file extension(s). It is always started with the filename as command line parameter and it takes those command line parameters, opens an interapplication communication channel (TCP/IP, DDE, etc) to your real application and passes it the command line parameters over that. After that it simply terminates to be launched again.

Of course there is a little more to it since the command line intercepter has to check for the main application to be started and if that is not the case do so first.

Unfortunately this is absolutely necessary in pre-8.2 scenearios since the LabVIEW DDE server functions never implemented receiving DDE Execute commands (the client functions support sending them though ) and that is how the Windows shell passes those requests to an already started application. I once tried to implement a new version of the DDE functionality in LabVIEW that would support receiving DDE commands too, but never got really far due to time constraints and lack of any need for that for myself.

From 8.2 you have this private Open Document event in the event structure. It seems to be there since and not really changed but there are troubles with this, that it throws an unknown LabVIEW document error the first time after the application has been launched. Not sure if this problem still exists in the most recent LabVIEW versions.

Rolf Kalbermatter

[Ton Plomp]

I filed an idea exchange.

Please vote

Ton

[Rolf Kalbermatter]

I filed an idea exchange.

Please vote

Battler, adding a comment to that idea is nice but supporting it by voting for it and click on the Kudos button would probably help more.

These ideas are all weighted and the decision to implement them is based on various criteria such as:

- The necessary work to do it (not terribly much but it is a tricky thing to get right for all LabVIEW platforms and will require quite some testing)

- The availability of resources (developers and their time)

- and last but not least the number of votes an idea gets

Rolf Kalbermatter

[Mads]

I do it this way in my applications. The loader app gets the file path from the argument generated by the OS due to the registry settings - and uses DDE to transfer the path of the opened file. If the DDE connection fails it assumes that the app is not running yet and starts it...and waits until it gets the DDE link. I do not launch the target app with arguments simply because I want it to work smoothly when opening multiple files:

I have set the .ini file of the launcher so that it runs multiple instances (AllowMultipleInstances=True)...that way people can open multiple files in one go.

The reason why I chose DDE instead of TCP is because it is less of an open door to the outside world...although I would prefer it if there was indeed a way to esnsure that the communication was only possible locally on the PC (without using the firewall). ActiveX could be an option...as DDE really is a very old technology and might get phased out soon.

Mads

Thanks for your response.

As you say, perhaps I could register a separate application (App2) to my custom file extension with command line arguments enabled.

When a custom file is double-clicked App2 would need to either:

1. If App1 is not running - Open App1 and pass the filename with custom extension; or

2. If App1 is already running - Send the filename. An event would need to be triggered in App1.

I like the sounds of TCP/IP as opposed to DDE. How would this work? How would an event be triggered in the event structure upon receiving TCP/IP data (i.e. filename)?

Nice thinking.

Cheers,

Battler.

Edited August 20, 2009 by Mads

[Kurt Friday]

I have set the .ini file of the launcher sothat it runs multiple instances (AllowMultipleInstances=True)...thatway people can open multiple files in one go.

Nice!!

ActiveX could be an option...as DDE really is a very old technology and might get phased out soon.

I don't think you can communicate between LabVIEW exe's with ActiveX as this would involve writing your own ActiveX server.

[battler]

Nice!!

I don't think you can communicate between LabVIEW exe's with ActiveX as this would involve writing your own ActiveX server.

I thought LabVIEW exe's had the ability to act as an ActiveX server. It's a setting in the App builder.

I do it this way in my applications. The loader app gets the file path from the argument generated by the OS due to the registry settings - and uses DDE to transfer the path of the opened file. If the DDE connection fails it assumes that the app is not running yet and starts it...and waits until it gets the DDE link. I do not launch the target app with arguments simply because I want it to work smoothly when opening multiple files:

I have set the .ini file of the launcher so that it runs multiple instances (AllowMultipleInstances=True)...that way people can open multiple files in one go.

The reason why I chose DDE instead of TCP is because it is less of an open door to the outside world...although I would prefer it if there was indeed a way to esnsure that the communication was only possible locally on the PC (without using the firewall). ActiveX could be an option...as DDE really is a very old technology and might get phased out soon.

Mads

Thanks Mads. Can you post some example code?

How does the "loader app gets the file path from the argument generated by the OS"? You build 2 separate exe's? The loader (laucher?) is registered to the sutom file type (i.e. .myx)with the OS via registry settings?

[Mads]

Yes, you have a helper executable - that's what I call the "Launcher". When the whole application set is installed it adds entries to the registry that associates certain files with the Launcher...This way the OS runs an instance of the launcher...which in turn runs (if necessary) and transfers the file path to the main application. I have extracted the core of the code and attached it here...

I have *not* taken the time to make it into a fully working example as that would take more time than I have right now...but you should be able to pick up the main ideas. OpenG VIs are required...

It is about time that we get full support for file associations in LV..so Kudos that idea on the Idea Exchange everyone, please.

Mads

I thought LabVIEW exe's had the ability to act as an ActiveX server. It's a setting in the App builder.

Thanks Mads. Can you post some example code?

How does the "loader app gets the file path from the argument generated by the OS"? You build 2 separate exe's? The loader (laucher?) is registered to the sutom file type (i.e. .myx)with the OS via registry settings?

File Launcher Example.zip

Edited August 20, 2009 by Mads

[Kurt Friday]

I thought LabVIEW exe's had the ability to act as an ActiveX server. It's a setting in the App builder.

My apologies, it looks like you can. I'd never played with this before, I'll check it out.

[battler]

Thanks Mads, that's fantastic.

The settings in the exe ini file. How do you know what to put in there? Can you point me in the direction of some documentation about those?

I'm really keen to explore the ActiveX server method for doing this.

My apologies, it looks like you can. I'd never played with this before, I'll check it out.

That's ok I forgive you;-) Especially since you are in Sydney like me.

I'm really keen to explore the ActiveX server method for assigning file extensions to exe.

Does anyone have any idea about this (i.e. ActiveX servers)?

[Ton Plomp]

The activeX server as shown by a LabVIEW app, is just an activeX accessible VI server layer.

So what you can do is build a specific VI into your app that will trigger an event or (named) queue when run, place a path control on it's FP.

Now via the ActiveX interface get to this VI, fill in the path control and run the VI, this should do.

Ton

[Rolf Kalbermatter]

This is fine when my application is closed. However, I want it to work when my application is running. My application contains an event structure. I was told that I could probably doing it by using the DDE server functions.

Well, I just checked it again. It has been a long time that I have worked with this but DDE Server is unfortunately not an option here using the LabVIEW DDE VIs. The LabVIEW internal DDE callback specifically refuses to receive DDE Execute commands and that is exactly the method used by the Windows shell to pass such requests to an application. You would have to implement your own DDE server in C and integrate it as DLL which I think is not a useful exercise in terms of effort required and the benefit you get.

As to the solution to your problem I'm sure it has been talked about in the threads linked to from this one as well as in a previous post by me and others in this thread before.

The reason why I chose DDE instead of TCP is because it is less of an open door to the outside world...although I would prefer it if there was indeed a way to esnsure that the communication was only possible locally on the PC (without using the firewall). ActiveX could be an option...as DDE really is a very old technology and might get phased out soon.

With any respect but I find this remark rather amusing. DDE is an old legacy technology. If it is any more secure than TCP/IP then only by its obscurity but certainly not by its way of implementation. DDE is a technology that origins from Windows 3.x days when applications had no seperate virtual memory

and could write in each others memory anyway they wanted. Great for implementing interapplication communication schemes like DDE since you had almost nothing to do to allow that. Absolutely not so great for security.

In order to make DDE work in Win32, they had to jump through many hoops and add a lot of code that does some obscure things deep in the windows event management to allow for proper operation of it. As such I would never trust it to be really secure, other than the obscurity fact, since very few people know nowadays about DDE and how to use it.

The use of TCP/IP (either explicitedly or through VI server) has the advantage that everything will keep working exactly the same if you happen to use this on a non Bill Gates sanctioned OS .

I'm really keen to explore the ActiveX server method for assigning file extensions to exe.

Does anyone have any idea about this (i.e. ActiveX servers)?

There is AFAIK no ActiveX server method to assign file extensions. Even if there would be an alternative that allows to invoke an application based on file extension, the LabVIEW ActiveX server would not be compatible since it only exports its own ActiveX Class Interface and not any other ones. Microsoft would for sure have designed a specifc COM interface for this, that such applications would have to expose, but as said I'm not aware of an alternative ActiveX activation based on file extensions.

How things currently happen: If a file extension has a DDE Server registry entry the Windows shell simply tries to contact that server. Failing that it will launch the executable and optionally pass it the file as command line parameter (command/open verb contains the %1 parameter). If that parameter is missing it will try again to contact the application through DDE and pass it the open verb with the file path.

Rolf Kalbermatter

[Kurt Friday]

That's ok I forgive you;-) Especially since you are in Sydney like me.

Cool, I'm interested in catching up and getting to know the Sydney LabVIEW people, PM me if you want to catch up for a sometime.

[Mads]

Absolutely Rolf, if anything I would call using DDE this way now a kind of security through obscurity..I do not blame you for laughing

Everyone notices if an application opens a TCP-port, you even get a nice warning from the Windows firewall. Most apps I make are servers (so I do not avoid the warning anyway...) I could have just added the command to the existing set of commands supported by my client-server interface...however it does not seem like a good idea to have such a thing available.If I had used TCP I would put this on a separate TCP port and make sure that port would always stay blocked in the firewall and had some password protection that "only" the launcher would be able to pass by accessing local information. There should be a better option for local communication....I can think of a couple, but neither of them are elegant...

Mads

With any respect but I find this remark rather amusing. DDE is an old legacy technology. If it is any more secure than TCP/IP then only by its obscurity but certainly not by its way of implementation. DDE is a technology that origins from Windows 3.x days when applications had no seperate virtual memory

and could write in each others memory anyway they wanted. Great for implementing interapplication communication schemes like DDE since you had almost nothing to do to allow that. Absolutely not so great for security.

In order to make DDE work in Win32, they had to jump through many hoops and add a lot of code that does some obscure things deep in the windows event management to allow for proper operation of it. As such I would never trust it to be really secure, other than the obscurity fact, since very few people know nowadays about DDE and how to use it.

The use of TCP/IP (either explicitedly or through VI server) has the advantage that everything will keep working exactly the same if you happen to use this on a non Bill Gates sanctioned OS .

Edited August 22, 2009 by Mads

[battler]

Hi all.

I haven't had time to implement this yet.

From Rolf's post it tells me that double-clicking a file and opening while an application is open is not possible with DDE nor ActiveX. True?

Mads, are you saying that you have made it work with DDE (I've seen your example, thanks)?

Cheers,

Battler.

[Fedor]

I have tried to use "OS open document" event in labview 2010 32 bit on MS Server 2008.

I created a test executable, than launched it from windows explorer using right mouse click "Open with.." menu, where I selected my new application. The event was invoked every time I use "Open with..." on a file when app was running, and the "path" contained correct file name. I did not associate the app as default for given file type.

It did work for a bit on my test application. Then I added same even to my main app, and associated is with a file extension "tdms". The event "OS open document" did not work in my main app and it stopped working in the original test app, with any file extension. I rebooted the machine thinking that labview service got screwed up, but it is still not firing.

Any suggestion on what could have broken it?

P.S. Sorry, I meant to post on in this thread instead:

Edited February 3, 2012 by Fedor

[Mads]

The "LVShellOpen"-helper executable seems to be the de-facto solution for this, but it seems everyone builds their own. Or has someone made a template for this and published it?

Seems like a good candiate for a VIPM-package 🙂 

(The downside might be that NI then never bothers making a more integrated solution, but then a again such basic features has not been on the roadmap for a very long time🤦‍♂️...)