Magic Wiki-Wakka: Windows API

Most recent edit on 2010-04-13 17:06:38 by ArchLineberger [Added params for tapi32.RequestMakeCall]

Additions:
~2)Application Name (comment)

Comment
Return code

Deletions:
~2)
return code

Edited on 2010-03-16 17:28:19 by ArchLineberger [update to default printer]

Additions:
Update v.Default Printer Name with strtoken(DefaultPrinterInfo,1,',')

Edited on 2010-03-16 17:25:16 by ArchLineberger [Added Default Printer]

Additions:

Default Printer

GetProfileStringA,AAAA44,

'windows'
'device'
',,,'
DefaultPrinterInfo
254

return code

Edited on 2009-11-28 18:41:16 by ArchLineberger [Added link to Windows SDK]

Additions:
Windows versions later than XP break from this lineage to introduce a vector graphics interface and .NET set of interface modules. The following API functions are therefore unable to address the new Vista features. Nonetheless, they will be with us for a while. You can get a list of the pre-.NET Windows library function parameters using some free utilities such as APIGen∞. The complete description of functions’ parameters and requirements is provided in the Windows Platform SDK 2003∞.

Deletions:
Windows versions later than XP break from this lineage to introduce a vector graphics interface and .NET set of interface modules. The following API functions are therefore unable to address the new Vista features. Nonetheless, they will be with us for a while. You can get a list of the Windows library function parameters using some free utilities such as http://winrazor.chat.ru/apigen.zip∞. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.

Edited on 2009-11-28 18:27:21 by ArchLineberger [Added ling=k to API Gen]

Additions:
Windows versions later than XP break from this lineage to introduce a vector graphics interface and .NET set of interface modules. The following API functions are therefore unable to address the new Vista features. Nonetheless, they will be with us for a while. You can get a list of the Windows library function parameters using some free utilities such as http://winrazor.chat.ru/apigen.zip∞. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.

Deletions:
Windows versions later than XP break from this lineage to introduce a vector graphics interface and .NET set of interface modules. The following API functions are therefore unable to address the new Vista features. Nonetheless, they will be with us for a while. You can get a list of the Windows library function parameters using some free utilities such as APIViewer. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.

Edited on 2009-11-28 17:59:22 by ArchLineberger [Modify first paragraph.]

Additions:
The current API—Win32 (and its near-identical 64-bit equivalent, Win64)—have been with us since Windows NT 3.1, launched in 1993. Its history is older still; Win32's design was largely based on that of Win16, due to the phenomenal success of the Windows 3.0 product line. Win32, though much larger and more expansive, took many concepts from Win16 to allow developers to more easily migrate to the new platform. With the release of Windows 95, Win32 became the dominant API.

Deletions:
The current API—Win32 (and its near-identical 64-bit equivalent, Win64)—have been with us since Windows NT 3.1, launched in 1993. Its history is older still; Win32's design was largely based on that of Win16, due to the phenomenal success of the Windows 3.0 product line. Win32, though much larger and more expansive, took many concepts from Win16 to allow developers to more easily migrate to the new platform. With the release of Windows 95, Win32 became the dominant API, the status it has had ever since.

Edited on 2009-11-25 15:44:43 by ArchLineberger [Format Argument table]

Additions:

C	VB	Type	Attribute	Picture	Bytes
ATOM	Integer	2	Num	N4	2
BOOL	Long	4	Num	N9	4
BYTE	Byte	1	Num	N3	4
CHAR	Byte	1	Num	N3 or Alpha '1'	1
COLORREF	Long	4	Num	N9	4
DWORD	Long	4	Num	N9	4
WWND,HDC,etc	Long	4	Num	N9	4
INT,UINT	Long	4	Num	N9	4
LONG	Long	4	Num	N9	4
LPARAM	Long	4	Num	N9	4
LPDWORD	Long	L	Num	N9	4
LPINT, LPUINT	Long	4	Num	N9	4
LPRECT	Type	T †	BLOB	BLOB
LPSTR,LPCSTR	String	A	Alpha	255	255
LPVOID	As any	U ††	Unicode	255	255
LPVOID	As any	V	Num	N9	4
LPWORD	Integer	L	Num	N9	4
LRESULT	Long	4	Num	N9	4
NULL	Long	4	0 as expr		4
SHORT	Integer	2	Num	N4	2
VOID		0	nothing		2
WORD	Integer	4	Num	N5	2
WPARAM	Long	4	Num	N9	4

† If the documentation mentions that the function is a STRUCTURE, you must use a BLOB, type 'T'. As with alpha variables, you must fill the variable - before calling the function - with the number of bytes that will be returned so Magic can reserve the proper amount of space for the results. Since each alpha character is a byte and it doesn't matter to Magic what the bytes are, the easiest way to fill the variable is with the function BufSetAlpha('BB'var,'X',1,'N','False'L) where 'BB'var points to the BLOB variable, 'N' is the number of bytes to fill, and the logical is true if the buffer should receive a string of undetermined size; otherwise, set it to false.
†† Please note that the U argument type is not supported by all versions of eDeveloper. It sees to be present in 10.1 SP3d but it is unclear when it was added. The other details of this type are also not clear so are assumed the same as for type A.

