Dos window content

[m.waschk]

Hi all,

i

[dhuff]

have you looked at the System Exec.vi (located on the Communications Pallette)?

[m.waschk]

have you looked at the System Exec.vi (located on the Communications Pallette)?

4839[/snapback]

yes i did, but there are only two possibilities:

"Wait until execution ends" and "do not wait until execution ends"

With none of them i can readout the window content during the execution...

... i thing i forgot to mention that want to readout during the execution, sorry...

[m3nth]

Hi all,

i

[martin@aerodynamics]

Hello I am using the System Exec.vi to send dos commands. This vi also get's back the content of the dos window....

Example: You could use the ping command. When the dos window close you will get back the dos window content as a string (If you wait until completion)

However, this works not if you want to poll an existing dos window...

(Maybe there is a work around)

[m.waschk]

....

However, this works not if you want to poll an existing dos window...

[dhuff]

does your dos command finish quick? I have used the DOS output redirect command to pass results to somewhere I can find. Then you just read the results back into labview.

For example, the command below will "redirect" the output of the dir command into a file called output.txt:

C:\dir *.* > C:\output.txt

I have used this for a quick and easy way to read the results of DOS commands issued in Labview back into Labview.

[m3nth]

does your dos command finish quick?  I have used the DOS output redirect command to pass results to somewhere I can find.  Then you just read the results back into labview.

For example, the command below will "redirect" the output of the dir command into a file called output.txt:

C:\dir *.* > C:\output.txt

I have used this for a quick and easy way to read the results of DOS commands issued in Labview back into Labview.

4907[/snapback]

This has already been covered and will not work since he wants to poll the dos window. Please read the entire thread before posting hastily.

[Rolf Kalbermatter]

This has already been covered and will not work since he wants to poll the dos window.  Please read the entire thread before posting hastily.

4908[/snapback]

Basically you need to redirect the standard input/output of the process to some IO channels and intercept them. NI has done this for the Unix variants of LabVIEW with the VI Open System Command Pipe or similarly named VI. On Unix this is quite simple as it is the standard way of doing such business. Windows is a lot more involved. The concept of standard IO is basically only added later to the DOS environment in a somewhat complicated way and porting that to the emulated DOS environment in Windows made everything even more complicated.

I have started some work on OpenG on a module called pipe which is supposed to execute a program and redirect its standard IO to Windows pipes which would allow to write to the program standard input and read from its standard output. This of course won't work for normal Windows applications as they have usually no standard IO at all but rather use a GUI for interaction with the user.

The current state of the pipe module on OpenG is still a work in progress. It does show how it is supposed to work but there are still problems and crashes with it. At the moment I have not enough time to spend on this nor enough motivation but if anyone with some serious C programming knowledge wants to look into this, I would think this to be a good starting point. The module is located at http://cvs.sourceforge.net/viewcvs.py/opengtoolkit/pipe/. Other than spending the time to make this work I would guess that only the mentioned ActiveX component would currently give a working solution.

Rolf Kalbermatter

[dhuff]

OK, before we get into flame wars, my suggestion was to use an easy DOS command, basically it is no extra software to build or buy, so everybody relax, I was trying to get a simple point across.

Some important questions:

Why do you want to know the contents of the window DURING RUNTIME?

Is there something there in the DOS window that will not be there when it finishes?

Does this DOS sequence involve many steps or commands?

Does it involve keypresses or user input decisions too complex for the computer?

Is this on a remote platform or other special platform that does not facillitate easy use?

Is this DOS process long enough that you can not wait for the result to finish?

My central point is:

Most of the time, DOS or system exec commands are "one time events" meaning once you invoke the command, it will execute in a seperate process until it pauses, crashes, finishes, or exits. THERE IS VERY LITTLE YOU CAN DO TO STOP DOS ONCE IT STARTS, so the question is why would you want to stop it or change it? You launch DOS to execute a DOS command, the computer thinks, and then shows a result. The DOS System Exec is really a seperate process, it was designed that way on purpose. If you use a output pipe command, it will give you a complete record of what happened after the fact, but it can't change what runs in the command line.

