PrestoSoft Community

Thanks again for all your efforts.

I did a quick try this morning, and I'm wondering if Jeremy's guess isn't correct (about the console). Here's a SC showing my running test1.exe that simply outputs 10 rows of info. As you can (?) see, the actual Rexx SAY's go to a NEW console window and not the same one as I'm running the exe in.

MAYBE, an idea might be to create those 10 rows as a simple file and then, from within the exe, run a DOS command that writes them to STDOUT ?
Something like (I'm simplifying some of the stuff for writing to a file) It's SO seldom I write any DOS commands, could someone help me with the DOS code to write to STDOUT. Something like print %1 > 1 or similar ?

BTW. What's an OP (OAP I could understand, since I'm 65 )

G'morning! "OP" is a commonly-used abbreviation on forums and newsgroups etc, and means almost always (the) "Original Poster" ie whoever started the discussion. Once or twice I've seen it mean (the) Original Post.

There's no command that in one command window will allow you to write sysout to another command window.

As far as an uncompiled test exec goes you will have to pass it the name of an output file, then open that file and write data to it. I think that will still work in the plugin definition if you specify

Application "C:\Program Files (x86)\Reginald\RxLaunch.exe"

and likewise in theory

Arguments "H:\A_MS_rexxcode\anothertest.rex" $INPUTFILEPATH $OUTPUTFILE

but there's a 'gotcha' with the rexx exec itself. When the newest test rex exec runs you cannot use

parse arg ifile ofile

to chop up the incoming argument string into two file paths, because 'space', the delimiter that 'parse arg' uses by default, can appear naturally in a file path. It would work by good luck if your file paths always had no spaces in them but you can't rely on that. IF EDP always wraps its filenames in double quotes (which I think it does), then you could use

parse arg '"'ifile'"' '"'ofile'"'

(that's got double-quotes characters inside single-quotes, telling rexx to parse on the literal presence of double quotes).

For one of your 'compiled' execs... I spent quite a while last night trying to find documentation in a downloaded copy of Reginald about how one goes about 'compiling' a Reginald rexx exec, and couldn't. That might be because (with Jeff Glatt's website no longer in existence) the saved copies of the site one can find only offer his most recent version of rexx, which he called 'rexxlite'. It was no longer even pretending to be standard rexx - he'd taken out all the bits of rexx he didn't like, leaving in it all his extensions to rexx. I failed to find a copy of his older 'reginald.exe'.... also I wasn't willing to try installing it (reglite.exe) in case it breaks my ooREXX install but just unpacked the installer(s) to look at the files within. I do not know if there is any documentation in your system for how to 'compile' a reginald rexx exec and if so whether it (a) describes how a 'compiled' exec works internally, or (b) offers any switches to alter that.

YES !!!!

Many thanks Jeremy for pushing/pointing me in the right direction. I finally got it to work using the following trick/workaround.
Since the BC program expected an output file (which it then used as input) I could use the same code, but, for ED, deliberately set a temporary output file. Then at the end of the code, with ED I had to ensure the file created was written to the console (as you pointed out). To do this, I used the following Reginald possibility. (where file_after was the file created earlier).
The Reginald documentation for command is as follows

To run a shell command (ie, an executable that displays text to a console window and/or expects its input to be typed by an enduser at a console window prompt), you can use the RxCmd add-on DLL. It has a function in it called Command. Its sole purpose is to let you run a console mode command/program.

The only "problem" I have is that it seems as if for each comparison, some console window flashes by (I never have time to see what the window title is). Now this could be Reginald flashing the screen even though I've specified HIDE as a parm (in which case I'd have to live with this).

Does anyone know of a variation (either with some form of redirection on the TYPE command) or a DOS different command that might be worth trying to avoid the flashing screen.

BTW.

2 comments.

The BC parms - you were right again. I removed the first parm so now I just use %s %t. I changed the code to only expect 2 parms and it worked fine.

My plug-in parms for ED are now
Application H:\A_MS_exe\BC_CONVERT_MFE_FILE.exe
and
Arguments $INPUTFILEPATH

Use exit code Yes, and success exit code 0

Well I'm glad you've got something working!

I think you would do well to consider installing ooREXX - unlike Jeff's Reginald, it's still being developed; although it's now an open-source project it started off as a 'proper' IBM product. A lot of people used to 'classic' rexx avoid it because they think it only has object-orientated stuff in it, but that's not the case. The downside is that it does not have any of Jeff's rexx extensions. If you did install ooREXX, you should be able to keep it separate from Reginald alright; part of the install process asks you what the rexx exec file extensions should be. They default of course to .rex (and two other forms - for execs run without a console window, or with one but it's held open until you dismiss it after the exec's run) but don't have to be that, so the associated .exe that runs them could be kept apart from what you use with Reginald.