Deletions:

C	VB	eDev<	BR>	Argument<
BR>	Type	eDev<	BR>	Attribute
eDev<	BR>	Picture	ATOM	Integer
2	Num	N5	BOOL	Long
4	Num	N10	BYTE	Byte
1	Num	N3	CHAR	Byte
1	Num	N3 or Alpha '1'	COLORREF	Long
4	Num	N10	DWORD	Long
4	Num	N10	WWND,HDC,etc	Long
4	Num	N10	INT,UINT	Long
4	Num	N10	LONG	Long
4	Num	N10	LPARAM	Long
4	Num	N10	LPDWORD	Long
L	Num	N10	LPINT, LPUINT	Long
4	Num	N10	LPRECT	Type
T	BLOB	BLOB	LPSTR,LPCSTR	String
A	Alpha	255	LPVOID	As any
U	Unicode†	255	LPVOID	As any
V	Num	N10	LPWORD	Integer
L	Num	N10	LRESULT	Long
4	Num	N10	NULL	Long
4	0 as expr		SHORT	Integer
2	Num	N5	VOID
0	nothing		WORD	Integer
4	Num	N5	WPARAM	Long
4	Num	N10

If the documentation mentions that the function is a STRUCTURE, you must use a BLOB, type 'T'. As with alpha variables, you must fill the variable - before calling the function - with the number of bytes that will be returned so Magic can reserve the proper amount of space for the results. Since each alpha character is a byte and it doesn't matter to Magic what the bytes are, the easiest way to fill the variable is with the function BufSetAlpha('BB'var,'X',1,'N','False'L) where 'BB'var points to the BLOB variable, 'N' is the number of bytes to fill, and the logical is true if the buffer should receive a string of undetermined size; otherwise, set it to false.
† Please note that the U argument type is not supported by all versions of eDeveloper. It sees to be present in 10.1 SP3d but it is unclear when it was added. The other details of this type are also not clear so are assumed the same as for type A.

Edited on 2009-11-25 14:48:39 by ArchLineberger [Explaination of Structures]

Additions:

C	VB	eDev<	BR>	Argument<
BR>	Type	eDev<	BR>	Attribute
eDev<	BR>	Picture	ATOM	Integer
2	Num	N5	BOOL	Long
4	Num	N10	BYTE	Byte
1	Num	N3	CHAR	Byte
1	Num	N3 or Alpha '1'	COLORREF	Long
4	Num	N10	DWORD	Long
4	Num	N10	WWND,HDC,etc	Long
4	Num	N10	INT,UINT	Long
4	Num	N10	LONG	Long
4	Num	N10	LPARAM	Long
4	Num	N10	LPDWORD	Long
L	Num	N10	LPINT, LPUINT	Long
4	Num	N10	LPRECT	Type
T	BLOB	BLOB	LPSTR,LPCSTR	String
A	Alpha	255	LPVOID	As any
U	Unicode†	255	LPVOID	As any
V	Num	N10	LPWORD	Integer
L	Num	N10	LRESULT	Long
4	Num	N10	NULL	Long
4	0 as expr		SHORT	Integer
2	Num	N5	VOID
0	nothing		WORD	Integer
4	Num	N5	WPARAM	Long
4	Num	N10

If the documentation mentions that the function is a STRUCTURE, you must use a BLOB, type 'T'. As with alpha variables, you must fill the variable - before calling the function - with the number of bytes that will be returned so Magic can reserve the proper amount of space for the results. Since each alpha character is a byte and it doesn't matter to Magic what the bytes are, the easiest way to fill the variable is with the function BufSetAlpha('BB'var,'X',1,'N','False'L) where 'BB'var points to the BLOB variable, 'N' is the number of bytes to fill, and the logical is true if the buffer should receive a string of undetermined size; otherwise, set it to false.
To determine the number of bytes to reserve, you must look to the layout of the structure in the documentation. It should designate the number and type of elements that will be returned in the BLOB. Use the table above to learn the number of bytes in each element and sum them to get the total.

Deletions:

C	VB	eDev<	BR>	Argument<
BR>	Type	eDev<	BR>	Attribute
eDev<	BR>	Picture	ATOM	Integer
2	Num	N5	BOOL	Long
4	Num	N10	BYTE	Byte
1	Num	N3	CHAR	Byte
1	Num	N3 or Alpha '1'	COLORREF	Long
4	Num	N10	DWORD	Long
4	Num	N10	WWND,HDC,etc	Long
4	Num	N10	INT,UINT	Long
4	Num	N10	LONG	Long
4	Num	N10	LPARAM	Long
4	Num	N10	LPDWORD	Long
L	Num	N10	LPINT, LPUINT	Long
4	Num	N10	LPRECT	Type
T	BLOB		LPSTR,LPCSTR	String
A	Alpha	255	LPVOID	As any
U	Unicode†	255	LPVOID	As any
V	Num	N10	LPWORD	Integer
L	Num	N10	LRESULT	Long
4	Num	N10	NULL	Long
4	0 as expr		SHORT	Integer
2	Num	N5	VOID
0	nothing		WORD	Integer
4	Num	N5	WPARAM	Long
4	Num	N10

