Command line application with optional GUI

[Braggel]

Dear All,

I need a command line application that doesn't open the GUI when you have added switches to the commandline call. Thus, when I call my application without any switches, it opens the GUI and I can use it interactively. When I call my application with command line switches, I don't want it to show anything. It would also be nice to incorporate normal output and error ouput to the console...

Is there a nice way to do this?

I saw that you can create a .dll and write a wrapper calling this .dll in C or C++. Would this work for my idea also? (Although I prefer a complete Labview solution.)

Thanks already!

Filip Verbinnen.

Laborelec.

[Gleichman]

The VI Property FP.State can set the window to "Hidden", but I think it will still show in the task bar. I don't think there is anyway to return a value to the command line.

[Thoric]

It is possible to get the command line arguments within LabVIEW. Open an Application Reference and feed it to a Property Node. You can extract the Application>Command Line Arguments string property there.

As Gleichman states, you can programmatically set the front panel display visibility through more property settings. You could set the VI not to load it's front panel on launch, and then programmatically make it appear if the command line arguments string has no arguments (be careful here because I think the executable filename is always returned as a first argument - you'll need to discount this)

Not sure about returning information to standard out or error out though..

[LabBEAN · Accepted solution]

LabVIEW EXEs require a Start Up VI.  The Start Up VI is going to show its panel (regardless of VI Properties) when it runs.  You can run the FP.Open.Hidden method, but you may see a blink since the panel will open and then close immediately.

To retrieve the command line arguments, see:

Help >> Find Examples >> Search tab >> type "command" >> double click CommandLine.vi

No way (that I've found) to output a return value back to the command line.  Compile a DLL from the LV project Application Builder if that's necessary.

Message Edited by LabBEAN on 07-29-2009 02:07 PM

[Braggel]

Hi all,

Thanks for the suggestions! For now, I'm just keeping the window from the first VI open (this VI is the commandlineLauncher)... I'd rather have it not appear at all... To fancy this one up then,... What's the best way to transfer a status of the running subvi's to this commanlineLauncher VI? I figure that Global variables would be a nice start, but is there anything more suited maybe? E.g. my program transfers a bunch of data to a server. This is done in a subvi. It would be nice to get a progress bar on the very first commanlineLauncher VI...

Btw. What about services? Can we make Windows XP services in Labview?

Thanks again!

Filip Verbinnen.

Laborelec.

[LabBEAN]

Global Variables have by and large been replaced by Single Process SVs (Shared Variables) because it is easy to convert a Single Process SV to a Network Published SV later on.  That said, you won't have to look far on these forums to see the draw backs caused by race conditions with Global Variables (or Single Process SVs).

For your application, it would be easy to pass data between the EXEs with a Network Published SV.  This type of SV has to be deployed into the National Instruments Variable Engine, which runs as a Windows service at startup.  For the purpose of the attached example, you can deploy the SV directly from the LabVIEW project (right click on Variable.lvlib and select Deploy).  There are two EXEs included demonstrating passing data from one to the other.

I've also attached an example demonstrating the inablility of the same with a Single Process SV.

See here to convert your application to a Windows service.

Message Edited by LabBEAN on 07-30-2009 01:44 PM

[F._Schubert]

Actually I was going to suggest you to considere a service for this, as it has no GUI at all. There is a very good document on ni (a different one than the one linked by LabBean), I don't have it at hand right know but I will post it tomorrow (I've bookmarked it).

The communication between the service and the optional GUI: I would suggest you to use the VI Server posibillities.It might be as simple as your GUI just polling the controls of the service and writing that data on it's own visible controls. To ease things here, get yourself the OpenG package for application control.

To report errors, seach for damiens developements on debugging race conditions. He writes to the error output stream.

Felix

[LabBEAN]

Here are two other links that are referenced at the bottom of the previous.  Like Felix, I thought I had a document on this.

Creating a Windows NT Service using LabVIEW

Install Application as Windows Service (this one is a community example)

[F._Schubert]

Thanks LabBean, the first one is the one I have (I didn't catch it from the list on bottom of the other document). It is a pretty straight forwared guidance through the complicated process.

Follow it strictly!

Felix