I think you're still a bit confused. As far as I understand it, a plugin has to generate text which will be read by EDP. There are two ways of doing that. Either the plugin just writes to sysout and EDP is not told that there's an outputfile involved, so catches the sysout by (I assume) file redirection, OR you make the plugin write stuff to an output file ... but then you have to tell EDP to set up an output file before calling the plugin... which you do with the $OUTPUTFILEPATH parm in the settings.

You DON'T have to have an output file created and then use the 'DOS' (it's not DOS actually, it's cmd.exe under Windows) TYPE command to copy the file to sysout. You just need to have specified $OUTPUTFILEPATH on the definition of the plugin and make the plugin code parse that filename and use that as the place to write its data to. (I have tested that here and it worked.)

I think there's two possibilities for why you now see the screen 'flash'. One is that it has always happened but previously the plugin wassn't being called properly and the briefly-extant command window never got opened in the first place. Possibly it's never actually opened until something is written to it, and one of your earlier experiments didn't have any SAYs in it... Another possibility is that the output from TYPE has to go somewhere and so the window is opened to display it. It's hard to tell from here with no documentation on Reginald...

While writing my contributions above I noticed that sometimes I referred to $OUTPUTFILE and sometimes $OUTPUTFILEPATH

and went back to find out why I'd refrerred to both. It turns out that there's a documentation error, and some of my posts were
based on what I read in the help file and others on what I found EDP actually did.

In the help file [for: EDP Master 9.0.1.1 (64-bit)] there's a piece of text that says:

"if no output file name ($OUTPUTFILEPATH) is used"

and if you use the GUI option in Tools - Options - Plugins, that's the name of the variable that gets appended to the argument
string. But unfortunately also in the Help file, in the table of variable names just under that text, the named variable for the
output file path is

$OUTPUTFILE Full path of the output file

so that's what I used at first and also wrote about. It doesn't work; you have to use: $OUTPUTFILEPATH

You DON'T have to have an output file created and then use the 'DOS' (it's not DOS actually, it's cmd.exe under Windows) TYPE command to copy the file to sysout. You just need to have specified $OUTPUTFILEPATH on the definition of the plugin and make the plugin code parse that filename and use that as the place to write its data to. (I have tested that here and it worked.)

This is the bit I'm having difficulty understanding - the $OUTPUTFILEPATH parameter. As I showed earlier with BC, if I specified the %t (target file) as one of the parms when using the plug-in, a temp file name was passed as one of the arguments to the Rexx script.

If I specify $OUTPUTFILEPATH as the second argument to ED, as far as I can see, nothing is passed to my Rexx script (apart from the first argument).
I'm specifying the first line as and my input file contains no blanks. I even tried the following arguments

$INPUTFILEPATH c:\temp\temp.txt

but still wasn't passed a second parameter. ???????

BTW - I assume it's not because I have an evaluation version at the moment is it ?

How, precisely, are you checking in your rexx exec to see how many incoming parms there are?

Dööööhh.

All this time and it's been my fault !!!!! Here's an example of what I was originally using for my code (arg(1) and arg(2) were my last test attempts) I was assuming that parms1 would contain the first argument, and parms2 the second (ignoring for now potentially inbedded spaces). Here's a screen capture of the say results. As you can see, if I use arg(1) and arg(2) I do get the name of the temporary output file (exactly as I do with BC and its %s %t arguments). Just tested it with imbedded blanks in the filepath. Arg(1) and Arg(2) still work properly, whereas parms1 contains everything up to the first blank and parms2 contains the rest.

This means that I can use the same program for comparison as BC and skip the type command etc (now that I KNOW the name of the output file).

MANY MANY thanks Jeremy !!!!!

Hooray!

I'm guessing that this is because Windows (or within EDP, a call to a Win API routine to execute a command) would have Windows parsing the passed command line and splitting it into yourcompiledrexx.exe (or rxlauncher.exe) then successive arguments (in C terms) which are then passed to the rexx interpreter.

Whereas if you issue a command in a command window to execute explicitly an interpreter and a named exec, or implicitly just the named exec, whatever follows that is passes as a single string to rexx. (Unless Reginald treats it differently). That is, in a command window

C:\myrexx.rex followed by anything at all no matter what

will always give rexx ONE argument. In ooREXX the only time you'd see arg(1), arg(2) etc being used is inside a rexx function.