Edited on 2009-11-24 22:45:56 by ArchLineberger [Expanded information on pre-filling variables.]

Additions:
Windows versions later than XP break from this lineage to introduce a vector graphics interface and .NET set of interface modules. The following API functions are therefore unable to address the new Vista features. Nonetheless, they will be with us for a while. You can get a list of the Windows library function parameters using some free utilities such as APIViewer. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.
There are two methods for using the Windows Application Programming Interface available to you in eDeveloper, the UDP operation and the CallDLLS() function. The differences between the two are:

Like all functions, CallDLLS() is replaced in the expression by the value that the function returns; whereas, the UDP operation places the called function's return value in the last argument.
CallDLLS() cannot alter the value of any of the passed arguments; the called function can ONLY return a value. UDP however, is able to return a value AS WELL AS to modify the value of any of the passed parameters.

Using Visual Basic terminology, arguments in the three flavors of the CallDLL function (CallDLL, CallDLLS, and CallDLLF) are passed "By Value" and not "By Reference." This means that any variable used to pass a value to the API cannot be updated by the API. If you need a passed variable updated, instead of using the CallDLL() function to call the API, use a UDP operation. Variables passed as arguments in UDP operations ARE passed by reference and can, therefore, be updated by the API. Just make sure you initialize the variable before the UDP operation with a nonsense string that is at least as large as the expected return value.

Pre-fill alpha and BLOB variables with enough characters (any character) to fill the variable.

eDev can utilize dlls using several conventions; Standard, C, and Fast. The convention used and the syntax of the module name must agree. When you Invoke UDP, you select the convention in the Properties/Convention; in a v9 Call UDP, you select the convention in the Cnv column. For an explanation on calling conventions and using external functions other than Windows API, see Andreas Sedlmeier's in-depth discussion. The Windows API uses the "Standard" convention, so for these functions use the following syntax.
Traditionally eDev did not support Unicode for parameters or return values of external functions, (DLLs) or ActiveX and this could mean that using a Unicode Windows API would be unpredictable. It appears through some tests with USER32.MessageBoxW that this has changed in the later service packs of eDeveloper v10. Testing was performed with 10.1 SP3d but it is unclear when this behavior changed. Testing showed that MessageBoxW was able to display Unicode data passed from eDeveloper which was outside the code page of the Windows language and which could not be displayed by MessageBoxA.
When using Unicode data care should be taken but especially when using the older versions. Start testing with the function name without "A" or "W" appended. If the function DOES NOT deal with character data this will work. If the function DOES deal with character data you'll get an error message something like "function in module not found," then try the ANSI version by appending an "A" to the function name. If this does not give the required results then try appending a "W" to the function name, it may work if you are using a late enough version of eDeveloper but thorough testing should be made for the specific function.

UDP

Zoom at the next column to select an expression such as '@modulename.functionname'
Zoom at "Arguments" to specify the arguments (parameters)
Select "Standard" in the Properties/Convention (the default)

Windows API functions may or may not return a value. The return value may be specified in other languages' syntax before or after the parameter specifications depending upon the language in which it is described, but the arguments are always within parentheses:
In eDev, the first argument is always a variable mask consisting of a string where each character represents the Argument Type. The last letter in the "Argument Type String" always describes the data type of the function's return value or “0” if none.

Deletions:
Windows Vista breaks from this lineage to introduce a vector graphics interface and .NET set of interface modules. The following API functions are therefore unable to address the new Vista features. Nonetheless, they will be with us for a while. You can get a list of the Windows library function parameters using some free utilities such as APIViewer. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.
There are two methods for using the Windows Application Programming Interface available to you in eDeveloper, the Call UDP operation and the CallDLLS() function. The differences between the two are:

Like all functions, CallDLLS() is replaced in the expression by the value that the function returns; whereas, the Call UDP operation places the called function's return value in the last argument.
CallDLLS() cannot alter the value of any of the passed arguments; the called function can ONLY return a value. Call UDP however, is able to return a value AS WELL AS to modify the value of any of the passed parameters.

Using Visual Basic terminology, arguments in the three flavors of the CallDLL function (CallDLL, CallDLLS, and CallDLLF) are passed "By Value" and not "By Reference." This means that any variable used to pass a value to the API cannot be updated by the API. If you need a passed variable updated, instead of using the CallDLL() function to call the API, use a Call UDP operation. Variables passed as arguments in Call UDP operations ARE passed by reference and can, therefore, be updated by the API. Just make sure you initialize the variable before the Call UDP operation with a nonsense string that is at least as large as the expected return value.

Pre-fill alpha and BLOB variables with some (any) character using an update operation

