How does one find constants

[toma2]

I have been studying a coding example in a magazine and believe I understand all that the code does. However, I can't figure out how the coder got the value for a constant. I copied the following code example from this forum because it was shorter than what I was looking at and had an identical purpose (though different method). My specific question is: How does one know that it is necessary to set the EM_SETPASSWORDCHAR constant to &HCC in order to specify the edit control on an InputBox? I'd really appreciate it if someone could give me a "generic" answer so I'd know how to get such values for any control.

CODE EXAMPLE

Private Declare Function SendMessage Lib "user32" Alias _
"SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, _
ByVal wParam As Long, lParam As Any) As Long

' Constants for API set A
Const EM_SETPASSWORDCHAR = &HCC
Public Const NV_INPUTBOX As Long = &H5000&

Public Function TimerProc(ByVal lHwnd&, ByVal uMsg&, _
ByVal lIDEvent&, ByVal lDWTime&) As Long

' This function allows for a mask character on an inputbox


Dim lEditHwnd As Long

' Find a handle to the InputBox window, then to the textbox
' the user types in (Known as "Edit")
'
' **This part is VERY important, here is how the FindWindowEx call should look:
' **Only change the parameters that are enclosed in [ ] in the following example
'
' [variable] = FindWindowEx(FindWindow("#32770", "[caption of your InputBox]"), 0, "Edit", "")
'
lEditHwnd = FindWindowEx(FindWindow("#32770", "Security Dialogue"), 0, "Edit", "")

' Send the mask character to the target InputBox when the user types
' The mask character in this sample is the Asc("*") - the "*" can be changed
' to whatever you like.
Call SendMessage(lEditHwnd, EM_SETPASSWORDCHAR, Asc("*"), 0)

 

[CassandraR]

Hi toma2:

If one knows the name of the API constant, then one can look up the constant in WIN32API.TXT which is installed with Visual Basic. Also, one can use the API Viewer application that comes with VB.

Cassie

 

[dilettante]

These API functions are not really meant to be used from a VB program. That said, most of them can be and many even have "Declare Function" headers provided with later versions of VB in a large .bas module.

As far as these constants used with the APIs goes, most of them are really to be found in C/C++ "header" files provided by Microsoft. They also occur in various articles on different API functions that are posted on MSDN and elsewhere.

Basically, you have to dig them out of other sources.

Here is one source of fairly comprehensive information: Win32 Headers & Libraries.

Read this information and then follow the link "Windows 2000 Headers and Libraries" to proceed. This process will provide you with the Windows 2000 Core SDK, something you ought to have anyway. This and the rest of the Platform SDK contain a wealth of useful information for any Windows programmer.

I'm often amazed how many people forego this amazing resource, mostly because they don't seem to know it exists!

 

[vb5prgrmr]

dilettante...

>These API functions are not really meant to be used from a VB program.

Oh how contraire my good person ... What does API stand for? ...

Whereas you do point out a good resource let me point you to one better for the win API

http://msdn.microsoft.com/library/d...winprog/windows_api_start_page.asp?frame=true

or perhaps this one...

http://msdn.microsoft.com/library/d.../winprog/windows_api_reference.asp?frame=true

Or another one would be the good old F1. Yes thats right most of the API (execpt from newer OS's) can be found in the vb help files.

and as Cassie2002 points out you can get the definitions, constants, and types from the API viewer.

Good Luck toma2

 

[strongm]

>These API functions are not really meant to be used from a VB program

Slightly inaccurate....

 

[dilettante]

Well, I guess you have me there. That comment was probably a little strong.

But my intent was more to say that the Windows APIs are not typically optimized for use by VB programmers. Instead VB was altered over the years to include useful things like VarPtr, StrPtr, ObjPtr to make it easier to call the APIs. Also, many little tricks were quickly developed to help match VB data structures to API structures.

An example of the latter would be the technique of filling up a VB string with junk to pad it to a fixed size to pass it to an API function. A similar example is taking back the result from an API call and looking for the vbNull value put at the end of the data in the padded-out string, and trimming back the string using Left( ).

These sorts of things (and many more) show that the APIs were not built to be VB-friendly.


Of course it doesn't mean you can't do it, and it certainly doesn't mean there is a thing "wrong" with doing it. Most significant VB programs outside simple forms-and-database applications probably wouldn't succeed without making API calls.

They just tend to be somewhat less friendly than ActiveX objects to a VB programmer.

 

[dilettante]

I agree vb5prgrmr, the MSDN Online edition of the Platform SDK is as useful as having a local copy... as long as you are connected to the Internet and at a reasonable speed.

Even more useful than a local copy if you are using somebody else's machine. ;-)

And the API Viewer can save a lot of time too of course when all you need is the value of a constant. The SDK gives you a lot more information though, and is especially helpful when you need to figure out just how to go about doing something. But for just looking up a constant value it certainly is overkill.

 

[strongm]

Probably worth pointing out that VarPtr predates even QuickBasic, let alone Visual Basic.

 

[dilettante]

Ever the erudite Basic historian. ;-)

Gosh, did we have it back in the VB3 days too? I guess we did. It must have been VB4 and Unicode that made things messy until later on (VB5?) when we got StrPtr, StrConv, and such. But I admit I don't remember the precise history well at all.

 

[strongm]

Well, we only needed StrPtr (introduced in VB5 as you correctly recall) because MS decided to make VB (even) more API-friendly than it already was by changing how strings worked under the bonnet (in VB3 and earlier VarPtr would correctly return the address of the memory containing the string; as from VB4 it no longer did, so StrPtr was introduced to do what VarPtr had originally done).

 

[toma2]

Cassie2002, dilettante, vb5prgrmr and strongm,
Thanks all for your comments and directions. I did go looking through some of the resources you mentioned and found lots of good info and, most importantly, just what I needed. I suspect I'll be looking into those API resources more now.