How to assign file extension to exe.?

[ShaunR]

46 minutes ago, Mads said:

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🤦‍♂️...)

 

Edited July 11 by ShaunR

[Mads]

Oh, I knew. I just like to poke dormant threads (keeps the context instead of duplicating it into a new one) until their issue is resolved. Only then can they die, and live on forever in the cloud😉

[ShaunR]

4 minutes ago, Mads said:

Oh, I knew. I just like to poke dormant threads (keeps the context instead of duplicating it into a new one) until their issue is resolved. Only then can they die, and live on forever in the cloud😉

I can't even find threads I posted in last week. It's a skill, to be sure. 

[hooovahh]

So I use Inno Setup for making most of my LabVIEW installers.  It is pretty easy to setup file association with the registry like the LabVIEW Wiki mentioned.  Here is a post explaining some of the settings.  Once I'm on the LabVIEW side I've always used the property node Application >> Command Line Arguments. Maybe I've just used that because the event didn't always exist?  I'd like to think the property node gives you more control since I can send other command line arguments not just a file. But the majority of the time I do just want the file path.

[Mads]

On 7/11/2024 at 3:13 PM, hooovahh said:

So I use Inno Setup for making most of my LabVIEW installers.  It is pretty easy to setup file association with the registry like the LabVIEW Wiki mentioned.  Here is a post explaining some of the settings.  Once I'm on the LabVIEW side I've always used the property node Application >> Command Line Arguments. Maybe I've just used that because the event didn't always exist?  I'd like to think the property node gives you more control since I can send other command line arguments not just a file. But the majority of the time I do just want the file path.

Command line arguments is fine for the initial launch, but the helper app is used to also pick up double-clicks on associated files when the applictaion is already running.

Edited July 12 by Mads

[Rolf Kalbermatter]

On 7/12/2024 at 10:02 PM, Mads said:

Command line arguments is fine for the initial launch, but the helper app is used to also pick up double-clicks on associated files when the applictaion is already running.

I was fairly sure that there was actually an application event for file open events passed from the OS to the running application, but seem to have dreamed that up. It shouldn't be to difficult to add although might have some implications. Would have to be a filter event that can check the file name and then indicates if LabVIEW should further handle it (for LabVIEW known file types), or if it should be ignored (potentially handling it yourself).

 

Ahh, it's super secret private special stuff: 

And seems to have trouble in some newer versions than 8.2! Although Ton says he got it to work in 2009 again.

 

Edited July 15 by Rolf Kalbermatter

[dadreamer]

The task of intercepting WM_DDE_EXECUTE message has been around for a while here and there. Except that private OS Open Document event there are two more ways to get this done.

1. Using Windows Message Queue Library

2. Using DDEML of WinAPI and self-written callback library

More details can be found in this thread. I now think that it could even be simplified a bit, if one could try to hack that internal LinkDdeCallback function and reuse it like LabVIEW does. But I feel too lazy to check it now.

Edited July 15 by dadreamer

[Mads]

22 hours ago, Rolf Kalbermatter said:

I was fairly sure that there was actually an application event for file open events passed from the OS to the running application, but seem to have dreamed that up. It shouldn't be to difficult to add although might have some implications. Would have to be a filter event that can check the file name and then indicates if LabVIEW should further handle it (for LabVIEW known file types), or if it should be ignored (potentially handling it yourself).

 

Ahh, it's super secret private special stuff: 

And seems to have trouble in some newer versions than 8.2! Although Ton says he got it to work in 2009 again.

 

Yes, it does work 🙌 When that tip first got out way back it did not seem to do the job properly, but it does now, in LabVIEW 2022 at least.

I could not get the filter-version of the event to give me anything for some reason, but the regular does and it picks up opening multiple files together.

(Looking at the issue again earlier I noticed VIPM e.g. still uses the helper app (VIPM File Handler.exe), but perhaps that is just a legacy /  if it ain't broke, don't fix it thing. This is "supersecretstuff" too though, so trusting that it will continue to work is another issue.)

[Rolf Kalbermatter]

11 minutes ago, Mads said:

Yes, it does work 🙌 When that tip first got out way back it did not seem to do the job properly, but it does now, in LabVIEW 2022 at least.

I could not get the filter-version of the event to give me anything for some reason, but the regular does and it picks up opening multiple files together.

(Looking at the issue again earlier I noticed VIPM e.g. still uses the helper app (VIPM File Handler.exe), but perhaps that is just a legacy /  if it ain't broke, don't fix it thing. This is "supersecretstuff" too though, so trusting that it will continue to work is another issue.)

Could it be that the filter event only works for LabVIEW file types? There is no reason to let an application filter file types that LabVIEW doesn't know about how to handle anyway. They will be simply dropped into the "round archive folder" /dev/null anyhow if the normal event doesn't capture them.

Edited July 16 by Rolf Kalbermatter

[Mads]

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 🙁   (come to think of it this might be why it has not worked as expected in the past 🤔).

This might be a show stopper in cases where you *sometimes* want to be able to launch the app with additional/other arguments, 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..