XSharpPublic icon indicating copy to clipboard operation
XSharpPublic copied to clipboard

Support FoxPro types in .MEM files

Open RobertvanderHulst opened this issue 4 years ago • 3 comments

Support FoxPro types in .MEM files

RobertvanderHulst avatar Dec 06 '21 13:12 RobertvanderHulst

Robert,

Using the Fox dialect i tried to compile the MemVarSave.prg, but the line

nWritten := FWrite3(hFile, @nByte , 1)

https://github.com/X-Sharp/XSharpPublic/blob/5c70a30f19919e64ee834b2f3f2a34c0be6cb8dd/Runtime/XSharp.RT/Functions/MemVarSave.prg#L150

causes the compile error XS1615: Argument 2 may not be passed with the 'ref' keyword. I ve tried different compiler settings without success, but after this modification the code compiles and runs.

nWritten := FWrite3(hFile, (IntPtr) @nByte , 1)

Karl-Heinz

// #DEFINE USE_FOX_FIX   

FUNCTION Start( ) AS VOID 
LOCAL o AS MyMemWriter

	o := MyMemWriter { "D:\Test\FoxByteRef.txt" }
	o:WriteByte ( 97 ) 
	o:Close() 
	
	RETURN 	


 

CLASS MyMemWriter                  
    PRIVATE hFile       AS IntPtr   
    PRIVATE cFileName   AS STRING
    
    CONSTRUCTOR (cFile AS STRING)
        cFileName := cFile
        hFile := FCreate(cFile)
        IF hFile == F_ERROR
            SELF:_Error()
        ENDIF
        RETURN  
        
        
    DESTRUCTOR
        SELF:Close()
        
    METHOD Close() AS VOID
        IF hFile != F_ERROR  
            SELF:WriteByte(ASC_EOF) 
            FClose(hFile)  
            hFile := F_ERROR
            UnRegisterAxit(SELF)
        ENDIF
        RETURN

    METHOD _Error() AS VOID
        LOCAL oErr AS Error
        oErr := Error{FException()}
        oErr:Gencode := EG_READ
        oErr:SubCode := XSharp.VOErrors.E_OPEN_MSAVE
        oErr:FuncSym := "_MSAVE"
        oErr:FileName := cFileName
        oErr:OSCode   := FError()
        THROW oErr

   
 
    METHOD WriteByte(nByte AS BYTE) AS VOID PASCAL
    LOCAL nWritten AS DWORD  
    
    // ----------- 
    
    ? "Choosen dialect is:" , RuntimeState:Dialect:Tostring() 
     
  
#IFDEF USE_FOX_FIX 

	? "Using fox fix" 
		
	nWritten := FWrite3(hFile, (IntPtr) @nByte , 1)  // <---- this works
			
	
#ELSE 
	
	? "Using default call" 
		
	// Using the Fox dialect the FWrite3() causes the compile error XS1615: 
	// Argument 2 may not be passed with the 'ref' keyword	
	
	nWritten := FWrite3(hFile, @nByte , 1)       
    
#ENDIF    
 
	IF nWritten != 1      
		SELF:_Error()
	ENDIF
	
	RETURN 
        
END CLASS     

Karl1155 avatar Dec 13 '21 12:12 Karl1155

Karl-Heinz, That module was written to be compiled in Vo/Vulcan dialect. In these dialects the @ operator has 2 meanings:

  1. Take the address of a variable
  2. Pass a variable by reference.

In the other XBase dialects the concept of "the address of a variable" does not exist and then @ is always used to pass a variable by reference. In this case we were using @nByte to pass the address of the byte.

A cleaner solution (that I will implement in a future update) would be to write this as

LOCAL pByte as BYTE PTR
pByte := @nByte
nWritten := FWrite3(hFile, pByte , 1)

The line that assignes pByte is not ambiguous.

RobertvanderHulst avatar Dec 13 '21 17:12 RobertvanderHulst

Good morning, I welcome Karl's initiative to contribute to the cause of guiding the course of the project towards VFP needs. I tell you that on my own I did some research of the binaries and reached some conclusions: FoxPro incorporates to each variable saved in mem files 3 new "dimensions"

  1. Variable name of more than 10 characters

  2. Length of the content of the extended variable

  3. More data types supported "A" Array old dbase III plus format where in offset 33 it is array dimensions x + y (2 bytes + 2 bytes) An array with a short name is not the same as an array with a long name and when I say long it could be for example 300 characters. An array with a name length <=10 has type A, an array with name length >10 has type "a"

    The needs raised above generate new TYPE (Offset 12) and particular attributes change to "c" 0x63 characters large format name "h" 0x68 characters large format name big char data length "a" Array large name format "n" Numeric value large var name To be continued...

I would prefer not to overlap with other volunteers. Karl, for my needs it is enough to support the old Array format, if you took this challenge I can choose to take another without any inconvenience.

Best regards Juan

jpmoschi avatar Dec 15 '21 18:12 jpmoschi