GWLP_USERDATA & Klasseninstanz: Member haben falsche Werte
-
dot schrieb:
Kann es sein dass dein MyPogressBar Objekt zerstört wird bevor das Fenster zerstört wird?
Ich denke nicht, wie finde ich das im Zweifel heraus?
dot schrieb:
Er setzt seine WndProc erst nach dem Aufruf von SetWindowLongPtr()
Also riecht das Programm es nicht ^^
-
Juppie schrieb:
dot schrieb:
Kann es sein dass dein MyPogressBar Objekt zerstört wird bevor das Fenster zerstört wird?
Ich denke nicht, wie finde ich das im Zweifel heraus?
Wie und wo wird denn das MyProgressBar Objekt erzeugt und wie und wo wird es zerstört?
-
Um große Erklärungen zu sparen, so sieht die WndProc des Programms aus mit dem ich die Klasse teste:
LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { MyProgressBar xbar; switch (message) { case WM_CREATE: if (xbar.createBar (hwnd, 10, 10, 100, 100) == NULL) MessageBox (NULL, "Failed creating bar", "Error", NULL); xbar.setPosition (50, 50); xbar.setSize (300, 20); xbar.setText ("100%"); break; case WM_DESTROY: PostQuitMessage (0); break; default: return DefWindowProc (hwnd, message, wParam, lParam); } return 0; }
LONG_PTR zu nutzen hat im Übrigen leider nichts gebracht ...
Auf jeden Fall schonmal ein Danke für die Mühe .. ^^
-
Habe gerade mal in den Destruktor einfach die Methode destroyBar () mit reingepackt, die widerum DestroyWindow () für das Static aufruft, und siehe da: Die Bar ist einfach weg.
D.h. das Objekt wurde wirklich zerstört, ein einfaches static vor MyProgressBar xbar hat gereicht, ich hoffe das war wirklich das Problem ..
Wenn ja, dann auf jeden Fall ein riesiges Dankeschön, für den richtigen Hinweis, daran wäre ich wieder tagelang verzweifelt und hätte mich danach widerum tagelang geärgert, dass es wieder mal am static hing ^^Ich probier mal weiter rum ..
Danke, Danke, Danke
-
Ähm, dein xbar ist eine lokale Variable in der WindowProcedure
-
Ja das war ja auch der Fehler, hab sie jetzt per static "dauerhaft" verfügbar gemacht
Wie schon gesagt, danke für den richtigen Hinweis, hätte mich wieder tausende Nerven gekostet
-
Juppie schrieb:
Ja das war ja auch der Fehler, hab sie jetzt per static "dauerhaft" verfügbar gemacht
Das funktioniert aber nur solange es exakt ein Fenster dieser Klasse gibt.
Wäre es nicht besser, dieses Fenster in einer Klasse zu kapseln und xbar zu einem Member zu machen!?
-
Ja mag sein .. ich habe mir aber gerade eh schon etwas anderes überlegt ..
Anstatt dafür eine extra Klasse zu machen, bin ich gerade am abwägen ob es nicht generell sinnvoller wäre, eine eigene Fensterklasse zu registrieren und über SendMessage die benötigten Einstellungen treffen zu lassen .. Das ganze könnte man dann auch in eine Dll packen und es wäre (richtig programmiert) reines C, also eher im "Sinne" der WinAPI ..
Praktisch Common-Controls für Arme
Vorteil wäre noch, dass man auch als außenstehender die Bar wie ein Fenster behandlen könnte und nicht immer auf die Klassen-eigenen Methoden und Member zugreifen müsste ..
So als unverbindliche Frage, was gefiele dir (bzw. euch) besser, wenn du (bzw. ihr) jetzt genau meine (natürlich dann fertige) Bar benutzen würde(s)t?
-
Warum machst Du Dir das Leben so schwer ?
Lasse den ganzen OOP-GUI-Kapsel-Quatsch bleiben und mache es mit einer eigenen Fensterklasse.
-
Also wenigstens einer, der das schon mal genau so sieht
Bin grad schon dabei, die ganze Geschichte umzumodelliern ^^
-
Juppie schrieb:
Also wenigstens einer, der das schon mal genau so sieht
Bin grad schon dabei, die ganze Geschichte umzumodelliern ^^Warum soll man das genaus so sehen, wenn dieses "nicht einsetzen" bekannter Bibliotheken einen eigentlich vom wesentlichen abhält, was ein Program tun soll...
Zum swm gibt es genug "fertige" Ansätze, die einfach und erprobt sind...
-
Das ist gerade mein neues Projekt, also eine eigene ProgressBar zu entwickeln, von daher hält es mich zumindest in der Hinsicht von nichts weiter ab ^^
Was bedeutet swm ?