I'm working with AREV 3.12 on WinXP and I want to call an external .NET EXE program. Send it data and receive data back from it.
I've only recently learned of this approach and I'm trying to create a simple proof of concept process. My first attempts of:
PERFORM 'SUSPEND NOTEPAD.EXE'
and
PERFORM 'SUSPEND NOTEPAD.EXE MYFILE.TXT'
have been successful as far as they went. In my research, I found out how to call an EXE program and send it parameters like:
public static string main(string args)
{
…
}
The "args" is an array of strings seperated by spaces. This is easy enought to pull apart and deal with on the .NET side. I found out how to return a value to the calling program. What I haven't yet been able to figure out is how to pull that returned value into the calling AREV program so it could be used. Can anyone point me in the right direction? Is there a better approach?
Thanks,
Michael Slack
Write it out to a DOS file and OsRead it. Look at using START as well - provides you with more options.
World leaders in all things RevSoft
In my research so far, I remember coming across a brief mention about "START" but I can't find it again, yet. Is that a DOS command? If so, would that be a DOS 7.0 command? That would explain why I can't find it in my DOS 6.22 book or my AREV manuals. I'll keep looking.
Thanks,
Michael Slack
Hello Warren:
Thanks for the link. I was finally able to find some other links that talked about the "START" command. Some were more useful than others. This one looks like it'll be the most useful.
In playing with the "START" command, I found (at least in my environment) that the "/b" seems to negate the "/wait" parameter. Since I'm just at the get to know ya stage with this command, I'm assuming that any external EXE I call from my AREV applications, that I'll want to wait for it to finish and return whatever before I continue my AREV based processing.
Thanks,
Michael Slack
It was recommended that I use the START command. Typing in the commands by hand they worked. From TCL entered SUSPEND. From the DOS prompt entered START "" /WAIT NOTEPAD.EXE. An empty Notepad window displayed as expected. But when I put the following 2 lines into a simple program:
CMD=SUSPEND START "" /WAIT NOTEPAD.EXE'
PERFORM CMD
I got the AREV DOS widnow going away briefly before being redisplayed. No Notepad window was disdplayed. Checking the TCL stack, it looks like the line was executed. After trying as many variations as I could think of (including using the EXIT option), I finally tried:
CMD=SUSPEND NOTEPAD.EXE'
PERFORM CMD
This worked from the program and by hand. Am I doing something wrong? Or is there a setting in my application and/or environment that needs to be changed? Any suggestions as to why the START will work when entered by hand but not thru a program? I like the idea of the "/WAIT" switch, espeically if I expect back a returned value or need to read a file of returned information.
Thanks,
Michael Slack
START is an internal command of CMD.EXE under XP. Prior to XP START was an EXE or COM file.
For what every reason ARev shellexecute through COMMAND.COM where START is not an external command. Since START.EXE/COM doesn't exist on XP systems nothing happens,
What you have to do is call start through CMD.EXE:
sent=SUSPEND CMD /C START /W NOTEPAD.EXE"
Perform sent
For kicks from TCL type
SUSPEND VER
Then again from TCL just
SUSPEND
and at the DOS prompt type
VER
See the difference?
Hello Warren:
That's the piece I was missing. With it, I've been able to get my initial tests to work. Now I'm onto creating a simple skeleton test to pass data between my AREV application and a .NET program and back again. After I figure that out, a much wider world will be possibilities will open up.Thank you,
Michael Slack
Hello Warren:
At TCL, when I type SUSPEND VER, the DOS window goes black for a fraction of a second and then redisplays my original DOS window now with a blank TCL. I'm assuming that VER command runs and displays so fast that I can't see it.
From TCL, when I type in SUSPEND and then at the DOS prompt type in VER, I see the version information.
Just for kicks I tried SUSPEND CMD /C VER. With that, I did see the version information being displayed. But it displayed so fast that I couldn't blink if I wanted to see it.
I assume that the combined TCL command of SUSPEND VER goes by so fast because there isn't anything in the VER command to pause the version display before returning to the calling location. Since it's not actually on a DOS window so a DOS prompt would in effect allow me to see it. That what I'm seeing is a DOS window displayed with the version information and then immediately closed and the original AREV DOS window redisplayed.
I can imagine that both approaches could be useful, depending on the need and the amount of processing that is needed. If you don't care about the screen flashing and the user didn't actually need to see what was going on, that approach might help speed up processing by not needing user interaction. It might better be left of an unattended process. Where there is a pause, I can see would be useful for smaller processes and you want the user to see the steps as thing progress. Plus a lot less eye strain for the user.
Thanks,
Michael Slack
It may be how I have my _default.pif set but when I do the "SUSPEND VER" I get a "press enter to return to Advanced Revelation" at the bottom of the screen.
However it reports:
MS-DOS Version 5.00.500
Thanks to everyone for your help. With your help, a lot of searching on the web and that of a co-worker, I was able to create a small and simple proof of concept program.
Here is the core of what I've learned. Below is the core of the command to call an external EXE program.
TEMPORARILY HALT AREV TO RUN AN OPERATING SYSTEM COMMAND.
CMD =SUSPEND '
STARTS A NEW INSTANCE OF THE WINDOWS XP COMMAND INTERPRETER.
CMD := 'CMD /C '
STARTS A SEPARATE WINDOW TO RUN A SPECIFIED PROGRAM OR COMMAND.
CMD := 'START /WAIT "" '
CMD := 'NOTEPAD.EXE'
PERFORM CMD
Here are some of the other things I was able to do in place of the NOTEPAD.EXE above.
Call Notepad with a particular file that is automatically opened into the Notepade window.
CMD := 'NOTEPAD.EXE "C:\DUMMY FILE.TXT"'
Since on my machine's Window Media Player is associated with MP3 files, this is essentially the same as going to this location and double clicking on the file.
CMD := 'C:\Audio\Music\Leyenda.mp3'
This calls up a simple Visual Studio 2008 form that displays a message.
CMD := 'C:\FromArev\RunExeTest\RunExeTest\bin\Debug\RunExeTest.exe'
Here I called up a Visual Studio 2008 form that displayed PARAMETER1 which was entered by the user thru an AREV message RC box. Appently the total length of the command went over 256 characters (a limit I think I've been told about in the past), so the only way to make it work was to copy the EXE's from the Build into a location closer to the root. The other thing I had to do was on the AREV side, replace spaces with some other character. Because parameters are seperated by spaces. Then on the VS2008 side replace the characters with spaces. On the VS2008 form, the user could enter another string of text. I wrote that to a text file so the AREV program could read it and display it. Thus being able to pass data between the two programs.
* CMD := 'C:\FromArev\CalledFromArevTest\CalledFromArevTest\bin\Debug\CalledFromArevTest.exe ' : PARAMETER1
CMD := 'C:\CalledFromArevTest.exe ' : PARAMETER1
The last thing I did was call a web page. Again this is just like double clicking on a link in an E-mail or document. It used my default web browser. I did find that in the link below in this case was case sensitive (at least the last part) so I had to put it into quotes to make it work.
LINK=http://www.youtube.com/watch?v=Ez1MgopJD9g'
CMD =SUSPEND '
CMD := 'CMD /C '
CMD := 'START /WAIT "" '
CMD := QUOTE(LINK)
PERFORM CMD
Now if we are to use this newly learned capability, we'll have to figure out what the best way to pass data in and out of AREV and whatever outside program / application that'll be called.
Thanks to everyone for your help. Now it's just a matter for those who make those kind of decisions to decide how we can best use this new knowledge to help our users and processes,
Thanks,
Michael Slack