anyone have experience passing arguments to command line with lpflashex?

[xrobbyx]

I'm developing an application that takes form input in flash, and passes the variables out to a number of different RTF documents. I'm currently using lpflashex as an application wrapper, and SED as the search and replace utility. I'm having a problem when it comes to passing the arguments to SED from flash.

Here's the commandline script, which is what I'm trying to emulate from within flash. This assumes calling sed from the main CD directory, and sed and the source docs are currently in a folder called "util"

util\SED -e"s/txt_1/text replace here/" <util\source.rtf >util\output.rtf
This does exactly what I want from the command line, and I know I can pass arguments with this command from lpflashex:

LP.exec("exec", "PROGRAMNAME", "ARGUMENTS", "", 1);

After messing around with it, I got the command to halfway work. I can pass the part that tells it what to replace and the source file(-e"s/txt_1/text replace here/") and (<util\source.rtf ) but the output just gets sent to the console, and not to the output file.

As best I can tell, it seems to be ignoring the < and > that designate the input and output. Or maybe it's a whitespace issue?

Does this sound familiar to anyone? Or does anyone have any suggestions? I would like to continue using lpflashex, just because I already have it, but if there's another tool that will spare me the headaches, I'd be open to that as well.

Thanks!

[Northcode]

I/O redirection (using < and >) is handled by the command processor (DOS) so if LPFlashEx is using CreateProcess (as it probably is) then the redirection won't take place. What you have to do is launch the command processor to handle the command line, it's only a slight change to your existing fscommand from

fscommand("exec", "your_command_line_here")

to this

fscommand("exec", "c:\\winnt\\system32\\cmd.exe /c your_command_line_here");

The /C is a CMD.EXE argument and the command line that you would normally type at the command prompt follows the /C.

CMD.EXE only exists on Win NT, 2000 and XP so if you want to do this on 9x and Me systems you should use COMMAND.COM instead of CMD.EXE.

You will also need to provide the full path to the command processor (like I did). This will always be the Windows system directory, but you should figure out where that is at runtime instead of hard coding it like I did for this example.

[xrobbyx]

THANK YOU SO MUCH!!!!!

I spent so long beating my head against my computer trying to figure that out last night... I just tried what you said and it worked perfectly.

[xrobbyx]

One last thing before this application works for me. I don't currently have a windows 98 box to test my app out on, so can anyone tell me the folder location for command.com? is it in system?

or does it even matter because it's in the windows path? So I could call it from anywhere?

Thanks!

[Northcode]

It will be in the Windows System directory which should be in the PATH, but it could be moved on a security hardened machine i.e. one that's had the security tightened up and system files moved to prevent things like viruses from taking advantage of well known vulnerabilities. The safest solution involves multiple steps (i) find the Windows system dir (ii) find out where the COMSPEC environment variable is pointing (it should be at the current location of COMMAND.COM) and then (iii) check for the existence of COMMAND.COM before trying to use it.