Use command line to specify to an executable which file to open

[SimonJarvis]

Hi, hope this is in the right place, apologies if not.

I have never used Labview and am having a problem with a standalone executable I have. This has been created by someone else to convert from one file format to another. When the executable is run it presents a dialogue for input file path, then output file path, then converts the input to the output file. I would like to be able to tell the program which files to use from a command line so that I can create a batch file to process multiple files.

I have experimented with typing two hyphens then the two different paths after the name of executable to send user arguments to the program however that doesn't seem to work. Is there anyway I can find what the variables that correspond to the input and output files are so that I can set them from the command line? Or can anyone think of a better way to achieve this? Any help is greatly appreciated, many thanks in advance.

[silmaril]

It is possible to read the command line options in a LabVIEW application, but only if the programmer made the effort to implement it.

If he didn't document any special command line options, the best guess is, that there are none. :headbang:

So command line won't help you much here.

Maybe you could achieve your goal using AutoHotkey?

[Yair]

From the fact that you are asking the question I assume that you no longer have access to the original developer.

Do you at least have a copy of the source code? If you do, you can commision another LabVIEW developer to build a command line interface. If not, you're basically stuck with the other suggested option.

For what it's worth, though, you might be able to use the ActiveX interface available with LabVIEW to connect to the program from another program and input values into it. Do you have any programming experience?

[Rolf Kalbermatter]

QUOTE(yen @ Sep 8 2007, 02:22 PM)

From the fact that you are asking the question I assume that you no longer have access to the original developer.

Do you at least have a copy of the source code? If you do, you can commision another LabVIEW developer to build a command line interface. If not, you're basically stuck with the other suggested option.

For what it's worth, though, you might be able to use the ActiveX interface available with LabVIEW to connect to the program from another program and input values into it. Do you have any programming experience?

In order to be able to connect to a LabVIEW application over AcitveX it also must have been build with that option enabled. I personally always make sure that option is disabled for various reasons, including safety.

Rolf Kalbermatter

[SimonJarvis]

Thank you for all your help. As you guessed I have no access to the developer, only the compiled exe. I also don't have the source code. I've looked at Autohotkey and that seems to be the best way, I'm currently working my way through writing a script. Luckily I have a bit of experience writing in Basic so it is not proving too hard to learn. Thanks again to you all.

[SimonJarvis]

After a productive day playing with Autohotkey, my script is now working perfectly. I've saved myself a lot of time, many thanks again, particularly to you silmaril!

[Yair]

QUOTE(rolfk @ Sep 10 2007, 11:52 AM)

In order to be able to connect to a LabVIEW application over AcitveX it also must have been build with that option enabled. I personally always make sure that option is disabled for various reasons, including safety.

I was actually thinking about VI server, which as far as I know can be activated using the INI file, but I assume that can only be accessed from programs which can use the protocol.

I only thought about it now that this is probably a security risk. If anyone can add keys to the INI file and then connect to your app, that could be a serious problem. Then again, if someone has write access to the INI key, they could also do other nasty stuff.

[Ton Plomp]

QUOTE(yen @ Sep 10 2007, 08:19 PM)

I was actually thinking about VI server, which as far as I know can be activated using the INI file, but I assume that can only be accessed from programs which can use the protocol.

I only thought about it now that this is probably a security risk. If anyone can add keys to the INI file and then connect to your app, that could be a serious problem. Then again, if someone has write access to the INI key, they could also do other nasty stuff.

Well a good security strategy would eleminate those things in the initialization VI via VI server

(No I have never worried about this) :headbang:

Ton

[jpdrolet]

QUOTE(yen @ Sep 10 2007, 02:19 PM)

I was actually thinking about VI server, which as far as I know can be activated using the INI file, but I assume that can only be accessed from programs which can use the protocol.

I only thought about it now that this is probably a security risk. If anyone can add keys to the INI file and then connect to your app, that could be a serious problem. Then again, if someone has write access to the INI key, they could also do other nasty stuff.

I'd say that if someone has access to the EXE and its INI, security is already seriously breached...

The VI Server can be stopped programmatically using app property nodes so it is good to stop it at program initialisation.

However one can still drag and drop any VI on your running app (or execute the command line) to run a VI to reenable the VI Server programmatically...