Hi guys,
i'm trying to get a enumeration/callback function to work, that fills a combobox with the primary display device and more to choose (if there are any 3d accelerators for example). I tried to convert some C++ code, but i'm somehow stuck.Maybe someone can help me
inv DirectDrawEnumerateEx, OFFSET CallBackFotze, hcombo, DDENUM_NONDISPLAYDEVICES
this is the enumeration function, with the offset to my callback function, the handle of the combo box as lpContext variable and the flag at last. Should be right...
And here's my callback function...it's totally incomplete and just a try...
CallBackFotze PROC lpGUID: GUID, lpDriverDescription:LPSTR, lpDriverName:LPSTR, lpContext:LPVOID
LOCAL lpDevice: LPVOID
inv SendMessage, hcombo, CB_ADDSTRING, 0, offset lpDriverName
.IF eax != LB_ERR
.IF lpGuid == NULL
mov lpDevice, 0
.ELSE
the C++ code for the callback function looks like this:
BOOL WINAPI EnumDDrawDevice (GUID FAR *lpGUID, LPSTR lpDriverDescription, LPSTR lpDriverName, LPVOID lpContext)
( LONG iIndex;
HWND hWnd= (HWND)lpContext
LPVOID lpDevice = NULL;
iIndex = Sendmessage (hWnd, CB_ADDSTRING, 0, (LPARAM)lpDriverDescription ); <---?!?
if (iIndex!= LB_ERR)
{
if (lpGUID= NULL)
{
lpDevice = NULL;
}
else
{
lpDevice = (LPGUID) malloc (sizeof(GUID)); <-- totally lost here
if (!lpDevice) return FALSE;
memcpy (lpDevice, lpGUID, sizeof (GUID));
}
Sendmessage ( hWnd, CB_SETITEMDATA, iIndex, (LPARAM)lpDevice;
}
else
{
return DDENUMRET_CANCEL;
}
return DDENUMRET_OK
}
Is there a soul out there, able to help me ? :)
Thanks
i'm trying to get a enumeration/callback function to work, that fills a combobox with the primary display device and more to choose (if there are any 3d accelerators for example). I tried to convert some C++ code, but i'm somehow stuck.Maybe someone can help me
inv DirectDrawEnumerateEx, OFFSET CallBackFotze, hcombo, DDENUM_NONDISPLAYDEVICES
this is the enumeration function, with the offset to my callback function, the handle of the combo box as lpContext variable and the flag at last. Should be right...
And here's my callback function...it's totally incomplete and just a try...
CallBackFotze PROC lpGUID: GUID, lpDriverDescription:LPSTR, lpDriverName:LPSTR, lpContext:LPVOID
LOCAL lpDevice: LPVOID
inv SendMessage, hcombo, CB_ADDSTRING, 0, offset lpDriverName
.IF eax != LB_ERR
.IF lpGuid == NULL
mov lpDevice, 0
.ELSE
the C++ code for the callback function looks like this:
BOOL WINAPI EnumDDrawDevice (GUID FAR *lpGUID, LPSTR lpDriverDescription, LPSTR lpDriverName, LPVOID lpContext)
( LONG iIndex;
HWND hWnd= (HWND)lpContext
LPVOID lpDevice = NULL;
iIndex = Sendmessage (hWnd, CB_ADDSTRING, 0, (LPARAM)lpDriverDescription ); <---?!?
if (iIndex!= LB_ERR)
{
if (lpGUID= NULL)
{
lpDevice = NULL;
}
else
{
lpDevice = (LPGUID) malloc (sizeof(GUID)); <-- totally lost here
if (!lpDevice) return FALSE;
memcpy (lpDevice, lpGUID, sizeof (GUID));
}
Sendmessage ( hWnd, CB_SETITEMDATA, iIndex, (LPARAM)lpDevice;
}
else
{
return DDENUMRET_CANCEL;
}
return DDENUMRET_OK
}
Is there a soul out there, able to help me ? :)
Thanks
Hehe
We have not used That Callback yet in HE ... we just blindly use the first device we find :(
However we have used othe DirectX callbacks and i can share you a few of my experiences:
The procedure must be reentrant, preserve registers, assume nothing :)
The data sent to you or resented to you by DirectX is just temporary...
That is why you should copy it to another safe place... i guess that is the malloc and copy stuff in C++ code... pointers will be invalidate once you exit from the Callback (sometimes it still works but trust me it is pure luck)
Do not try and add strings/data directly to a combo box ...first just "OutputdebugString" or Value what you get inside the callback ... just to make sure everything is ok
Also you can not ID things just by its strings, think of it: it is possible that 2 drivers have the same string description (more likely to users or 2 computers or 2 printer names but doh ...) so you must ID them by the GUID and that must be copyed as i told you above...
it looks like the string is copied by the combo box in the CB_ADDString message but I (paranoia) whould not assume that...
We have not used That Callback yet in HE ... we just blindly use the first device we find :(
However we have used othe DirectX callbacks and i can share you a few of my experiences:
The procedure must be reentrant, preserve registers, assume nothing :)
The data sent to you or resented to you by DirectX is just temporary...
That is why you should copy it to another safe place... i guess that is the malloc and copy stuff in C++ code... pointers will be invalidate once you exit from the Callback (sometimes it still works but trust me it is pure luck)
Do not try and add strings/data directly to a combo box ...first just "OutputdebugString" or Value what you get inside the callback ... just to make sure everything is ok
Also you can not ID things just by its strings, think of it: it is possible that 2 drivers have the same string description (more likely to users or 2 computers or 2 printer names but doh ...) so you must ID them by the GUID and that must be copyed as i told you above...
it looks like the string is copied by the combo box in the CB_ADDString message but I (paranoia) whould not assume that...
Bogdan,here's a try....the program compiles fine ,but crashes at start up....
(after setcooperativelevel, in my DDInit proc)
mcall , IDirectDraw7_EnumDisplayModes, DDEDM_REFRESHRATES, NULL, NULL, offset Moden
and that's "Moden", my callbackfunction..
Moden PROC proc uses esi lpDDSurfaceDesc2:DWORD, lpContext:DWORD
LOCAL Buffer[90]:BYTE
mov esi,
mov eax,
push eax
mov eax,
push eax
mov eax,
push eax
mov eax,
push eax
lea eax, String
push eax
lea eax, Buffer
call wsprintf
inv SendMessage, hListBox, LB_ADDSTRING, NULL, ADDR Buffer
mov eax, DDENUMRET_OK
ret
Moden ENDP
where String is db "%d%d%d%d",0........and i call the DDInit Procedur while WM_Create,after the List and Combo boxes are made,maybe that's the prob?!?!?!?
(after setcooperativelevel, in my DDInit proc)
mcall , IDirectDraw7_EnumDisplayModes, DDEDM_REFRESHRATES, NULL, NULL, offset Moden
and that's "Moden", my callbackfunction..
Moden PROC proc uses esi lpDDSurfaceDesc2:DWORD, lpContext:DWORD
LOCAL Buffer[90]:BYTE
mov esi,
mov eax,
push eax
mov eax,
push eax
mov eax,
push eax
mov eax,
push eax
lea eax, String
push eax
lea eax, Buffer
call wsprintf
inv SendMessage, hListBox, LB_ADDSTRING, NULL, ADDR Buffer
mov eax, DDENUMRET_OK
ret
Moden ENDP
where String is db "%d%d%d%d",0........and i call the DDInit Procedur while WM_Create,after the List and Combo boxes are made,maybe that's the prob?!?!?!?
Never did it in WM_CREATE myself ... but then again we do not use GDI combo's in HE
Theoretically it should go allright but i somehow recall we had some problems with this in HE...
Why dont you test it just before you start your message loop (in code) this is how we do it in HE
Besides i think you should rebalance the stack after a call to wsprintf (i do no see an invoke there do i ? )
Wsprintf uses a C calling convention ...
Because of its unknown/variable number of parameters and since you know how many parameters you need it is your duty to balance the stack at the end of wsprintf with:
besides didnt i told you to be paranoical? :) never do such "complicated" things inside a callback from the start ... rather place some OutputDebugStringA with some messages like "Layla was here ... " and see what it happens ... :)
Theoretically it should go allright but i somehow recall we had some problems with this in HE...
Why dont you test it just before you start your message loop (in code) this is how we do it in HE
Besides i think you should rebalance the stack after a call to wsprintf (i do no see an invoke there do i ? )
Wsprintf uses a C calling convention ...
Because of its unknown/variable number of parameters and since you know how many parameters you need it is your duty to balance the stack at the end of wsprintf with:
add esp, nr_params*4
besides didnt i told you to be paranoical? :) never do such "complicated" things inside a callback from the start ... rather place some OutputDebugStringA with some messages like "Layla was here ... " and see what it happens ... :)
i figured it out now,there was a problem with the wsprintf function.
mov esi,
inv wsprintf, ADDR Buffer, OFFSET String, ,, \
that's the way it works...
If you wanna test the program,download it ,here's the new version :)
mov esi,
inv wsprintf, ADDR Buffer, OFFSET String, ,, \
that's the way it works...
If you wanna test the program,download it ,here's the new version :)