I am trying to use some Win32 API functions in a Visual Basic 6.0 and
I am getting some errors. What I am trying to do is to get the version
information from an executable, dll or custom control file. I am using
the functions GetFileVersionInfSize, GetFileVersionInfo and
VerQueryValue, which are located in version.dll file. I have no
problems with the first two functions, but when the program reaches
the line where I invoke the VerQueryValue function I get the following
error message:

"Can't find DLL entry point VerQueryValue in version.dll"

In my opinion this message means that the function VerQueryValue
cannot be found in the version.dll, but I don't why.
I am reading Dan Appleman's Visual Basic 5.0 Programmers Guide to the
WIN32 API, but I don't have the book. Instead I have some of the files
from the book's CD-ROM, which a friend of mine gave me. In these files
the most important file is a huge win help file with the name of
vbpg32.hlp, which contains the whole book in electronic format.
Unfortunately I don't have the sample files and projects from the book
and I use examples, which are given in the text in this win help file.
The above problem I got when I tried to do the FileDemo Example
project from Chapter 13 - FileDemo-Initialization File, Registry, and
Version Stamping Program.
I am using a computer with Windows 98 (not Second Edition) at my job.
I tried the same FileDemo project also at my home machine, which is
running Windows XP, but I am getting the same error message.
Can somebody help me to solve the problem? Also, does anybody know
where I can find information for currently actual Win32 API functions?
I tried Microsoft's MSDN web site, but I couldn't find anything
concerning Win32 API. Instead I found a lot of information concerning
Microsoft's .Net new technology. Dan Appleman's book, which I have in
electronic format is a little bit old, it discusses Visual Basic
versions 4.0 and 5.0. And I live in Bulgaria where is very difficult
to find original computer books.
Thank you for your help.

Public Declare Function VerQueryValue Lib "version.dll" Alias
"VerQueryValueA" (pBlock As Any, ByVal lpSubBlock As String, ByVal
lplpBuffer As Long, puLen As Long) As Long

HTH
greetz

Thank you very much for your help for using Win32 API VerQueryValue
function. You are right I had to add the:

 Alias "VerQueryValueA"  

to the declaration of the function. Actually I did it before posting
my message to the news group but I forgot to mention that  it crashed
the Visual Basic. After adding the "Alias ..." part to the declaration
of the function and seeing that my program crashes on the row where I
invoke VerQueryValue function, I decided to trace the program and to
read the description of VerQueryValue function in Dan Appleman's
e-book that I have. I noticed that Visual Basic's API Viewer
absolutely deceives the programmer. If you insert the declaration of
the VerQueryValue function that API Viewer suggests your program will
crash. Firstly, because the API viewer uses the "Alias ..." part
incorrectly and secondly, because it mistakenly declares the
lplpBuffer parameter as "ByVal". The declaration of VerQueryValue
function that API viewer offers is:

Public Declare Function VerQueryValue Lib "version.dll" Alias
"VerQueryValue" (pBlock As Any,  ByVal lpSubBlock As String, ByVal
lplpBuffer As Long, puLen As Long) As Long

It is absolutely incorrect! The correct declaration is:

Public Declare Function VerQueryValue Lib "version.dll" Alias
"VerQueryValueA" _
    (pBlock As Any, ByVal lpSubBlock As String, lplpBuffer As Long, _
    puLen As Long) As Long

The lplpBuffer variable is: "The address of the long variable to load
with the address of a buffer to load with the requested version
information." as Dan Appleman writes in his book, so lplpBuffer can
not be declared using "ByVal" keyword.

After correcting the declaration of VerQueryValue function my program
started running correctly. I even corrected another VB project, which
also used the above-mentioned API function and it also started running
OK.

Despite this slight success of using some Win32 API functions in my
Visual Basic projects I still have problems with declaration of some
function parameters with "ByVal" keyword and I even saw that some API
functions use "ByVal" keyword when they are invoked. I still cannot
understand a statement like the following, for example:

agCopyData ByVal fiiaddr&, ByVal tbuf$, fiilen&

This invokes the agCopyData function, which is part of APIGID32.DLL
file, but it uses "ByVal" keyword in the call to the function instead
in its declaration.

Anyway I am going on dealing with Win32 API functions. I hope I'll get
more understanding when I reading and working more with them.
Once again thank you very much!

<snip>

If you want to save yourself a lot of grief when using APIs, then
download the API Guide and replacement API viewer from :

http;//www.allapi.com
http://www.crackinguniversity2000.it/vb_api/ref/v/verqueryvalue.html

are great!!!
I found them very helpful for me!
Meanwhile, I'm continuing to deal with API and VB, I found more errors
in Microsoft's API Viewer and its database. The declaration of the API
function PtInRect is wrong:

Public Declare Function PtInRect Lib "user32" Alias "PtInRect" (lpRect
As RECT, pt As POINTAPI) As Long

The correct declaration is:

Public Declare Function PtInRect Lib "user32" (lpRect As RECT, ByVal
ptx As Long, ByVal pty As Long) As Long

Too many errors from Microsoft! I wasted a lot of time correcting
them. What are they doing? Why didn't they correct their declarations?
But with the help of the above web sites I hope I'll manage to go
ahead in VB and Win32 API world.
Thank you once again!!!

Public Declare Function PtInRect Lib "user32" Alias "PtInRect" (lpRect
         As RECT, ByVal pt As POINTAPI) As Long

They missed out the ByVal

I think you can not refer to a User Defined Types (UDT) ByVal. Did you
test the PtInRect with ByVal and POINTAPI structure? I tested it with
two long parameters - x and y coordinates of the point ant it works.

Greets,

<snip>

Normally I rely on
  www.AllAPI.net
for their alternative to MS's 'API thing'