The LA Fox Developer Newsletter

April 1999

Inserting/Retrieving (Con't from page 3)

cBuffer = FREAD( nHandle,nSize)

&& Can we close it now (we should be able to do this) IF ( FCLOSE( nHandle))

&& Did we read the entire file?

IF ( LEN( cBuffer ) == nSize)

IRetVal = TRUE

ENDIF

ENDIF

ENDIF

ENDIF

RETURN ( IRetVaI)

FUNCTION FIl_len( nHandle)

LOCAL nFilePos

LOCAL nSize

&& Save the current file pointer location

nFilePos = FSEEK( nHandle,O,FILEPOS_CURRENT

&& Set the file pointer at the end of the file

nSize = FSEEK( nHandle,O,FILEPOS_END)

&& Reset the file pointer where It was

FSEEK( nHandle,nFilePos,FILEPOS_BEGIN)

RETURN ( nSize)

OK ... Let’s test these two new funCtions! First let’s put the in a procedure file, TESTFILE. PRG for example, and then let’s try the functions:

COMPILE TESTFIE SET PROCEDURE TO TESTFILE but =

? CopyFileToVar( GETFILEO,@buf)

Surprise ... It works just fine! So the only thing left to do now is to store the content of the buffer in a memo field.

The DBF Structure/The Resource File Structure

In languages such as C, or even in Visual Basic files that hold the definitions of cursors, bitmaps, dialog boxes, etc. are Called resource files. So why not calling our DBF a simple resource?

Unlike regular resource files ours get a major advantage ! We can create indexes on them. In fact, getting access to the proper information is so fast in Visual FoxPro that you wouldn’t get back to real resources anymore.

What you merely need in your DBF structure is a kind of keyword, and associated content. But that isn’t enough if you want to store linked content. What’s linked content? Well, that might be a file that needs another file. For example, you might want to store a DBF in a DBF (why not? A DBF is a file like any other file) but the DBF you need to include might have memo fields which basically means that the .DBF file is tightly related to an .FPT file. Other example: maybe you want to store bitmaps in your resource file. However, a .BMP file might also be linked to a .MSK file (a mask). Many other examples of a file that can be linked to another file can be found. In my implemen

tation I am definitely not going to trap all circumstances where a file is linked to a file, linked to a file, linked ... I just provide a mechanism where 1 (and only 1) file can be linked to a primary file.

So let’s summarize all this a little bit: we need a DBF whose structure will feature a keyword, a content, and possibly a linked content. What’s more, it might be a very good idea to also include a kind of category; is this resource a bitmap, a table, a cursor (.CUR), a wave file, etc. So we’ll end up with a four fields structure:

Storing A Bitmap In The Resource File

FUNCTION SaveBitmap( cResourceFile,cResource,cKeyword

LOCAL IRetVal && Logical return of the function

LOCAL cBuffer && Internal buffer

LOCAL lReading && Successful reading?

lRetVal = FALSE && Function is not successful by default cBuffer = “ && Empty buffer right now IReading = FALSE && We didn’t read the file successfully

the resource file exists

IF ( FILE( cResourceFib))

&& If the bitmap we want to store exists

IF ( FILE( cResource))

&& If we successfully read the bitmap file

IReading = CopyFileToVar( cResource,@cBuffer) IF ( IReading)

&& Insert the content. in the DBF!

INSERT INTO ( cResourceFile)

VALUES ( UPPER( cKeyword),;

“BMP”

IRetVal = TRUE

USE

ENDIF

ENDIF

ENDIF

RETURN ( lRetVal)

Although not perfect, this code is a very good starting point. We indeed need to fix several particularities such as the following one: what if an .MSK exists ? We might also create one generic function that all particular functions will use: SaveFileO. Let’s go ahead

Generic SaveFile() Function

FUNCTION SaveFile( cResourceFile,cResource,cKeyword,cType

LOCAL IReading && Successful reading?

IRetVal = FALSE && Function is not successful by default

(Con’t, page 5)

Page 4