Announcement

Collapse
No announcement yet.

FIELD variables

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Andre Jacobs
    replied
    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"

    Leave a comment:


  • Bob Zale
    replied
    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.

    Leave a comment:


  • Michael Mattias
    replied
    >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.

    Leave a comment:


  • Andre Jacobs
    started a topic FIELD variables

    FIELD variables

    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:
    Code:
    ' 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:
    Code:
    #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: :confused2:
    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!!!
Working...
X