Sorry to be too simplistic, but, yes, there is a limit. We see it in generating long HTML strings all the time. We just break up the strings into shorter ones..
>I remember that from the DOS prompt there was a limitation on the lenght of string to use. It was rather short, around 128 or 256 characters. I doubt that limitation has been removed.
>
>Nevertheless, I have no idea if the limitation applies when going through the API.
>
>
>>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 ;
>> STRING lpCmdLine ,;
>> INTEGER uCmdShow
>>
>>* 0 = Hide
>>* 1 = Normal
>>* 3 = Maximized
>>* 6 = Minimized
>>
>>WITH THISFORM
>> DO CASE
>> CASE .opgShowWindow.Value = 1
>> lnWindow = 0
>> CASE .opgShowWindow.Value = 2
>> lnWindow = 6
>> CASE .opgShowWindow.Value = 3
>> lnWindow = 1
>> OTHE
>> lnWindow = 3
>> ENDC
>>ENDW
>>
>>lcProg2Run = ALLT(CMD_LINE.string)
>>
>>IF !WinExec(lcProg2Run,lnWindow) > 31
>> 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 the WinAPI call, and therefore is there a limit on the length of the string passed by VFP?
>>
>>Any ideas please?
>>
>>Chris