Command line failing to run

[kpassaur]

This is from a rather large compiled script - it used to work but now it doesn't - something had to have changed with the OS

The ProgramFolder is where the file "renderit.exe" resides - it is a 32 bit application that converts a PDF to a Tiff Image

ChangeDirectory>%ProgramFolder%
Let>RP_WAIT=1
Let>RP_WINDOWMODE=0
RunProgram>cmd /c renderit.exe "%settinsdir%\temp\single_%f%.pdf" "%OPF%\%outputfile%.tif" /M /DPI 300 /1BPP /dither

// the above runs, but does not do anything - it has worked for years but now generates no output

I have tried:

RunProgram>renderit.exe "%settinsdir%\temp\single_%f%.pdf" "%OPF%\%outputfile%.tif" /M /DPI 300 /1BPP /dither
It generates an error

Regardless of what I try it does not work and it used to


So, to fix it (but not correctly) I did the following

//I wrote the parameters that are to be passed to the file to text file
WriteLn>%settinsdir%\temp\line.txt,result,"%settinsdir%\temp\single_%f%.pdf" "%OPF%\%outputfile%.tif" /M /DPI 0 /1BPP /dither

I then created a new MS file called "pdf_render.exe"

This program contains

ReadLn>%settinsdir%\temp\line.txt,1,path
ChangeDirectory>%ProgramFolder%
Let>RP_WAIT=1
Let>RP_WINDOWMODE=0
RunProgram>pdf_render.exe %path%
Wait>.5
DeleteFile>%settinsdir%\temp\line.txt

This works, does anyone have any idea as to why it would not run correctly in a bigger script? I have also tried the playing around with RP_WIN64PROCESS, SYS_NATIVE etc with no results.

[Marcus Tettmar]

I think you need the path in the Run Program line. In your first example you are changing the working directory but then running it via CMD.exe which may have IT'S OWN working directory. Try:

Code: Select all

RunProgram>cmd /c "c:\bla\whatever\renderit.exe "%settinsdir%\temp\single_%f%.pdf" "%OPF%\%outputfile%.tif" /M /DPI 300 /1BPP /dither

Also do this:

Code: Select all

MessageModal>cmd /c "c:\bla\whatever\renderit.exe "%settinsdir%\temp\single_%f%.pdf" "%OPF%\%outputfile%.tif" /M /DPI 300 /1BPP /dither

Then copy out the contents of the message box and paste it into a command window - does it work? If not it will at least give you an error without the window disappearing - so you have a chance to see what the issue is. Whereas running it from Macro Scheduler, you're not going to have time to see any output before CMD.exe terminates. Once you have it correct, copy it back to Macro Scheduler.

[kpassaur]

Thank you, I tried both of those before posting. The first didn't work and the second when I copied it and pasted it into a command prompt window it did. This is where it gets good. My fix worked on the machine I wrote it on which is Windows 7 64 bit machine. I put it on a Win 10 machine and it generated a 64 bit redirection error. I had tried playing with that before with no success as well as SYS_NATIVE. This could be an issue with me and syntax.

So, it works in the command prompt window (this has been running for years), does not generate any output from the script (it just runs), if I change it I get the redirection error.

So my posted fix failed on Winn 10, my latest fix seems to work. I took pdf_render.exe out of the "c:\program files (x86)\edocfile\Print and File" subfolder and put it in the same folder as the files to be processed ("c:\programdata\edocfile\Print and File\temp") and it seems to be working fine.

So it somehow has to do with redirection / 64 and 32 bit machines I suspect. Naturally I would like it in the same folder as the other files but so it goes. I should mention that I had a similar issue about five years ago where I had to place the program in the same folder as the files if using MS. However, after a few windows updates I didn't have to anymore.

[Marcus Tettmar]

The message about Win64 is just a suggestion. Not necessarily the cause of an error. Is it a 64 bit process? Shouldn''t really matter as you are just calling cmd.exe.

Are you able to send me a copy of renderit.exe - or can I get it from somewhere - to try it? You can send to support.

[kpassaur]

I have attached it and appreciate your help on this. I am confused as I wrote this back in 2012 or so, and It worked fine for years. If you want the whole program it can be found at "http://www.edocfile.com/downloads/Setup ... d_File.exe"

The whole program does more than just batch process pdf's into tifs. It separates the file based upon content, adds barcodes renames and moves the files etc.

You have the syntax in the example. All it really needs is an input pdf and a name for the output tif. The switches are not necessary but without them you will end up with a massive uncompressed tif.

I received a message that the attachment was to big so I put it here
Http://www.edocfile.info/pdf_render.zip

[Marcus Tettmar]

Working fine for me. I dropped pdf_render.exe into my documents folder, where I also happened to have a PDF file already. Then ran this:

Code: Select all

Let>cmd="%USERDOCUMENTS_DIR%\pdf_render.exe" "%USERDOCUMENTS_DIR%\ssc.pdf" "%USERDOCUMENTS_DIR%\out.tif" /M /DPI 300 /1BPP /dither

Run>cmd

out.tif was produced successfully.

This is under Windows 10.

[kpassaur]

Yes it will, the fix appears to be to remove it from a subfolder of c:\Program files (x86) and put the files in the same folder. Where the issue is in storing pdf_render.exe in:

"C:\Program Files (x86)\eDocfile\Print and File"
and having the input files in:
C:\ProgramData\eDocfile\Print and File\temp

I think by taking it out of the (x86) Program Files folder it does something different with redirection.

[Marcus Tettmar]

I think you're confused. Redirection has nothing to do with running programs or program files. Redirection is when Windows forces a 32 bit app to run the 32 bit version of a system component.

I can't see why the folder it is in would make any difference.

To be sure I have just created a folder called eDocFile in my Program Files (x86) directory and put pdf_render.exe in there. Modified the script accordingly. It again ran perfectly. Here's a screen-cast:

http://vids.mjtnet.com/watch/cDQ32yjqzD

[kpassaur]

It won't work on mine or my clients. Perhaps there is a conflict with something else the script calls. I brought up the redirection as that is what the error says. At this point all I care about is that it is currently working.