Molti hanno richiesto una guida API per convertire le loro dichiarazioni WinAPI in C o VB per l'utilizzo con Rapid-Q, così ecco un riassunto con qualche breve spiegazione. Grazie a Mayuresh S. Kadu per questa guida API WIN32 in VB.
| Tipo dati in C |
Pascal |
VB |
Rapid-Q |
| ATOM |
SHORT |
byval as INTEGER |
SHORT |
| BOOL |
BOOLEAN |
byval as LONG |
LONG |
| BYTE |
BYTE |
byval as BYTE |
BYTE |
| CHAR |
CHAR |
byval as BYTE |
BYTE |
| CHAR[20] |
STRING[20] |
as STRING |
Non applicabile in dichiarazioni API |
| COLORREF |
LONGINT |
byval as LONG |
LONG |
| DWORD |
DWORD |
byval as LONG |
DWORD |
| Windows handles ie. HDC |
Windows Handles |
byval as LONG |
LONG |
| INT, UINT |
INTEGER, DWORD |
byval as LONG |
INTEGER, DWORD |
| LONG |
LONGINT |
byval as LONG |
LONG |
| LPARAM |
LONGINT |
byval as LONG |
LONG |
| LPDWORD |
^DWORD |
as LONG |
BYREF as DWORD |
| LPINT, LPUINT |
^INTEGER |
as LONG |
BYREF as LONG |
| LPRECT |
^TRECT |
as ANY |
QRECT |
| LPSTR, LPCSTR |
PCHAR |
byval as STRING |
BYREF as STRING |
| LPVOID |
LONGINT |
as ANY |
LONG |
| LPWORD |
^WORD |
as INTEGER |
BYREF as WORD |
| LRESULT |
LONGINT |
byval as LONG |
LONG |
| NULL |
NIL |
byval as LONG |
LONG |
| SHORT |
SHORT |
byval as INTEGER |
SHORT |
| WORD |
WORD |
byval as INTEGER |
WORD |
| WPARAM |
LONGINT |
byval as LONG |
LONG |
I tipi di dati in rosso sono puntatori alla variabile. In Rapid-Q, ciò comporta l'uso di VARPTR quando si passa l'indirizzo della variabile, e non il valore della variabile. Ecco alcuni esempi di conversione:
In VB:
DECLARE SUB Test LIB "USER32" ALIAS "What" _
(byval L AS LONG, byval S AS STRING)
Test (1230, "Hello world!")
In Rapid-Q:
DECLARE SUB Test LIB "USER32" ALIAS "What" _
(byval L AS LONG, byval S AS STRING)
Test (1230, "Hello world!")
Non c'è alcuna differenza, ma notate che Rapid-Q non usa BYVAL, che può essere omesso. Nell'esempio precedente, la stringa è passata per riferimento, cioè viene passato l'indirizzo della stringa, non la stringa stessa. Ecco un esempio in cui viene passata l'intera stringa (non l'indirizzo, così richiede un OLE per allocare spazio per la stringa); questo funziona in VB ma non in Rapid-Q: In VB:
DECLARE SUB Test LIB "USER32" ALIAS "What" _
(byval L AS LONG, S AS STRING)
Test (1230, "Hello world!")
In Rapid-Q:
Non è possibile in quanto non utilizza OLE per allocare la stringa.
Cosa succede con le stringhe NULL? Ecco un'altra situazione (notate che non uso molto VB, per cui potrebbe essere possibile dichiarare S cone STRING e passarlo come vbNullString; non ne sono certo, così vado sul sicuro): In VB:
DECLARE SUB Test LIB "USER32" ALIAS "What" _
(byval L AS LONG, byval S AS LONG)
Test (1230, 0&)
In Rapid-Q:
DECLARE SUB Test LIB "USER32" ALIAS "What" _
(byval L AS LONG, byval S AS LONG)
Test (1230, 0&)
Così se vogliamo passare una stringa anzichè una stringa NULL, dovremo usare VARPTR: In VB o Rapid-Q:
DIM S AS STRING
S = "Hello world!"
Test (1230, VARPTR(S))
Una stringa NULL è praticamente un indirizzo pari a 0. VARPTR ritorna semplicemente l'indirizzo di una variabile. E per gli altri puntatori, come LPWORD? Un dato WORD è semplicemente un numero positivo di 16 bit, e VB supporta solo numeri di 16 bit positivi o negativi chiamati INTEGER, ma l'idea generale è di rimuovere il comando byval quando si passano variabili per riferimento: In VB (non supporta WORD, utilizziamo il tipo più simile):
DECLARE SUB Test LIB "USER32" ALIAS "Another" _
(L AS INTEGER)
DIM L AS INTEGER
Test (L)
In Rapid-Q:
DECLARE SUB Test LIB "USER32" ALIAS "Another" _
(BYREF L AS WORD)
DIM L AS WORD
Test (L)
In Rapid-Q, utilizzate BYREF per passare variabili per riferimento; in VB non è necessario usare BYREF, come dimostrato dall'esempio precedente.