eDev can call dlls using several conventions; Standard, C, and Fast. The convention used and the syntax of the module name must agree. When you Call UDP in version 10, you select the convention in the Properties/Convention; in v9, you select the convention in the Cnv column. For an explanation on calling conventions and using external functions other than Windows API, see Andreas Sedlmeier's in-depth discussion. The Windows API uses the "Standard" convention, so for these functions use the following syntax.
Traditionally eDev did not support Unicode for parameters or return values of external functions, (DLLs) or ActiveX and this could mean that using a Unicode Windows API would be unpredictable. It appears through some tests with USER32.MessageBoxW that this has changed in the latest service packs of eDeveloper v10. Testing was performed with 10.1 SP3d but it is unclear when this behaviour changed. Testing showed that MessageBoxW was able to display Unicode data passed from eDeveloper which was outside the code page of the Windows language and which could not be displayed by MessageBoxA.
When using Unicode data care should be taken but especailly when using the older versions. Start testing with the function name without "A" or "W" appended. If the function DOES NOT deal with character data this will work. If the function DOES deal with character data you'll get an error message something like "function in module not found," then try the ANSI version by appending an "A" to the function name. If this does not give the required results then try appending a "W" to the function name, it may work if you are using a late enough version of eDeveloper but thorough testing should be made for the specific function.

UDP

Zoom at the next column to select an expression
Zoom at "Arguments" to specify the arguments (parameters)
Select "Standard" in the Properties/Convention

Windows API functions may or may not return a value. The return value may be specified before or after the parameter specifications depending upon the language in which it is described, but the arguments are always within parentheses:
In eDev, the first argument is a variable mask consisting of a string where each character represents the Argument Type. The last letter in the "Argument Type String" always describes the data type of the function's return value or “0” if none.

