I think you rpoblem is with the quotes. AFAIK shell expects the parameter enclosed in double quotes not single. ie:
set excl off
use ("C:\PROGRAM FILES\MICROSOFT VISUAL FOXPRO 7\SAMPLES\data\customer")
lcFullPathName = dbf()
lcCommand = "C:\VSO3\Utilities\VSORM\VSORM.EXE"
lcParameters = '"' + m.lcFullPathName + '"'
declare long ShellExecute in "shell32.dll" ;
long hwnd, string lpszOp, ;
string lpszFile, string lpszParams, ;
string lpszDir, long nShowCmd
ShellExecute(0,'Open',m.lcCommand,m.lcParameters,0,0)I don't think you need an extra array column to keep the type. Values are already saved preserving their types.
Cetin
>Hi Cetin
>
>>:) Hmm I would first prevent:
>>use &lcCursor
>>
>>and instead use:
>>use (m.lcCursor)
>>IOW trace why you get such a weird lcCursor value. You're still expnading the same variable and indirectly hitting & blues. Check what you really use with:
>>? dbf().
>
>I am sending the value returned by DBF() which is also confirmed when I put in wait window just before the use (m.var) command. So looking at the value stored in lcCursor, is what I want. One thing that comes to my mind is I am putting the return value of DBF() into single quotes when passing as parameter, fearing that spaces in the path may make the mini.exe think of it as 2 variables:
>
>reportform.execute() (see supporting UDFs below()
>
LOCAL lcFullPathName
>
>lcFullPathName = DBF(THISFORM.cRMCursorName)
>
>CloseUsed(THISFORM.cRMCursorName)
>
>_Run("C:\VSO3\Utilities\VSORM\VSORM.EXE '" + lcFullPathName + "'", ".", "HID", .T.)>
>
>>"which is your favourite if variable type was the utmost important for you, precision and all"
>>This is really a hard question.
>
>Gotcha <g>.
>
>>So this makes me think .mem saving is more generic.
>
>The more I studied your codes, I feel passing a mem file containing a 3 dim. array to work instead of the rows of the table I am currently sending. With it I can assign the type to the first elem., value to the second elem. and that too without converting to text etc., the third elem. can contain the optional parameter. So on for the next row of the array. And each and every row in the array can have a different type of value assigned to the second elem. (in this case) and there will not be any problems, I guess.
>
>>I didn't yet try saving such an object to a .mem file. If it works probably would be my choice for the job.
>
>Nice idea passing the object in the mem file. But in need for speed I will update my codes to work for a mem file first, then later I will give passing objects.
>
>Wow this is great. Please pass on any idea that you may have now or in the future for this thread, I would love to try them out.
>
>Thanks for all the help. Rest assured I will be back when I get stuck with the implementation <vbg>.
>
>
>ClosedUsed()
>
FUNCTION CloseUsed()
> *** Checks to see if the given alias is in use and closes it
>
> LPARAMETERS tcAlias
>
>
> IF USED(tcAlias)
> USE IN (tcAlias)
> ENDIF
>ENDFUNC
>
>_Run() is warpper for Late Ed Rauh's class
>
FUNCTION _RUN()
> *** Parameters
> *** tcCommandLine: Char: Full Command including parameters
> *** tcLaunchDir : Char: The directory where the application is to be launched
> *** tcWindowMode : Char: Can be
> *** "NOR" - Run Normal
> *** "MIN" - Run Minimized
> *** "MAX" - Run Maximized
> *** "HID" - Run Hidden
> *** tlExecBG : Logical: .T. if you want the application to run in the
> *** background and continue with VFP execution
> *** irrespective of the app status
> *** .F. default - wait for the application to
> *** terminate before continuing VFP execution
>
> LPARAMETERS tcCommandLine, tcLaunchDir, tcWindowMode, tlExecBG
>
>
> LOCAL luRetVal, loProcess
>
>
> loProcess = CREATEOBJECT("cAPI_AppRun", tcCommandLine, tcLaunchDir, tcWindowMode)
>
>
> IF tlExecBG
> loProcess.LaunchApp()
> ELSE
> loProcess.LaunchAppAndWait()
> ENDIF
>
>
> luRetVal = loProcess.CheckProcessExitCode()
>
>
> RELEASE loProcess
>
>
> RETURN luRetVal
>ENDFUNC
