zXref (version 1.10)

[Paul Elliott]

I see at least part of the problem of files included multiple times.

gsIncludes() only has the main file name ( sometime multiple entries ).
gsFiles() has the whole path & file name.

The DoGetIncFiles is only searching for the INC file name ( no path ) in gsIncludes().

There may be other places that it gets searched but this routine seems the right place to weed
out duplicates.

[Paul Elliott]

something along the lines of

Code Select Expand


'                // Patrice resolve missing include path
                 IF zExist(sWork) = 0 THEN sWork = zFindFile(sWork)
                 IF zExist(sWork) THEN                       'safety check - if we can find what we got..
         ' I added the following
                    ARRAY SCAN tmpFiles(), COLLATE UCASE, = sWork, TO xx
                    IF xx = 0 THEN
                       ARRAY SCAN gsFiles(), COLLATE UCASE, = sWork, TO xx
                       IF xx = 0 THEN
         '  checks to see if file already in tables               
                          tmpFiles(fc) = sWork                               'store path + name in temporary array
                          fc += 1: REDIM PRESERVE tmpFiles(fc)     'incr counter and redim temporary array
         ' and the 2 End Ifs
                       END IF
                    END IF
                 END IF   


should work. Had to add another variable  ( Local xx as Long ) to keep from changing something
I shouldn't.

This checks to see if the file is already in the tmpFiles() or in gsFiles() in DoGetIncFiles().

Patrice will probably have a better method.

[Larry Charlton]

That worked really well.  Scan time dropped from 95 seconds to 29 seconds.

Turns out there's another option also, in zXRef.cfg all the exclude files are commented out.  I updated it to point to the PBWin10 includes and built an updated list of all the include files and dropped them in uncommented.  Skips right over them and reduces scan time to 1.7 seconds. 

[Paul Elliott]

Larry,

It also works if you point it to .\ so that it only looks at the current directory. Then you can work on
programs dealing with either PB's or Jose's INC files and different versions of them without any
change to the cfg file.
Another choice would be to point it to the directory where you have your INC files ( in case they are
not specified on the #Include lines ).

[Paul Elliott]

Patrice,

Have not heard your opinion yet.

I was confused about which array had what file name at first. Then I ran a few files and dumped
out what was in them. I think I got it right.

Is what I wrote in reply #101 correct? Or did I miss something? 

[Theo Gottwald]

Can anyone explain to me why an INC file should be included multiple times?

Paul, the WinAPI not, I guess.

BUT, an Included file is technically same like MACRO.
You see that, if you intermix MACROS and Include files, they even share the same "NESTING DEPT".

The reason for including a file twice is the same, why you should use a MACRO twice.
Include files are not solely for using WinAPI, or reading definitions,
but you can also use them to include your personal code-stuff "as often as you want" without always typing it again.

[Paul Elliott]

Theo,

Ok, thanks for pointing that out.

I was just trying to figure out how to handle the #Include Once & #Include This Once. For the latter,
I'm just going to leave in the code already read up to that point ( it gets messy having to undo
anything already input if that is not the first real line of code ).

I was just running all the PB or Jose WinAPI files into 1 main file to get a big list of equates and
check out if I was handling #IF...#ENDIF blocks correctly. And to check how to store equate values
for comparison or use in building other equates.

I guess it's time to track down my problem with multiple copies of the same file open at once.
Something to do this weekend.

[Larry Charlton]

...BUT, an Included file is technically same like MACRO.
You see that, if you intermix MACROS and Include files, they even share the same "NESTING DEPT".

The reason for including a file twice is the same, why you should use a MACRO twice.
Include files are not solely for using WinAPI, or reading definitions,
but you can also use them to include your personal code-stuff "as often as you want" without always typing it again.

Theo,

Thanks for that!  I read that and it percolated in the back of my mind for a bit.  Puts a whole new light on #include   I'm not sure I'll use it, but it occurs to me it could be used to include common methods (or interfaces) in several classes.  Going further with a bit of naming convention it could be used as a sort of templating.  Here's a simple example

Name_Create.inc

Code Select Expand

  vName = "Theo!"

Name_Definition.inc

Code Select Expand

    Property Get Name() As String
      Property = vName
    End Property
    Property Set Name( value As String )
      vName = value
    End Property

Name_Instance.inc

Code Select Expand

  Instance vName As String

Test.bas

Code Select Expand

#Compile Exe
#Dim All

Function PBMain () As Long
  Local v1 As i1
  Local v2 As i2

  v1 = Class "C1"
  ? v1.Name + ", " + v1.Phone

  v2 = Class "C2"
  ? v2.Name + ", " + Format$( v2.Age, "0" )
End Function


Class C1
  #Include "Name_Instance.inc"
  Instance vPhone As String

  Class Method Create()
    vPhone = "704-555-1212"
    #Include "Name_Create.inc"
  End Method

  Interface i1
    Inherit IUnknown

    #Include "Name_Definition.inc"
    Property Get Phone() As String
      Property = vPhone
    End Property
    Property Set Phone( value As String )
      vPhone = value
    End Property
  End Interface
End Class


Class C2
  #Include "Name_Instance.inc"
  Instance vAge As Long

  Class Method Create()
    vAge = 140
    #Include "Name_Create.inc"
  End Method

  Interface i2
    Inherit IUnknown

    #Include "Name_Definition.inc"
    Property Get Age() As Long
      Property = vAge
    End Property
    Property Set Age( value As Long )
      vAge = value
    End Property
  End Interface
End Class