Fensterklasse mit Get-/SetWindowLong: Zugriff innerhalb der WndProc?

if(wnd)
{
    return wnd->wndProc(hWnd,uMsg,wParam,lParam);
}
else
{
    return DefWindowProc(hWnd,uMsg,wParam,lParam);
}

don_basto schrieb:

Das Problem liegt beim Speichern des Zeigers:
Window* wnd = (Window*)(((LPCREATESTRUCT)lParam)->lpCreateParams);
wnd ist danach 0.

Wie sieht dein CreateWindow Aufruf aus?

don_basto

Das war's.
Hab's auch gerade rausgefunden... .

CodeFinder

don_basto schrieb:

Das war's.
Hab's auch gerade rausgefunden... .

Huh?!, was wars denn jetzt ? Du hast doch vorher schon geschrieben, dass dein Problem gelößt sei... *iritiert sei*

Badestrand

CodeFinder schrieb:

don_basto schrieb:

Das war's.
Hab's auch gerade rausgefunden... .

Huh?!, was wars denn jetzt ? Du hast doch vorher schon geschrieben, dass dein Problem gelößt sei... *iritiert sei*

Jo, Problem scheint gelöst zu sein, hat wohl vergessen bei CreateWindow this als Param zu parsen^^ Das hat der Poster mit den 11 Fragezeichen wohl übersehen

don_basto

Ich hat den This-Zeiger bei CreateWindow() nicht mitgegeben. Nachdem ich den Fehler gefunden hatte und dann hier meinen alten Beitrag editiert, kam der ????-Beitrag zum CreateWindow().

Badestrand

Wegen mir aus hättest du auch nen Doppel-Post machen können, dann sieht man immerhin, dass du noch was geschrieben hast Sonst übersieht man sowas so leicht^^

CodeFinder

Ahso, ok ok, so hatte ich's auch verstanden; war nur iritiert wg. dem Post von '???????????' .

hustbaer

Das "if(!wnd) dann DefaultWndProc" solltest du auf jeden Fall drinnen haben, sonst wird u.U. erst wieder 0 als this verwendet, nämlich bevor die WM_CREATE gekommen ist. Was zwar normal funktioniert solange man nicht über "this" zugreift (siehe GetSafeHwnd - *würg*), aber zumindest gefährlich ist (z.B. wenn man mal den Code ändert), und ich denke (bin aber nicht sicher) dass es auch laut C++ Std. nicht OK ist.

CodeFinder

hustbaer schrieb:

Das "if(!wnd) dann DefaultWndProc" solltest du auf jeden Fall drinnen haben, sonst wird u.U. erst wieder 0 als this verwendet, nämlich bevor die WM_CREATE gekommen ist.

Jo das seh ich auch so .

hustbaer schrieb:

aber zumindest gefährlich ist (z.B. wenn man mal den Code ändert),

Was sollte man denn am Code ändern, so dass es 'gefährlich' wird ? ( konkret ? )

hustbaer schrieb:

und ich denke (bin aber nicht sicher) dass es auch laut C++ Std. nicht OK ist.

Was soll nicht dem C++-Standard entsprechen ?

CStoll

CodeFinder schrieb:

hustbaer schrieb:

und ich denke (bin aber nicht sicher) dass es auch laut C++ Std. nicht OK ist.

Was soll nicht dem C++-Standard entsprechen ?

Afaik gehört es in den Bereich "undefiniertes Verhalten", wenn du eine Klassenmethode über den NULL-Zeiger aufrufen willst.

CodeFinder

CStoll schrieb:

CodeFinder schrieb:

hustbaer schrieb:

und ich denke (bin aber nicht sicher) dass es auch laut C++ Std. nicht OK ist.

Was soll nicht dem C++-Standard entsprechen ?

Afaik gehört es in den Bereich "undefiniertes Verhalten", wenn du eine Klassenmethode über den NULL-Zeiger aufrufen willst.

ACh das meinte er damit, ja klar, das wird krachen .

hustbaer

@CodeFinder: es kracht eben mit vielen Compilern nicht solange "this" in der Funktion nicht dereferenziert wird, also kein Zugriff auf non-static Member. Dazu darf die Funktion natürlich auch nicht virtual sein.
Und das meinte ich auf mit "gefährlich", also einen 0 "this" Pointer zu "übergeben" bloss weils gut geht. Wenn man dann später mal den Code ändert so dass für jede Message irgendwelche Member angegriffen werden... *boom*

phlipsi

Ist das eigentlich der Standardweg, dieses klassische C++-WinAPI-Problem zu lösen? Oder gibt es da eine Reihe von anderen Möglichkeiten? Wenn ja, welche? Und wo kann man sich informieren?