UNd wieder dieses verwirrende VC++??

[Saturo]

Hallo Leute!

Heute habe ich mal wieder ein Problem fuer euch .

Das ist mir schon öfters passiert, ich habe aber nie rausgefunden, woran es liegt.

Ich habe eine Klasse erstellt.(zu einem Dialog). In dieser Klasse gibt es eine Membervariable m_Text, die auf das Eingabefeld zugreifen soll.Ob diese nun CEdit oder CString ist, spielt keine Rolle für später .

Mein Problem...wenn ich nun auf diese Klasse zugreife, zB so: Klasse.m_Text , so läuft alles Prima. Wenn ich jedoch jetzt eine Funktion von m_Text aufrufen will, zb:

Klasse.m_Text.GetWindowText(buffer) , so kompiliert er es Problemlos, aber im Programm kommt ein komischer Ausnahmefehler. Das komische: Wenn ich Klasse. schreibe, dann schlägt mir VC++ ja ein paar Funktionen vor...wenn ich schreibe: "m_Text." passiert das nun nichtmehr!

Hat einer schonmal damit erfahrungen gemacht? Ich komme einfach nicht drauf .

[Crush]

Also bei mir funktioniert alles, was Du beschreibst, was nicht gehen soll. Ich kann mich erinnern, daß das Intellisense bei extremen Source-Änderungen mal irgendwas "verschlafen" kann und dann stimmen die .opt, .ncb, .bsc & .pdb Dateien nicht mehr so richtig. Das kann passieren, wenn man das inkrementelle Binden ausgeschaltet hat (falls der Fehler nur im Release auftritt). Vor allem wenn man zuerst die Hs und dann im Nachhinein die cpps ändert sollen solche Fehler auftreten können. Mir persönlich ist das nur 1-2 mal innerhalb der letzten 3 Jahre passiert. Da hilft dann nur eines (wenn es das auch sein sollte): Die 4 Dateien löschen und "alles neu erstellen" lassen. Sollte der Fehler dann immer noch nicht behoben sein, dann wäre es auch möglich, daß Du evtl. private oder protected abgeleitet hast, was solche Fehler (vielleicht) auch erklären könnte hinsichtlich des Intellisense, weil man da ja über Referenzen nicht direkt von außen Zugreifen darf (Keine Zeigerzugriffe, Keine Referenzzugriffe, nur Direktzugriff über das Objekt selbst).

Was für eine Fehlermeldung bekommst Du denn genau? Hast Du das neueste Update für VC drauf, welches diesen Bug einigermaßen ausmerzen sollte?

Versuche vielleicht auch ein wenig an den Compiler-Optionen rumzuschrauben. Das kann manchmal auch noch helfen.

<FONT COLOR="#a62a2a" SIZE="1">[ 03. November 2001 16:40: Beitrag 2 mal editiert, zuletzt von Crush ]</font>

[Saturo]

ja, irgendwie muss es wohl ein bug sein..komisch.

Ich mache es jetzt so:

in der klasse:

CString Data;

CEdit m_Text;

m_Text.GetWindowText(Data);

ausserhalb: Klasse.Data <---- jetzt geht es....

Klasse.m_Text.GEtWindowText(buffer); geht nicht...argh.

ABER!!!!::::

KLasse.Data=xxxx

m_Text.SetWindowText(Data) geht nicht!!! uaaah! *heul*

der Fehler: Debug Assertion Failed!

File: Winocc.cpp

Ich werde es jetzt doch mal mit einem Patch probieren.

cu erstmal

[Saturo]

hm, in der Releaseversion kommt es nicht vor...der Debugger schließt die Anwendung anscheinend mit Code 3 wegen diverser "Memory leaks"....au waia

[Crush]

Schon mal im Tracer alles durchgelaufen? In solchen Fällen schnippel ich auch gern mal die Elemente auseinander um genau beobachten zu können.

Ganz oben in der APP das hier definieren: Dadurch werden Zusatzinformationen bei Speicheranforderungen geloggt und bei Fehlern mitausgegeben. So können bei Speicherfehlern die Auslöser lokalisiert werden.

#define NEW DEBUG_NEW

aus Klasse.m_Text.GetWindowText(buffer);

mach ich dann:

CEdit&membervar=Klasse.m_Text;

ASSERT(membervar);

ASSERT(membervar.GetWindowText(buffer));

Im Debugger kann man beim Einzelschritt alles genau erkennen. Bei Release-Built wird der Debug_new und er Assert automatisch eliminiert und Fehlinitialisierungen werden im Log genauer erläutert.

Du könntest auch try-catch-Blöcke um die Gesamtfunktion aufbauen, denn dann ist es einfacher komplexere Fehlerquellen mit genauem Fehlercode zu interpretieren.

Compiler-Option /GX und /EHs aktivieren!

[Saturo]

ASSERT(::IsWindow(m_hWnd)); .....da tritt der Fehler auf...

void CWnd::SetWindowText(LPCTSTR lpszString)

