Sam Lantinga schrieb:
You’ll need to call SDL_RegisterApp() from your Delphi application.
Actually, as I look over the code this may no longer be necessary.
I’ll let you know if SDL 1.1.3 will remove this restriction.
Okay, I added a quick fix. Let me know if this works:
http://www.devolution.com/~slouken/SDL/cvs/Delphi-SDL.dll
[Disclaimer]
This is a current PRERELEASE binary of SDL 1.1.3 - it may contain bugs.
it doesn’t work. the application crashes when I call SDL_Init. but maybe
the parameter types have changed. I only got the source of SDL1.0… are
there any changes in the interface of SDL_Init ?
I also tried to call sdl_registerapp before sdl_init (with the old dll) but
nothing changes (“couldn’t create window”). I haven’t found documentation
to the SDL_RegisterApp function, so I guessed what the parameters meant:
name=title of application (taskbar), style=windows windowstyle (used by
CreateWindow (?)). there is this void hInst left, which I think is a bit
confusing: if this should be the Instance-Handle of the Application, why is
it a pointer?? (or does "" not mean, that its a pointer in C?)
so long,
tom.–
das leben ist wie ein eis. du mu?t es aufessen sonst ist es weg.
it doesn’t work. the application crashes when I call SDL_Init. but maybe
the parameter types have changed. I only got the source of SDL1.0… are
there any changes in the interface of SDL_Init ?
SDL 1.1 and 1.0 are not binary compatible.
I also tried to call sdl_registerapp before sdl_init (with the old dll) but
nothing changes (“couldn’t create window”). I haven’t found documentation
to the SDL_RegisterApp function, so I guessed what the parameters meant:
name=title of application (taskbar), style=windows windowstyle (used by
CreateWindow (?)).
That’s correct.
there is this void *hInst left, which I think is a bit
confusing: if this should be the Instance-Handle of the Application, why is
it a pointer??
A handle is a void pointer. I don’t use HINSTANCE because it can be called
from code that doesn’t include windows.h
Hmm, I found the problem. You can’t do GetModuleHandle(NULL) from a DLL
to get the main application instance handle. Any ideas anyone?
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Hmm, I found the problem. You can’t do GetModuleHandle(NULL) from a DLL
to get the main application instance handle. Any ideas anyone?
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Catch and store the app instance handle in LibMain.
Sam Lantinga wrote:
Hmm, I found the problem. You can’t do GetModuleHandle(NULL) from a DLL
to get the main application instance handle. Any ideas anyone?
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Catch and store the app instance handle in LibMain.
I already do. The question was “without using SDLmain (Delphi)” can I
use SDL?"
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Sam Lantinga wrote:
Hmm, I found the problem. You can’t do GetModuleHandle(NULL) from a DLL
to get the main application instance handle. Any ideas anyone?
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Catch and store the app instance handle in LibMain.
I already do. The question was “without using SDLmain (Delphi)” can I
use SDL?"
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Oops. My mistake. I meant “dll_entry”. When windows loads a DLL, it
calls
that function, and passes it a few args, one of which is the app
instance
handle. I used grep to search all the C files in my checkout of SDL CVS,
and dll_entry is not defined anywhere. It looks something like this:==================================
static HANDLE hInstance;
int WINAPI dll_entry(HANDLE h, DWORD reason, void *ptr)
{
switch (reason)
{
case DLL_PROCESS_ATTACH:
hInstance = h;
printf(“DLL Process attach\n”);
break;
case DLL_PROCESS_DETACH:
printf(“DLL Process detach\n”);
break;
case DLL_THREAD_ATTACH:
printf(“DLL Thread attach\n”);
break;
case DLL_THREAD_DETACH:
printf(“DLL Thread detach\n”);
break;
}
return 1;
}
Oops. My mistake. I meant “dll_entry”. When windows loads a DLL, it
calls
that function, and passes it a few args, one of which is the app
instance
handle.
I found it. It actually is passed the DLL instance handle, not the app
instance handle:
BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to the DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpvReserved // reserved
);
Parameters:
hinstDLL
[in] Handle to the DLL module. The value is the base address of the DLL.
The HINSTANCE of a DLL is the same as the HMODULE of the DLL, so hinstDLL
can be used in calls to functions that require a module handle.
Thanks though!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
Sam Lantinga wrote:
Oops. My mistake. I meant “dll_entry”. When windows loads a DLL, it
calls
that function, and passes it a few args, one of which is the app
instance
handle.
I found it. It actually is passed the DLL instance handle, not the app
instance handle:
BOOL WINAPI DllMain(
HINSTANCE hinstDLL, // handle to the DLL module
DWORD fdwReason, // reason for calling function
LPVOID lpvReserved // reserved
);
Parameters:
hinstDLL
[in] Handle to the DLL module. The value is the base address of the DLL.
The HINSTANCE of a DLL is the same as the HMODULE of the DLL, so hinstDLL
can be used in calls to functions that require a module handle.
Thanks though!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
DLLTOOL/DLLWRAP from the mingw32 dist allow you to change the
name of the “entry” function. The default was dll_entry in one of my
older projects (the one I looked this up in). But I think other tools
have other defaults. I remember seeing “LibMain” somewhere in the
labyrinth of MSSDK docs…