Command line length limitations

[ChrisRChamberlain]

Hi

I am developing a VFP application for use with Zeon corporation's PDFCMD Control Interface.

By way of background, this is a 32 bit command line program to provide basic PDF handling functions, expressed as "C:\path\pdfcmd c -c target.pdf first.pdf second.pdf..." etc.

The command line string is "assembled" by the interface into a memo field, .string, in a cursor named CMD_LINE, and executed through the following code:-

DECLARE INTEGER WinExec IN kernel32 ;
[tab]STRING lpCmdLine ,;
[tab]INTEGER uCmdShow

* 0 = Hide
* 1 = Normal
* 3 = Maximized
* 6 = Minimized

WITH THISFORM
[tab]DO CASE
[tab]CASE .opgShowWindow.Value = 1
[tab][tab]lnWindow = 0
[tab]CASE .opgShowWindow.Value = 2
[tab][tab]lnWindow = 6
[tab]CASE .opgShowWindow.Value = 3
[tab][tab]lnWindow = 1
[tab]OTHE
[tab][tab]lnWindow = 3
[tab]ENDC
ENDW

lcProg2Run = ALLT(CMD_LINE.string)

IF !WinExec(lcProg2Run,lnWindow) > 31
[tab]WAIT WINDOW [Unable to create PDF]
ENDIF

If the length of the command line is in excess of approx 300 characters, (it varies), Windows 98SE is likely to crash bigtime without warning, often requiring the use of the Reset button.

According to Zeon, there is no practical limit to the length of the command line string, so the problems appears to be with the way VFP is interacting with Windows through this WinAPI call, and therefore is there a limit on the length of the command line string?

Any ideas please?

Chris

 

[dgrewe]

At one time in the life of Fox, (way back when and so long ago I can not remember when,) there was a 256 char limit on the command line. I got so used to making the commands short that I never needed to know if the problem was every fixed.

(note I said Fox, not FoxPro, Not VisualFoxPro) ops, i just gave away my generation. David W. Grewe
Dave@internationalbid.com
ICQ VFP ActiveList #46145644

 

[ChrisRChamberlain]

David

Thanks for your response.

One reason for using a WinAPI call is to attempt to get beyond the 256 character limit, and the second is that by using a WinAPI call, you can run the program hidden, and thus stop a user "interfering" with its execution.

I was hoping, perhaps in vain, that the WinAPI call would extend the rather limited scope available.

Part of the problem is that PDFCMD works by basically contatenating path\filenames which individually can be very long in their own right.

Come back DOS - all is forgiven!!

Chris

 

[rgbean]

Chris,
I don't have an answer for your problem directly, but I've used the modified ShExecute which uses a WinAPI call to "ShellExecute" by John Harvey. Go to

http://home.att.net/~john.harvey/vfpstuff.htm

and in "Other Stuff", get "Modified Shellexecute class".

Rick

 

[ChrisRChamberlain]

Rick

Thanks for the link - if it doesn't work I have devised a way of working within the 256 - 300 character limit and still concatenate over 30 PDFs at a single session.

Chris

 

[jonscott8]

Chris,

I know Windows imposes a maximum path length of 255 characters. That can be illustrated by running the following code:

strtofile('test','C:\'+replicate('A',248)+'.vbs')
strtofile('test','C:\'+replicate('A',249)+'.vbs')

The first file will be created as expected. The second will be created with a .VB extension because the 256 character (s) is truncated.

AFA your question IRT the command line length, I dont have Zeon's app to test, but I did a quick test with the WSH and it had no problems with command lines of large lengthes.
In case you want to see an illustration of my test, paste the following into a VFP prg and execute it:

lcPath = 'C:\'+REPLICATE('A',200)+'.VBS'
lcScript='DIM oArg' +chr(13)
lcScript = lcScript+'SET oArg = WSCRIPT.ARGUMENTS'+chr(13)
lcScript=lcScript+'WSCRIPT.ECHO WSCRIPT.SCRIPTFULLNAME'
lcScript=lcScript+ ' +" WAS PASSED " + oArg(0)' + chr(13)
lcScript=lcScript + 'WSCRIPT.ECHO "The argument len: " & LEN(oArg(0))'
STRTOFILE(lcScript,lcPath)

DECLARE INTEGER WinExec IN kernel32 ;
STRING lpCmdLine ,;
INTEGER uCmdShow

lcProg2Run = 'C:\windows\wscript.exe ' + lcPath + ;
' //E:VBScript ' + REPLICATE('W',500)
lnWindow = 1
? WinExec(lcProg2Run,lnWindow)
? 'Command line length: ' + TRANS(LEN(lcProg2Run))

But I am interested in whatever findings you do discover. Jon Hawkins

 

[ChrisRChamberlain]

Jon

Thanks for the interest and the code, which I will try.

As mentioned in the previous post, the application now uses a method whereby 30+ PDFs can be processed as a single batch, within the known character limit.

The long filename files are copied to the application's folder and in so doing are renamed as 1.pdf, 2.pdf etc.

This enables the application to accurately calculate how many files can be processed and this information is displayed on screen through a thermometer and a label caption.

After processing, the files in the application's folder are either automatically deleted or, if the user elects to save the data, copied to a new subfolder with their original long filenames, and become available as a "set" for further processing.

30+ PDFs, (the final count is determined by the number of command line switches used), may not sound a lot of files - in reality, this can be a vast amount of data depending on the number of pages in a single PDF.

The test data files used, for example, produce a 5 mb 700+ page PDF from 28 files.

The application allows a user to either build a PDF from scratch or append further PDFs to any existing file.

So if 30+ files is insufficient, you simly add more to the original PDF through another session.

Generating PDFs from whatever source is easy - maximising their usefulness to a user requires somewhat more effort!

Chris