{

ASSERT(::IsWindow(m_hWnd));

if (m_pCtrlSite == NULL)

::SetWindowText(m_hWnd, lpszString);

else

m_pCtrlSite->SetWindowText(lpszString);

}

so sieht das ganze komplett in der MFC aus...

das sagt mir echt null, denn mit dem Debugger habe ich mich noch wenig auseinandergesetzt.

erstmal drueber schlafen

cu

[Saturo]

eines muss ich noch dazusagen:

Es handelt sich bei dem Programm um ein Registerkartenprogramm...dh. diese Klasse (klasse.m_text) bildet eine Karte dieses Registers. Aus den Registerkarten rauszulesen klappt, wie oben schon erwaehnt. Wenn ich aus dem Getwindowtext ein Setwindowtext mache(an selber Stelle), dann errort es . Man kann doch in Registerkarten schreiben, oder? *bet*

[Saturo]

LOL NEIN...seitdem ich das mit dem umaendern ausprobiert habe, klappt das rauslesen auch nicht mehr...vorher ging es. Naja, wie war das mit dem Visual Basic nochmal?

[Crush]

Sich mit dem Debugger zu beschäftigen verpassen viele Newbies, aber ohne den wird man früher oder später nicht mehr leben können. Es ist sogar ratsam sich ein kleines bissel auf ASM zu konzentrieren, damit man mit dem Speichermonitor auch was anfangen kann - das hilft sehr oft bei Problemfindungen.

ASSERT(::IsWindow(m_hWnd)); .....da tritt der Fehler auf...

void CWnd::SetWindowText(LPCTSTR lpszString)

{

ASSERT(::IsWindow(m_hWnd));

if (m_pCtrlSite == NULL)

::SetWindowText(m_hWnd, lpszString);

else

m_pCtrlSite->SetWindowText(lpszString);

}

Ist doch ganz klar, was los ist: IsWindow frägt ab, ob ein Fenster überhaupt existiert 0=nein.

Entweder hast Du kein Window aus dem Dialogobjekt erstellt: z.B. CDialogclass DialogWindow; oder halt mit new oder sonstwie (z.B. als Member in der App-Klasse) oder Du hast den Windowhandle falsch initialisiert/ausgelesen.

Nehmen wir an Du hast ein illegales Fenster geöffnet mit negativem RECT (Rechteckbereich des Fensters), dann klappt das nicht und Dir wird ein 0er-Handle zurückgegeben, weil das Erstellen des Fenster nicht funktioniert hat. Das denke ich wird hier jedoch nicht der Fall sein.

Es könnte natürlich auch sein, daß Du den Handle anderweitig verfremdet hast. Angenommen er ist nicht als global in dem Bereich definiert in dem der obige Programmcode liegt, wird nicht per value zurückgegeben, sondern in einem eigenen Namespace {} drin, vielleicht in einer anderen CPP und dann noch nicht mal als static und wird dann per Referenz weitergegeben, dann ist der Handle nur für eine Mikrosekunde vorhanden und sobald die }-Klammer erreicht wird wird der Stack aufgeräumt, der Handle vernichtet und der Inhalt mit dem nächsten Funktionsaufruf überschrieben/gelöscht. Das würde auch zum selben Ergebnis führen. Static kann die Problemlösung für viele 0er-Handles sein!

Versuch mal zu schauen, was passiert, wenn Dein Fenster erstellt wird.

Letzteres war bei mir das erste mal das Problem (werd ich nie vergessen), als ich einen kompletten Dialog mal mit einer Resize()-Funktion versehen wollte, damit bei jeder Fenster-Größe die Größenverhältnisse auch gleich bleiben. Die haben aber fast schon zufallszahlenartige Größen angenommen beim Resizen, weil eben der Static an der richtigen Stelle gefehlt hatte und daher willkürlich Größenwerte aus dem Speicher gelesen wurden!

[Saturo]

Mensch,erschreck mich doch nicht so! Wenn ich Handles höre, bekomme ich schon Ohrensausen...uaahh.

Aber ich habe das Problem gefunden! Sowas dummes passiert mir nicht nochmal!

Also:

Dialog wurde erstellt:

CDialog Dialog;

Dialog.domodal();

fertig.....und meine Funktionen zum Schreiben habe ich im Konstruktor untergebracht. Das war der fehler, weil die Objekte am Konstruktor ja noch sozusagen aufgebaut werden.

Als 2. Variante hatte ich mir eingebrockt, die SetW.... in die Funktion OnkillActive zu stecken...auch eine Dummheit, weil das Objekt ja schon nicht mehr angezeigt wird...daher also der Debugfehler. argh!!!!!! Ich habe die SetWindowtext funktion nun in der Funktion OngetActive(oder so aehnlich) eingebunden. Jetzt geht es...man, ich dachte, ich gebe irgendwas falsch ein, oder habe ein Memoryproblem, dabei rufe ich die Funktion bloss zur falschen Zeit auf! *OMG*

Jedenfalls danke nochmal für die Romane, die du mir immer als Antwort geschrieben hast . Ich glaube ich bin in Sachen Dialogen erstmal über den Berg.

Ciao!