FIELD variables

[Andre Jacobs]

Hello,

I am busy porting an old DOS application to PB/WIN and have come a bit unstuck with the FIELD variables:

Old DOS Version:

' no #DIM ALL is set
  
    Open ClientDbDir$ + "SUPPLIER.IDX" Lock Shared As #31 Len = 64

    Field #31, 48 As SBSSName$,     _
               10 As SBSSSupplier$, _
                4 As SBSSSpare$,    _
                2 As SBSSMaster$

    Field #31, 64 As SBSSIdx$

    If Lof(31) = 0 Then
       LSet SBSSIdx$ = DatabaseEOF$
       Put #31
    End If

New PB/WIN version:

#DIM ALL
Global X&
Global DatabaseEOF$
Global SBSSName as Field
Global SBSSSupplier as Field
Global SBSSSpare as Field
Global SBSSMaster as Field
Global SBSSIdx as Field
.
.
.
.
.
.


  X& = FreeFile
    Open ClientDbDir$ + "SUPPLIER.IDX" Lock Shared As #X& Len = 64

    Field #X&, 48 As SBSSName,     _
               10 As SBSSSupplier, _
                4 As SBSSSpare,    _
                2 As SBSSMaster

    Field #X&, 64 As SBSSIdx

    If Lof(X&) = 0 Then
       LSet SBSSIdx$ = DatabaseEOF$
       Put #X&
    End If

The PB/WIN compiles clean, but this is what is confusing to me:
Focus only on: LSet SBSSIdx$ = DatabaseEOF$

SBSSIdx$ is not defined, but compiles clean. (Would/should bring compile error)
Does this mean that if I do not use the field in an assign statement, it can be referred to as an ordinary string?
IOW: Is the use of variables SBSSIdx$ and SBSSIdx interchangeable?

I am hoping against my better judgment that it can be done this way, as there are LOTS of code referencing the database fields as strings throughout the code.
It is a foregone conclusion that I will miss a LOT of them when/if manually changing them to field variables, and if the compiler does not assist, then I'll be doomed.

To give you the scope of the "upgrade", there are 57 modules each running in it's own 64k segment that are executed with a run "module.pbc" statement and they end with a run "mainmodule.exe". They are all now combined into one run module. ( Using #Includes of course)
There are over 500 database "fields" used as strings, to change them all in the code would be ENORMOUS!!!

[Michael Mattias]

>SBSSIdx$ is not defined, but compiles clean. (Would/should bring compile error)

>Global SBSSIdx as Field

??

I know other than with FIELD datatypes, when any variable is defined 'AS something' using either GLOBAL/LOCAL/STATIC scope or DIM statement, the type specifier for the same type is redundant and ignored. (Although I know at one time (and maybe still) you could have dog&, dog$, [email protected]@ and dog# as separate variables). (Not recommended by MCM).

I guess the FIELD datatype must be part of the "string" family.

[Bob Zale]

A FIELD variable is a STRING variable with a little extra overhead to provide some additional functionality. The "Handle/Pointer" to dynamic string space occupies 16 bytes instead of 4 bytes, but in virtually all other respects, they can be substituted.

Once a FIELD is declared, you can reference it with or without a $ id suffix.

Bob Zale
PowerBASIC Inc.

[Andre Jacobs]

Thanks Bob,

Now I know that throughout the application I can leave the references "as is"
This will save me a lot of "finger trouble"