DLL bleibt nicht in Nachrichtenschleife hängen

[flenders]

Zur Message-Loop in DllMain:

The entry-point function should perform only simple initialization or termination tasks.

Aber warum du mit PeekMessage Nachrichten bekommst und mit GetMessage nicht, ist auch seltsam

[SirLant]

Das Beispiel aus meinem letzten Posting geht ja soweit, nur bekomm ich eben ununterbrochen WM_PAINT nachrichten, welche aber erst nach beenden des Fensters angezeigt werden. Aber das WM_DESTROY bekommt er nicht mit, da es anscheinend ab dem ersten WM_PAINT hängt.

Die exe und die dll sind beide als multithreaded Programme kompiliert, also daran kann es nicht liegen.

[painter]

Du hast wohl BeginPaint und EndPaint vergessen, oder lass DefWindowProc das Regeln. :p

[Windowsprogger]

int APIENTRY DllMain (HINSTANCE hinst, DWORD fdwReason, PVOID pvReserved)
{
    switch (fdwReason)
    {
        case DLL_PROCESS_ATTACH:
            _beginthread (Thread, 0,  hinst);
            break;
        case DLL_PROCESS_DETACH:
            _endthread ();
            break;
    }
    return TRUE;
}

Bad idea. You should have a dedicated initialization function in the DLL
that creates the thread and the dialog. You should only perform simple
initializations in DllMain, read the documentation on DllMain.

[SirLant]

painter schrieb:

Du hast wohl BeginPaint und EndPaint vergessen, oder lass DefWindowProc das Regeln. :p

Wow das klappt ja damit wirklich
hab nicht gewusst, dass man in WM_PAINT "zwangsweise" beginpaint und endpaint benutzen muss

Danke

[SirLant]

Windowsprogger schrieb:

int APIENTRY DllMain (HINSTANCE hinst, DWORD fdwReason, PVOID pvReserved)
{
    switch (fdwReason)
    {
        case DLL_PROCESS_ATTACH:
            _beginthread (Thread, 0,  hinst);
            break;
        case DLL_PROCESS_DETACH:
            _endthread ();
            break;
    }
    return TRUE;
}

Bad idea. You should have a dedicated initialization function in the DLL
that creates the thread and the dialog. You should only perform simple
initializations in DllMain, read the documentation on DllMain.

Where else should I create the thread when I don't want to export a function for creating the thread und dialog.
The only thing would be an asynchronous function which creates them else it would be the same thing only that DllMain
calls another function which takes the same amount of time to initialize them.

[Windowsprogger]

Where else should I create the thread when I don't want to export a function for creating the thread und dialog.

Ok, if you don't want to export a seperate function, live with your dirty design.

[SirLant]

Windowsprogger schrieb:

Where else should I create the thread when I don't want to export a function for creating the thread und dialog.

Ok, if you don't want to export a seperate function, live with your dirty design.

It seems that I dont have the choide cause I've just discovered, that directly after the DLL_PROCESS_ATTACH call I get a DLL_PROCESS_DETACH call which destroys the thread and causes some trouble in my program (I get new DLL_PROCESS_ATTACH calls, but normally there should be only one).

[flenders]

Vielleicht hängt es damit zusammen:

When a DLL is unloaded from a process as a result of an unsuccessful load of the DLL, termination of the process, or a call to FreeLibrary, the system does not call the DLL's entry-point function with the DLL_THREAD_DETACH value for the individual threads of the process. The DLL is only sent a DLL_PROCESS_DETACH notification.

[SirLant]

Gut möglich, aber durch die exportierte Funktion welche jetzt den Thread erzeugt läuft es super

Wieso kann ich eine exportierte Funktion die so aussieht EXPORT bool CALLBACK initialize (); nicht mit bool (CALLBACK *init_ptr)() laden?
Bekomme, dann immer nen NULL Handle von GetProcAdress, wenn ich statt __stdcall __cdecl, also einfach nix dazu schreibe, benutze geht es