Announcement

Collapse
No announcement yet.

Call To FindFirstFile - Strange

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

  • Call To FindFirstFile - Strange


    Okay, here's a strange one for me!
    (all lines adjusted to be readable)

    File: test.inc

    Has just 1 function

    DECLARE FUNCTION FindFirstFile LIB "kernel32.dll" _
    ALIAS "FindFirstFileA" (lpFileName AS ASCIIZ, _
    lpFindFileData AS WIN32_FIND_DATA) AS LONG

    (WIN32_FIND_DATA types are declared properly)


    File: test.bas

    curpath$ = "c:\"

    ' this works fine!
    hFile& = FindFirstFile(curpath$ & "*.*", gfRecs)

    ' However, make a small change!

    curpath$ = "c:\*.*"

    ' this produces an error in PB6
    hFile& = FindFirstFile(curpath$, gfRecs)

    Can someone explain why ?

    Thanks
    MWM


    -------------
    mwm
    mwm

  • #2
    Michael --
    try, for example

    Dim hFile As Long, gfRecs As WIN32_FIND_DATA, curpath As Asciiz * %MAX_PATH
    curpath$ = "c:\*.*"
    hFile& = FindFirstFile(curpath$, gfRecs)
    MsgBox gfRecs.cFileName
    FindClose hFile&

    It seems to me that you have problems with curpath$ length' declaration.

    ------------------

    Comment


    • #3

      Semen, I tried makeing curpath As Asciiz * %MAX_PATH,
      but got a PB-Byval error.

      Just seem weird that curpath$ & "*.*" will work, but
      Not curpath$

      Thanks




      ------------------
      mwm
      mwm

      Comment


      • #4
        Semen's example does not solve your problem - although he created an ASCIIZ string, he still continued to use a Dynamic String to call the API.

        Getting back to your original problem, the compiler throws an Error 480 "Parameter mismatch, may need BYCOPY", right? The problem is simple - the API is declared to receive an ASCIIZ string BYREF (ie, a pointer to an ASCIIZ string buffer's data), so you'd need to pass a dynamic string BYCOPY or use BYVAL STRPTR(CURPATH$) - either case creates a pointer to the string data.

        It "worked" when you changed the parameter to CURPATH$ + "*.*" because it created an expression - the compiler has to resolve CURPATH$ + "*.*" and store that result somewhere, then pass a pointer to the result. This is exactly the same as passing the string BYCOPY.

        Read all about the differences between BYVAL, BYREF and BYCOPY in the help file under the CALL keyword.


        ------------------
        Lance
        PowerBASIC Support
        mailto:[email protected][email protected]</A>
        Lance
        mailto:[email protected]

        Comment


        • #5
          Lance --
          Are you seriously ?
          Pb dll 6.0, Win2000, Msgbox returns "IO.SYS"


          #Compile Exe
          #Register None
          #Dim All
          #Include "win32api.inc"
          Function PbMain
          Dim hFile As Long, gfRecs As WIN32_FIND_DATA, curpath As Asciiz * %MAX_PATH
          curpath$ = "c:\*.*"
          hFile& = FindFirstFile(curpath$, gfRecs)
          MsgBox gfRecs.cFileName
          FindClose hFile&
          End Function


          ------------------

          Comment


          • #6

            Thanks Lance.....

            I knew it had to be simple!

            Pointers! <----Looks whose pointing at me!

            Once again,
            Thanks

            Mike



            ------------------
            mwm
            mwm

            Comment


            • #7
              "Are you seriously ?"

              Am I serious? Yes. Your original 'snippet' is misleading because of the $ type-specifier, and especially as Michael was having a problem trying to pass a dynamic string to a function expecting an ASCIIZ.

              While your code works, you are actually exploiting the fact that CURPATH and CURPATH$ should not be regarded as the same variable but are treated as one and the same by the compiler - one is ASCIIZ and the other is supposed to be a dynamic string. The compiler is accepting your use of the $ type specifier but ideally should not. I'll ask R&D to see if this can be tightened up in the future. The same applies to fixed-length strings.

              My advice is to _never_ append a type specifier to an ASCIIZ or fixed-length string as it can lead to subtle errors and visual errors - $ should only ever be used with dynamic strings. If someone else every needs to use your code they may make assumptions about the variable based on the type-specifier.

              For example, add the following line to your code before PBMAIN and see how readable and predictable the code becomes:
              Code:
              GLOBAL CURPATH$
              Does that answer your question?!


              ------------------
              Lance
              PowerBASIC Support
              mailto:[email protected][email protected]</A>
              Lance
              mailto:[email protected]

              Comment


              • #8
                Lance --
                I agree with your next message.
                Problem that Asciiz strings have no indicator sign, similar other types.

                [This message has been edited by Semen Matusovski (edited March 27, 2000).]

                Comment


                • #9
                  Exactly my point - reread my message.


                  ------------------
                  Lance
                  PowerBASIC Support
                  mailto:[email protected][email protected]</A>
                  Lance
                  mailto:lan[email protected]

                  Comment


                  • #10
                    Semen (and everybody else), would it create any problems for you if the compiler was changed to reject type-specifiers on ASCIIZ and Fixed-Length strings, as per your code above?

                    ie,
                    Code:
                    #COMPILE EXE
                    GLOBAL z$
                    FUNCTION PBMAIN
                      DIM z AS ASCIIZ * 128
                      Z$ = "128 byte buffer"
                      MSGBOX Z$ & $CRLF & Z
                    END FUNCTION
                    By omitting the type-specifiers the compiler could be more likely to catch subtle variable-scope errors, but before I make the request to R&D I need to get a feel for how much this could affect existing code...

                    Comments anyone?

                    TIA!


                    ------------------
                    Lance
                    PowerBASIC Support
                    mailto:[email protected][email protected]</A>
                    Lance
                    mailto:[email protected]

                    Comment


                    • #11
                      Lance --
                      as you know, there are two popular Basic's lines.
                      First - Microsoft.
                      Here you can't have different variables with the same name, such as n%, n#, n(x).
                      Second - Turbo Basic ... PB.
                      Here this is possible.

                      I always used DefInt A-Z and for all types, others than integer, used indicator sign (#, !, $).
                      Which indicator I can use for Asciiz and fixed-length strings ?
                      Nothing ? But for me nothing always meant integer.
                      So, I don't want to use $, but I haven't a choice.

                      Best solution - to add special indicators in future releases.

                      Also I think in future it's better to accept MS' rules (not allowed different variables with the same name).
                      To avoid troubles with existing programs, new IDE should store special line - "Version x.xx" (similar VB).
                      During loading files in old format, IDE, if meat n% and n#, should require to rename one of variables.

                      [This message has been edited by Semen Matusovski (edited March 28, 2000).]

                      Comment


                      • #12
                        Lance

                        it'd be okay with me - hope others speak up - I could imagine such a change breaking some people's code.

                        Cheers

                        Florent

                        ------------------

                        Comment

                        Working...
                        X