If the commands you run take a long time or need to have user inputs or displays, look at using the application focus part of Labview, you can make the DOS window be on top of the Labview window, or the other way around.

[Rolf Kalbermatter]

 

 

My central point is: 

Most of the time, DOS or system exec commands are "one time events"  meaning once you invoke the command, it will execute in a seperate process until it pauses, crashes, finishes, or exits. THERE IS VERY LITTLE YOU CAN DO TO STOP DOS ONCE IT STARTS, so the question is why would you want to stop it or change it?  You launch DOS to execute a DOS command, the computer thinks, and then shows a result.  The DOS System Exec is really a seperate process, it was designed that way on purpose.  If you use a output pipe command, it will give you a complete record of what happened after the fact, but it can't change what runs in the command line. 

 

If the commands you run take a long time or need to have user inputs or displays, look at using the application focus part of Labview, you can make the DOS window be on top of the Labview window, or the other way around. 

4955[/snapback]

 

Well, on Windows you are in fact right most of the time. DOS commands are something invoked and quitting almost instantly. However on Unix it is very common to have a tool (just think about putty for instance, which you start and let do the work of establishing a secure transport layer and also maintaining it.)

Now with redirected standard IO this is very simple. Start up the tool, tell it through the redirected standard input the commands to connect and login to the remote system, monitor the redirected standard output for the responses of the program and then start to communicate across the communication channel provided by this tool through the same redirected standard IO channels. At the end send it the command to close down, et voila. No need to include a secure socket communication library into your program or under Windows find out how to call the often not so well documented APIs through many Call Library Nodes if they are provided with the desired secure protocl at all.

With Windows you can also do programmed standard IO redirection for invoked command line tools, but to do so is quite hard (and usually wouldn't work for GUI programs since they do at most times not handle standard IO at all). So it is seldom used but it can be useful nevertheless. Turtoise CVS uses this for instance to talk to the CVS client which does the actual CVS work, since the CVS client is really a command line tool. Rewriting the CVS client as a DLL would have been possible, but that would create a second code base which has to be thoroughly tested again, while the command line tool has been tested in years of operation already.

So while it is rather esoteric to intercept standard IO on Windows at runtime of a command line tool it is possible, albeit with difficulties, and at times useful.

Rolf Kalbermatter

[m.waschk]

....

Some important questions:

Why do you want to know the contents of the window DURING RUNTIME?

    In there appearing things I need to know at the time they are appear.

Is there something there in the DOS window that will not be there when it finishes?

    ...no only too late.

Does this DOS sequence involve many steps or commands?

      yes, it does

Does it involve keypresses or user input decisions too complex for the computer?

      no

 

Is this on a remote platform or other special platform that does not facillitate easy use?

      no

Is this DOS process long enough that you can not wait for the result to finish?

      ???

4955[/snapback]

Greetings

M.Waschk

[Rolf Kalbermatter]

Greetings

M.Waschk

4960[/snapback]

Well, I'm very sorry but I didn't keep my promise of not working on the OpenG Pipe library ;-).

So I have created a first, appearently working version of that library. There are many possible problems with this and I have only done limited testing but it seems to work for what I have tried. So whoever feels like trying this out, feel free. I can't promis that I can do something if it doesn't work for whatever reasons.

The attachment is an OpenG package of the library. I can't seem to upload *.ogp files so I gave it a ZIP ending.

It would be best to rename it to .ogp and first download OpenG Commander and install it through it. Also you should get at least the ogrsc_dynamicpalette package in that case. Alternatively you could open the file with any ZIP extractor tool and put the files where you want them. The second file is a ZIP file containing a test VI and an external command line program for this test. The test VI should give you some ideas how to use the VI library.

Documentation is non-existent at the moment, so you should know your command line program you want to use with this and also be willing to do some trial and error.

Rolf Kalbermatter

Download File:post-349-1118609673.zip

[Rolf Kalbermatter]

This is the test archive

Download File:post-349-1118609275.zip