GWLP_USERDATA & Klasseninstanz: Member haben falsche Werte

dot

Kann es sein dass dein MyPogressBar Objekt zerstört wird bevor das Fenster zerstört wird?

Thorgrim schrieb:

Mit
*(MyProgressBar*) GetWindowLongPtr (hwnd, GWLP_USERDATA);
dereferenzierst du mindestens ein Mal (WM_CREATE) einen Nullzeiger, da SetWindowLongPtr erst nach dem Aufruf dieser Nachricht durchgeführt wird.

Er setzt seine WndProc erst nach dem Aufruf von SetWindowLongPtr()

barText war nur eine unsaubere Variante um zu testen, ich nehme dafür ansonsten meine eigene Stringklasse, die ich jetzt aber gerade nicht zur Hand hatte ..

Ich definiere hwndBar in der Klasse als HWND* hwndBar, gebe ihm im Konstruktor eine "feste" Addresse über hwndBar = new HWND und muss dann mit dem Pointer arbeiten, um eben den Inhalt der so zugewiesenen Addresse verändern zu können. Dann gibt die Methode den ganzen Spaß zurück, damit man auch außerhalb der Klasse mit dem Fenster arbeiten kann und jede Änderung von außerhalb auch im Objekt der Klasse ankommt. So hab ich mir das erklärt, programmiert und so gehts auch .. lasse mich aber gern berichtigen bzw. meinen Horizont erweitern wenn ich da irgendwo auf dem Holzweg bin ..

Und das SetWindowLongPtr erst nach dem WM_CREATE aufgerufen wird versteh ich nicht. Ich subclasse das Static doch erst, nachdem ich GWLP_USERDATA mit this belegt habe, also müsste IMO doch auch erst danach die SubclassProcedure aufgerufen werden und zwar bereits mit dem gültigen Zeiger. Das Programm kann doch wohl nicht riechen, dass ich nach der Zuweisung von this in USERDATA das Static subclassen werde und somit schon die SubclassProcedure aufrufen, oder irre ich mich ?

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 ^^

dot

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

dot

Ä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

dot

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.

http://www.catch22.net/tuts/custom-controls

Also wenigstens einer, der das schon mal genau so sieht
Bin grad schon dabei, die ganze Geschichte umzumodelliern ^^

Martin Richter

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 ?

GWLP_USERDATA &amp; Klasseninstanz: Member haben falsche Werte

GWLP_USERDATA & Klasseninstanz: Member haben falsche Werte