Types of input parameters and return values
m — signed 64-bit integer — INT64, LONGLONG, ...q — unsigned 64-bit integer — UINT64, ULONGLONG, ...
l — signed 32-bit integer — LONG, INT, BOOL, ...
u — unsigned 32-bit integer — ULONG, UINT, DWORD, ...
h — handle — HANDLE, HWND, HMODULE, HINSTANCE, HICON, ... — 32-bit (x86) or 64-bit (x64) integer.
p — pointer; for numbers it is the same as u (x86) or q (x64) but can also be used to pass an object (IDispatch *) or a string.
n — signed 16-bit integer — SHORT
t — unsigned 16-bit integer — USHORT, WORD, WCHAR, OLECHAR, ...
c — signed 8-bit integer — CHAR
b — unsigned 8-bit integer — UCHAR, BYTE, ...
f — single-precision floating-point number (32 bits) — FLOAT
d — double-precision floating-point number (64 bits) — DOUBLE
w — Unicode string — BSTR, LPWSTR, LPOLESTR, OLECHAR *, WCHAR *, ...
s — ANSI/Windows string (default codepage) — LPSTR, LPCSTR, CHAR *, ...
z — OEM/DOS string (default codepage) — LPSTR, LPCSTR, CHAR *, ...
v — pointer to a VARIANT structure.
Remarks
- Read more about string types here.
- Besides handles and pointers, there are other types that change their bitness with the bitness of the process. For example: LRESULT, LPARAM, WPARAM, SIZE_T. They should also be passed and returned as type h or p so your code can work correctly regardless of the bitness of the script interpreter.
- The script types corresponding to m and q would be VT_I8 and VT_UI8, but they are not supported by JScript and VBScript, which limits what you can do with 64-bit integers in scripts. As long as the value returned by the function allows this, DynamicWrapperX converts it to type VT_I4 (32-bit signed integer) or VT_R8 (double-precision floating-point number). Since the mantissa of VT_R8 has only 53 bits, it cannot represent every number in the range of the 64-bit integer. In that case VT_I8 or VT_UI8 is returned. All you can do with these types is pass them as arguments to some other method or display their values via WScript.Echo or MsgBox. No calculations are possible.
- When a large integer is returned as VT_R8 and you want to see its value in a message box, it may not be displayed correctly because the number of digits after the decimal point in string representation of a floating-point number is limited. So if, for example, the number is 9223372036854775808, in the message box you may see 9,22337203685478E+18 instead of 9,223372036854775808E+18. However, the actual numeric value in the variable is not rounded and remains accurate.
- If the value of a 64-bit integer does not fit in any numeric type available, you can specify it in string format, decimal or hexadecimal (with a 0x prefix).
DWX.Register("lib.dll", "func", "i=m") DWX.func("0xFFFFFFFFFFFFFFFF") DWX.func("-0x7FFFFFFFFFFFFFFF") DWX.func("18446744073709551615") DWX.func("-9223372036854775807")
Output parameters
M — pointer to the specified number (its address in memory) — LONGLONG *, PLONGLONG, ...Q — same as above — ULONGLONG *, PULONGLONG, ...
L — same as above — LONG *, LPLONG, ...
H — same as above — HANDLE *, PHANDLE, LPHANDLE, ...
U — same as above — ULONG *, LPDWORD, ...
P — same as above
N — same as above — SHORT *
T — same as above — USHORT *, LPWORD, WCHAR *, OLECHAR *, ...
C — same as above — CHAR *, ...
B — same as above — UCHAR *, LPBYTE, ...
F — same as above — FLOAT *, PFLOAT
D — same as above — DOUBLE *, PDOUBLE
W — output Unicode string
S — output ANSI string
Z — output OEM string
Remarks
- The output types above can be used in scripting languages that pass arguments to methods by reference as VBScript does. In that case DynamicWrapperX can obtain a pointer to the argument's value, which it then passes to the registered function so the function can change the value at that address. If arguments are passed by value, like in JScript, they are copied, so there is no way to find and change the original. In this case you can allocate a buffer in memory by means of MemAlloc, give the returned pointer to the function (as the p type) and after calling the function read the number it put in the buffer with NumGet.
- Some scripting engines also copy strings before passing them to methods, in which case the use of output types for strings makes no sense either. The solution to this is similar to the above: a memory buffer passed as type p and reading the resulting string from it via StrGet.