Call To FindFirstFile - Strange

[Michael Meeks]

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

[Semen Matusovski]

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.

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

[Michael Meeks]

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

[Lance Edmonds]

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>

[Semen Matusovski]

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


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

[Michael Meeks]

Thanks Lance.....

I knew it had to be simple!

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

Once again,
Thanks

Mike



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

[Lance Edmonds]

"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:

GLOBAL CURPATH$

Does that answer your question?!


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

[Semen Matusovski]

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).]

[Lance Edmonds]

Exactly my point - reread my message.


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

[Lance Edmonds]

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,

#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>

[Semen Matusovski]

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).]

[Florent Heyworth]

Lance

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

Cheers

Florent

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