simple call to GetWindowsDirectoryA isnt working?

[Wayne Diamond]

I cant see why this isnt working? ive pulled it from one of my VB apps (that could be why) where it was working
Result& returns 8, but the WindowsDirectory string buffer isnt "C:\WINNT" - its blank
can anyone please tell me what im doing wrong? Thankyou!

#COMPILE EXE
DECLARE FUNCTION GetWindowsDirectory LIB "Kernel32.DLL" ALIAS "GetWindowsDirectoryA" (BYVAL lpBuffer AS STRING, BYVAL nSize AS LONG) AS LONG

FUNCTION PBMAIN() AS LONG
ON ERROR RESUME NEXT
iH& = SHELL(COMMAND$, 1)
LOCAL WindowsDirectory AS STRING * 144
WindowsDirectory = SPACE$(144)
Result& = GetWindowsDirectory(BYVAL WindowsDirectory, 144)
MSGBOX LEFT$(WindowsDirectory,Result&),, "Result& = " & STR$(Result&)
END FUNCTION

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

[Kev Peel]

Wayne, try this:

#COMPILE EXE
#INCLUDE "WIN32API.INC

FUNCTION PBMAIN() AS LONG
ON ERROR RESUME NEXT
iH& = SHELL(COMMAND$, 1)
LOCAL WindowsDirectory AS [b]ASCIIZ * 260[/b]
Result& = GetWindowsDirectory(WindowsDirectory, 260)
MSGBOX WindowsDirectory,, "Result& = " & STR$(Result&)
END FUNCTION

The Visual Basic declare you had down for GetWindowsDirectory is invalid in PowerBASIC.

Regards,


------------------
Kev G Peel
KGP Software, Bridgwater, UK.
www.go.to/kgpsoftware

[Wayne Diamond]

Kev, many thanks for that - I can resume programming now

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

[Lance Edmonds]

To add to Kevin's comments... when VB passes a dynamic string to a DLL, VB internally converts the string from UNICODE into ANSI and adds a NUL byte to the string. Then, it passes the address of the actual string buffer to the target DLL Sub/Function.

This is equivalent to passing an ASCIIZ string in PowerBASIC.

Kevin's post implies one more helpful thing: when converting VB code to PowerBASIC, don't bother using the VB declarations... dump them and use #INCLUDE "WIN32API.INC" instead... it contains declarations that are known to work correctly with PowerBASIC.

However, Kevin's code contains one thing that can be improved... instead of hardcoding the 260 byte string buffer, it should use the %MAX_PATH equate. This will help keep code bug-free if/when Microsoft change the specification for the maximum path length in future versions of Windows.
ie:
DIM WindowsDirectory AS ASCIIZ * %MAX_PATH + 1 ' add one to allow for the terminating NUL byte.

For more info on VB, consult VB appendix in the help file. While it deals with passing parameters to PB, it indirectly shows how VB code can be converted to PowerBASIC.



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

[Lance Edmonds]

One more note: this BBS contains about 30,000 messages with a lot of free code. If you have problems with an API function, then a search of the BBS stands a high chance of finding some example code using that API.

For example, Dave Navarro posted a function in October 1998 for the GetWindowsDirectory() API (although it contains an error with the buffer size allocation as discussed above). http://www.powerbasic.com/support/fo...-7-000076.html

There are at least 4 other posts in this BBS that refer to this API function.

I hope this helps.

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

[Semen Matusovski]

Lance --
> DIM WindowsDirectory AS ASCIIZ * %MAX_PATH + 1 ' add one to allow for the terminating NUL byte.
This +1 confuses me.
I made experiments under Win2000 Pro.
WindowsDirectory = G:\WinNt (8 letters)

If to call with usize = 8 (unlike >= 9), GetWindowsDirectory returns error.
This means that OS assumes that usize includes NUL.
Because MSDN recommends usize = %MAX_PATH, I guess that this value includes NUL.

Which OS do you mean when you talk about +1 ?

------------------
E-MAIL: [email protected]

[Lance Edmonds]

Technically you are quite correct, the extra byte is irrelevent for this particular O/S imposed limit. The 1998 example in the source code forum contains a subtle bug because the buffer is slightly smaller than the largest possible path string the API can return. Which approach of the two is safer... an oversize buffer, or an undersize buffer ?

However, the SDK/MSDN documentation is often lacking in specifics in these sorts of details. In this particular case, adding one byte to our buffer causes no problems for the API, and therefore we err on the side of caution to ensure that the buffer will be large enough for the largest path string.

Ideally, all "string" buffers should have a length that is a multiple of 4 bytes in memory (for efficiency, data alignment, etc). However, there is no "guarantee" that buffer limits of every single API function respect this "rule".



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