Edited on 2009-01-10 19:57:12 by ArchLineberger [Steve Blank's explanation of CallDLL vs CallUDP]

Additions:
Using Visual Basic terminology, arguments in the three flavors of the CallDLL function (CallDLL, CallDLLS, and CallDLLF) are passed "By Value" and not "By Reference." This means that any variable used to pass a value to the API cannot be updated by the API. If you need a passed variable updated, instead of using the CallDLL() function to call the API, use a Call UDP operation. Variables passed as arguments in Call UDP operations ARE passed by reference and can, therefore, be updated by the API. Just make sure you initialize the variable before the Call UDP operation with a nonsense string that is at least as large as the expected return value.

Edited on 2008-12-29 17:42:47 by ArchLineberger [function added]

Additions:

Change Title Bar Wording

Invoke UDP '@user32.SetWindowTextA<%27%40user32.SetWindowTextA>'
with 4 arguments:
1. '4A2'
2. WinHWND(0)
3. 'MyNewCaption'
4. 'FALSE'LOG

Edited on 2008-07-10 14:13:19 by RosieColler [Additional Unicode details]

Additions:

C	VB	eDev<	BR>	Argument<
BR>	Type	eDev<	BR>	Attribute
eDev<	BR>	Picture	ATOM	Integer
2	Num	N5	BOOL	Long
4	Num	N10	BYTE	Byte
1	Num	N3	CHAR	Byte
1	Num	N3 or Alpha '1'	COLORREF	Long
4	Num	N10	DWORD	Long
4	Num	N10	WWND,HDC,etc	Long
4	Num	N10	INT,UINT	Long
4	Num	N10	LONG	Long
4	Num	N10	LPARAM	Long
4	Num	N10	LPDWORD	Long
L	Num	N10	LPINT, LPUINT	Long
4	Num	N10	LPRECT	Type
T	BLOB		LPSTR,LPCSTR	String
A	Alpha	255	LPVOID	As any
U	Unicode†	255	LPVOID	As any
V	Num	N10	LPWORD	Integer
L	Num	N10	LRESULT	Long
4	Num	N10	NULL	Long
4	0 as expr		SHORT	Integer
2	Num	N5	VOID
0	nothing		WORD	Integer
4	Num	N5	WPARAM	Long
4	Num	N10

† Please note that the U argument type is not supported by all versions of eDeveloper. It sees to be present in 10.1 SP3d but it is unclear when it was added. The other details of this type are also not clear so are assumed the same as for type A.

Deletions:
† Please note that the U argument type is not supported by all versions of eDeveloper. It sees to be present in 10.1 SP3d but it is unclear when it was added.

C	VB	eDev<	BR>	Argument<
BR>	Type	eDev<	BR>	Attribute
eDev<	BR>	Picture	ATOM	Integer
2	Num	N5	BOOL	Long
4	Num	N10	BYTE	Byte
1	Num	N3	CHAR	Byte
1	Num	N3 or Alpha '1'	COLORREF	Long
4	Num	N10	DWORD	Long
4	Num	N10	WWND,HDC,etc	Long
4	Num	N10	INT,UINT	Long
4	Num	N10	LONG	Long
4	Num	N10	LPARAM	Long
4	Num	N10	LPDWORD	Long
L	Num	N10	LPINT, LPUINT	Long
4	Num	N10	LPRECT	Type
T	BLOB		LPSTR,LPCSTR	String
A	Alpha	255	LPVOID	As any
V	Num	N10	LPWORD	Integer
L	Num	N10	LRESULT	Long
4	Num	N10	NULL	Long
4	0 as expr		SHORT	Integer
2	Num	N5	VOID
0	nothing		WORD	Integer
4	Num	N5	WPARAM	Long
4	Num	N10

Edited on 2008-07-10 14:06:45 by RosieColler [Updated for Unicode changes in recent Service Packs]

Additions:

Unicode Character Data

If a Windows API function deals with "character data," which means it either returns character data (or a pointer to it) or has any character parameter, the Windows API will most often provide you with two functions: an ANSI version and a Unicode version. These will be designated by a functionname suffix of "A" for the ASCII version and "W" for the Unicode version.
Traditionally eDev did not support Unicode for parameters or return values of external functions, (DLLs) or ActiveX and this could mean that using a Unicode Windows API would be unpredictable. It appears through some tests with USER32.MessageBoxW that this has changed in the latest service packs of eDeveloper v10. Testing was performed with 10.1 SP3d but it is unclear when this behaviour changed. Testing showed that MessageBoxW was able to display Unicode data passed from eDeveloper which was outside the code page of the Windows language and which could not be displayed by MessageBoxA.
When using Unicode data care should be taken but especailly when using the older versions. Start testing with the function name without "A" or "W" appended. If the function DOES NOT deal with character data this will work. If the function DOES deal with character data you'll get an error message something like "function in module not found," then try the ANSI version by appending an "A" to the function name. If this does not give the required results then try appending a "W" to the function name, it may work if you are using a late enough version of eDeveloper but thorough testing should be made for the specific function.
Visual Basic “ByVal” refers to variables of eDev Argument types 1, 2, 4, 8, and F. “ByRef” refers to eDev Argument types A, U†, D, E, L, T, and V which are actually pointers to addresses. eDev automatically supplies the address for these types rather than the value of the variable specified.
† Please note that the U argument type is not supported by all versions of eDeveloper. It sees to be present in 10.1 SP3d but it is unclear when it was added.

Deletions:
If a Windows API function deals with "character data," which means it either returns character data (or a pointer to it) or has any character parameter, the Windows API will most often provide you with two functions: an ANSI version and a Unicode version. These will be designated by a functionname suffix of "A" for the ASCII version and "W" for the Unicode version. Since eDev does not support Unicode for parameters or return values of external functions, (DLLs) or ActiveX, using a Unicode Windows API will be unpredictable. However since eDev will convert your Unicode variables to ANSI before calling, in some cases it might work. Start testing with the function name without "A" or "W" appended. If the function DOES NOT deal with character data this will work. If the function DOES deal with character data you'll get an error message something like "function in module not found," then try the ANSI version by appending an "A" to the function name.
Visual Basic “ByVal” refers to variables of eDev Argument types 1, 2, 4, 8, and F. “ByRef” refers to eDev Argument types A, D, E, L, T, and V which are actually pointers to addresses. eDev automatically supplies the address for these types rather than the value of the variable specified.

Edited on 2008-04-07 21:17:47 by ArchLineberger [added function]

Additions:

Sleep

Sleep,40, nMilliSeconds

milliseconds delay

Edited on 2007-09-26 18:29:47 by AndreasSedlmeier [added paragraph about GetFileTime and linked a sample]

Additions:

File Time

GetFileTime∞ retrieves date and time that a file was created, last accessed and last modified.
This API requires however several other APIs being involved (CreateFile, FileTimeToSystemTime, SystemTimeToTzSpecificLocalTime, ....).
Find a complete sample for usage of this function for retrieving file dates implemented with eDeveloper v9.4 SP4 at http://tech.groups.yahoo.com/group/magicu-l/files/FileDateTime.exp∞.
Many thanks to Mathieu Claesen for this nice sample.

Edited on 2007-04-12 23:35:00 by ArchLineberger

Additions:
In both cases for this function, the arguments are within the parentheses, represented here by (...), and the return value is the same 4 byte signed integer: in VB, the return value is called Long; in C++, it is called BOOL.

Deletions:
In both cases for this function, the arguments are within the parentheses (represented here by ...) and the return value is the same 4 byte signed integer: in VB, the return value is called Long; in C++, it is called BOOL.

Edited on 2007-03-21 18:04:49 by ArchLineberger

Additions:
The current API—Win32 (and its near-identical 64-bit equivalent, Win64)—have been with us since Windows NT 3.1, launched in 1993. Its history is older still; Win32's design was largely based on that of Win16, due to the phenomenal success of the Windows 3.0 product line. Win32, though much larger and more expansive, took many concepts from Win16 to allow developers to more easily migrate to the new platform. With the release of Windows 95, Win32 became the dominant API, the status it has had ever since.
Windows Vista breaks from this lineage to introduce a vector graphics interface and .NET set of interface modules. The following API functions are therefore unable to address the new Vista features. Nonetheless, they will be with us for a while. You can get a list of the Windows library function parameters using some free utilities such as APIViewer. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.

Deletions:
You can get a list of the Windows library function parameters using some free utilities such as APIViewer. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.

Edited on 2007-02-19 18:25:53 by ArchLineberger

Additions:

WinMM.dll

Play a WAV

PlaySoundA,A48

Filespec (max 256)
Handler (131072)
0

Edited on 2007-02-19 17:56:05 by ArchLineberger

Additions:

Advapi32

Beep (custom)

Beep,444

Frequency
Duration
Return code

Tapi32.dll

Dial

tapiRequestMakeCall,AAAA4

Phone Number
Name
return code

Hangup

Select A - vDialerWinHandle(N4)
Update A with:
calldll('user32,FindWindowA','AA4','DialerClass','Phone Dialer')
calldll('user32.SendMessageA',44444',a,HVAL('10'),0,0)
calldll('user32.SendMessageA',44444',a,HVAL('2'),0,0)
calldll('user32.SendMessageA',44444',a,HVAL('82'),0,0)

Beep (standard Windows)

Deletions:

advapi32

Beep

Oldest known version of this page was edited on 2007-02-19 17:38:18 by ArchLineberger []

Page view:

Windows API

You can get a list of the Windows library function parameters using some free utilities such as APIViewer. The complete description of functions’ parameters and requirements is provided in the Microsoft Platform SDK. Search Google for the latest addresses of these free utilities.

There are two methods for using the Windows Application Programming Interface available to you in eDeveloper, the Call UDP operation and the CallDLLS() function. The differences between the two are:

Like all functions, CallDLLS() is replaced in the expression by the value that the function returns; whereas, the Call UDP operation places the called function's return value in the last argument.
CallDLLS() cannot alter the value of any of the passed arguments; the called function can ONLY return a value. Call UDP however, is able to return a value AS WELL AS to modify the value of any of the passed parameters.

To use the Windows API in eDeveloper, you need to do four things:

Select required variables for the parameters
Pre-fill alpha and BLOB variables with some (any) character using an update operation
Call (Invoke v10) UDP or use CallDLLS() in an expression
Specify the parameters

Syntax

eDev can call dlls using several conventions; Standard, C, and Fast. The convention used and the syntax of the module name must agree. When you Call UDP in version 10, you select the convention in the Properties/Convention; in v9, you select the convention in the Cnv column. For an explanation on calling conventions and using external functions other than Windows API, see Andreas Sedlmeier's in-depth discussion. The Windows API uses the "Standard" convention, so for these functions use the following syntax.

If a Windows API function deals with "character data," which means it either returns character data (or a pointer to it) or has any character parameter, the Windows API will most often provide you with two functions: an ANSI version and a Unicode version. These will be designated by a functionname suffix of "A" for the ASCII version and "W" for the Unicode version. Since eDev does not support Unicode for parameters or return values of external functions, (DLLs) or ActiveX, using a Unicode Windows API will be unpredictable. However since eDev will convert your Unicode variables to ANSI before calling, in some cases it might work. Start testing with the function name without "A" or "W" appended. If the function DOES NOT deal with character data this will work. If the function DOES deal with character data you'll get an error message something like "function in module not found," then try the ANSI version by appending an "A" to the function name.

CallDLLS

Use in the expression for an Evaluate statement, specifying a variable to receive the Return Code
Update a (Return) variable with the expression
Use the expression as a Condition to another statement

Expression:

CallDLLS('modulename.functionname','argument type string',arg1,arg2,...)

UDP

Versions 8-9

Call Operation of type UDP
Zoom at the ":" to select an expression
Enter the DLL as '@modulename.functionname'
Zoom at "Arg:" to specify the arguments (parameters)
Select "Standard in the "Cnv:" column

Version 10

Invoke Operation of type UDP
Zoom at the next column to select an expression
Enter the DLL as '@modulename.functionname'
Zoom at "Arguments" to specify the arguments (parameters)
Select "Standard" in the Properties/Convention

Return Values

Visual Basic

Public Declare Function GetVolumeInformation Lib "kernel32.dll" Alias "GetVolumeInformationA" (…) As Long

C++

BOOL GetVolumeInformation(…);

In both cases for this function, the arguments are within the parentheses (represented here by ...) and the return value is the same 4 byte signed integer: in VB, the return value is called Long; in C++, it is called BOOL.
If nothing is returned, VB will have no text after the closing parenthesis whereas C will show VOID before the opening. Regardless, eDev Call UDP needs to have a container for the return value even if it is null; therefore, if there is no return value, the final argument in the argument string needs to be “0” indicating no return.

Arguments

In eDev, the first argument is a variable mask consisting of a string where each character represents the Argument Type. The last letter in the "Argument Type String" always describes the data type of the function's return value or “0” if none.
Visual Basic “ByVal” refers to variables of eDev Argument types 1, 2, 4, 8, and F. “ByRef” refers to eDev Argument types A, D, E, L, T, and V which are actually pointers to addresses. eDev automatically supplies the address for these types rather than the value of the variable specified.
If an argument is passed to, but is not updated by the function, you can pass an expression rather than a variable so long as the result of the expression is of the proper eDev Attribute.

Argument types:

C	VB	eDev<	BR>	Argument<
BR>	Type	eDev<	BR>	Attribute
eDev<	BR>	Picture	ATOM	Integer
2	Num	N5	BOOL	Long
4	Num	N10	BYTE	Byte
1	Num	N3	CHAR	Byte
1	Num	N3 or Alpha '1'	COLORREF	Long
4	Num	N10	DWORD	Long
4	Num	N10	WWND,HDC,etc	Long
4	Num	N10	INT,UINT	Long
4	Num	N10	LONG	Long
4	Num	N10	LPARAM	Long
4	Num	N10	LPDWORD	Long
L	Num	N10	LPINT, LPUINT	Long
4	Num	N10	LPRECT	Type
T	BLOB		LPSTR,LPCSTR	String
A	Alpha	255	LPVOID	As any
V	Num	N10	LPWORD	Integer
L	Num	N10	LRESULT	Long
4	Num	N10	NULL	Long
4	0 as expr		SHORT	Integer
2	Num	N5	VOID
0	nothing		WORD	Integer
4	Num	N5	WPARAM	Long
4	Num	N10

Examples

The following examples show the dll name at the top of the section and the entry point for each function. Use the syntax explained above for the usage type you chose.

advapi32

OS User Name

GetUserNameA,AL4,

User Name returned
LEN(#1)
return code

Kernel32.dll

Command Line Parameters

GetCommandLineA,A4,

Parameters returned
return code

Computer Name

GetComputerNameA,AL4,

Computer name returned
LEN(#1)
return code

Create Directory

CreateDirectoryA,A44,

TRIM(directory name)
FileAttributes
return code

Current Directory

GetCurrentDirectoryA,4A4,

LEN(#2)
Current directory returned
return code

Environment Variables

GetEnvironmentVariableA,AAL4,

Environment variable name
Value returned
LEN(#2)
return code

File Attributes

GetFileAttributesA,'A40',

Filespec
Attributes

SetFileAttributesA,’A41’,

Filespec
Attributes
Return Code

Hard Disk Serial Number

GetVolumeInformationA,'AA4L44A44',

Root of logical drive (C:\)
Volume name buffer
LEN(Volume name buffer)
Serial number (Since it can be 10 digits, specify as 10 digit Numeric Float)
0
0
File system name buffer
LEN(#7)
Return

Installation Directory

GetModuleFileNameA,4A44,

0 (implies the current process)
fully-qualified path returned
LEN(#2)
return code

Temporary Path

GetTempPathA,’4A4’,

LEN(#2)
Returned path
Return Code

Time and Zone

The following returns the current local date, time, and UTC bias minutes (aka time zone) and formats them as a single string in the xs:dateTime format 'YYYY-MM-DDTHH:MM:SS±HH:MM'.

Define six variables as follows:

(A) bufSystemTime (Blob)
(B) dtmCurDate (Date)
(C) dtmCurTime (Time)
(D) bufTimeZoneInfo (Blob)
(E) lngRetVal (Numeric 'N10')
(F) lngBiasMinutes (Numeric 'N10')

Note that the character data fields are Unicode.
Perform the following operations:

Evaluate expression: BufSetAlpha('A'VAR,1,Fill(ASCIIChr(0),16),1,16,'FALSE'LOG)
Invoke UDP: '@kernel32.GetLocalTime'
Argument 1: 'T0'
Argument 2: Variable A
Update Variable B with AddDate('00/00/0000'DATE, BufGetNum('A'VAR,1,1,2), BufGetNum('A'VAR,3,1,2), BufGetNum('A'VAR,7,1,2))
Update Variable C with AddTime('00:00:00'TIME, BufGetNum('A'VAR,9,1,2), BufGetNum('A'VAR,11,1,2), BufGetNum('A'VAR,13,1,2))
Evaluate Expression BufSetAlpha('D'VAR,1,Fill(ASCIIChr(0),172),1,172,'FALSE'LOG)
Invoke UDP with '@kernel32.GetTimeZoneInformation'
Argument 1: 'T4'
Argument 2: Variable D
Argument 3: Variable E
Update Variable F with BufGetNum('D'VAR,1,1,4)
Format this information into a proper xs:dateTime string:
DStr(B,'YYYY-MM-DD') & 'T' & TStr(C,'HH:MM:SS') & IF(F<0,'+','-') & TStr(ABS(F)*60,'HH:MM')

Shell32.dll

Manipulate an External File Type

ShellExecuteA,4AA444,

WINHWND(0)
Operation in parentheses; i.e., 'open'
{filespec inc'l extension}
Parameters (0 for a document)
Default directory (0) if #3 includes path)
Window type
return code

Operations

edit - Launches an editor and opens the document for editing. If lpFile is not a document file, the function will fail.
explore - Explores the folder specified by lpFile.
find - Initiates a search starting from the specified directory.
open - Opens the file specified by the lpFile parameter. The file can be an executable file, a document file, or a folder.
print - Prints the document file specified by lpFile. If lpFile is not a document file, the function will fail.
NULL - For systems prior to Microsoft Windows 2000, the default verb is used if it is valid and available in the registry. If not, the "open" verb is used. For Windows 2000 and later systems, the default verb is used if available. If not, the "open" verb is used. If neither verb is available, the system uses the first verb listed in the registry.

Window Types

Flags that specify how an application is to be displayed when it is opened. If lpFile specifies a document file, the flag is simply passed to the associated application. It is up to the application to decide how to handle it.

0 - Hides the window and activates another window.
1 - Maximizes the specified window.
2 - Minimizes the specified window and activates the next top-level window in the z-order.
3 - Activates and displays the window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when restoring a minimized window.
4 - Activates the window and displays it in its current size and position.
5 - Sets the show state based on the SW_ flag specified in the STARTUPINFO structure passed to the CreateProcess function by the program that started the application. An application should call ShowWindow with this flag to set the initial show state of its main window.
6 - Activates the window and displays it as a maximized window.
7 - Activates the window and displays it as a minimized window.
8 - Displays the window as a minimized window. The active window remains active.
9 - Displays the window in its current state. The active window remains active.
10 - Displays a window in its most recent size and position. The active window remains active.
11 - Activates and displays a window. If the window is minimized or maximized, Windows restores it to its original size and position. An application should specify this flag when displaying the window for the first time.

User32.dll

Beep

MessageBeep,44

Parameter
Return code

Parameters

0 Standard
16 Error
32 Question
48 Warning
64 Information

Change Title Bar Icon

Select:

A = v_Prog_Handle, N10
B = v_Icon_Handle, N10
C = {your icon filespec}, A255

Update A with CallDLLS ('User32.GetActiveWindow','4')

Update B with CallDLLS ('Shell32.ExtractIconA','4A44',0,C,0)

Evaluate CallDLLS(‘User32.SendMessageA','44444',A,128,1,B)

Evaluate CallDLLS(‘User32.SendMessageA','44444',A,128,0,B)

Cursor Visibility

Hide - CallDLLS('User32.ShowCursor', '44', 0)
Show - CallDLLS('User32.ShowCursor', '44', 1)

Key State

CallDLLS('user32.GetKeyState','42',20)
Returns Logical 1 if on
Where ‘20’ is the Hex value of the key (20 is Caps Lock)

Message Box

MessageBoxA','4AA44'

WINHWND(0)
Message
Heading
Parameters
return code

Parameters

HVAL(Button Code) + HVAL(Icon) + HVAL(Default Button)
Where:

Default Button (A4): '0000' Button 1
'0100' Button 2
'0200' Button 3
Icon (A4): '0010' Stop
'0020' Question
'0030' Exclamation
'0040' Information
Button Codes (A4): '0000' OK
'0001' OK/Cancel
'0002' Abort/Retry/Ignore
'0003' Yes/No
'0004' Cancel
'0005' Retry/Cancel

Minimized Application Name

Select:

A = v_Handle, N10
B = v_App_Handle, N10

Update B with CallDLLS ('User32.GetParent','44',WINHWND (0))

Update B with CallDLLS ('User32.GetParent','44',A)

Simulate Keystrokes

Keybd_Event,'22440',

Decimal value of the Virtual-Key code for control keys or the ASCII value of character keys*
0 (not used)
Flags: 0 = press; 2 = release
Additional value associated with keystroke

Examples

Press Alt - Evaluate CallDLLS ('user32.keybd_event','22440',18,0,0,0)
Release Alt - Evaluate CallDLLS ('user32.keybd_event','22440',18,0,2,0)
Press Q - Evaluate CallDLLS ('user32.keybd_event','22440',ASC(Q),0,0,0)
Release Q - Evaluate CallDLLS ('user32.keybd_event','22440',ASC(Q),0,2,0)

* NOTE: Search MSDN for "Virtual-Key codes"∞

Screen Resolution

GetSystemMetrics,44,

0
Returned horizontal resolution
return code

GetSystemMetrics,44,

1
Returned vertical resolution
return code

Window Control

User32.ShowWindow,444,

WINHWND(0)
Attribute
return code

Attributes are:

0 = HIDE
1 = NORMAL
2 - SHOWMINIMIZED
3 - MAXIMIZE
4 - SHOWNOACTIVATE
5 - SHOW
6 - MINIMIZE
7 - SHOWMINNOACTIVE
8 - SHOWNA
9 - RESTORE

If you maximize your window and then make calls to other programs from it, your window will revert to its default size.

This information was gleaned from the Magic-u list and compiled with help from Steve Blank and Andreas Sedlmeier