Kampfkartoffel

Hallo Klotzkopp, ich habe nun eine WM_CREATE-Message mitreingenommen, die er auch anspricht. Die nächste Windows-Message,die er bearbeiten müsste, wäre die Show_Window, nach der Beendigung von WM_CREATE, führt er mich jedoch zu diesem Fehlerbereich: _AFXWIN_INLINE CWnd* CWnd::GetParent() const { ASSERT(::IsWindow(m_hWnd)); return CWnd::FromHandle(::GetParent(m_hWnd)); } Was ich komisch finde, ist, dass das Programm bei VS2003 so läuft. Aber hilft ja nix Edit: Auf dem Dialog sind Buttons und Editfelder Gruß KK

Hallo bogpoint, naja, wenn ich das Programm kompiliere, spuckt er keinen Fehler aus. Darüber hinaus über gibt er alle Werte, die ich an die Suchklasse über die Instanz vergebe korrekt raus. Ich habe sie mir über MessageBoxes anzeigen lassen. Er springt nur nicht in den Dialog. Ich habe keine Ahnung, wie ich nun vorgehen soll Gruß KK

Hallo an Alle, mein Programm überspringt im Code-Durchgang DoModal Anweisungen. Er gibt mir bis zur DoModal-Anweisung alle übergebenen Werte korrekt raus. Er springt aber nicht in den Dialog, sondern überspringt ihn einfach und macht in der nächsten Zeile weiter. Das Programm habe ich in VS2003 geschrieben und da lief es einwandfrei, nun in VS2005 habe ich Probleme. Kann mir einer sagen, woran der Übersprung liegen kann? Edit: Auch als ich versuchte mir über eine MessageBox, das Ergebnis der DoModal-Funktion ausgeben zu lassen, übersprang er diese Anweisung einfach. Mit Gruß und Dank KK

Mein Problem hat sich erledigt. Der Fehler lag darin, das die Pfad.ini zwar in dem Debug-Verzeichnis lag, aber nicht in dem Release-Verzeichnis. Ich habe mir zunächst eine MessageBox ausgeben lassen, die mir noch einmal einträgt, mit welchem String (sTemp) die Datei geöffnet werden soll. Der String passte und war fehlerlos. Dann habe ich das Datei-Öffnen so abgefangen, dass ich fragte ob es NULL sei. Dem war so. Als ich dann wie gesagt ins Release-Verzeichnis ging, stellte ich fest, dass keine Pfad.ini da war. Seit ich eine erstellt habe, läuft auch die Release-Version anstandslos. War jetzt wahrscheinlich ein dämlicher Fehler, der mich jedoch bezüglich der Aufmerksamkeit von Fehlerquellenabfragungen weitergebracht hat. Dank Dir Klotzkopp Gruß KK

Hallo Klotzkopp, danke für Deine Antwort, sich die Einzelschritte über MessageBoxen ausgeben zu lassen ist eine gute Idee. Ich dachte, dass die Release-Version die Befehle gleich abarbeitet, wie die Debug-Version, werde dass aber offenkundig doch überprüfen müssen. Es wäre nett, wenn Du mir noch mitteilen könntest, wie man z.B. Fehler bei fsopen abfangen kann. Schreibt man eine Assert-Anweisung, bzw. try-, Catch-Anweisung oder wie geht man vor? Gruß KK

-- Visual Studio 2005 / Programm in C++ -- Hallo an Alle, ich habe zur Zeit folgendes Problem, ich habe ein Programm, dass im Debug-Modus einwandfrei läuft, aber im Release-Modus sofort einen Fehler ausspuckt. Mein Code: int Cursor=0; sTemp=""; sTemp=GetCommandLine(); // Eigenpfad bestimmen Cursor=sTemp.ReverseFind('\\'); //Zeichen bis zur Exe-Datei bestimmen sTemp=sTemp.Mid(0,Cursor+1); // Exe-Datei rausschneiden, so dass nur der // reine Pfad übrig bleibt SetInipfad(sTemp.Mid(1,Cursor)); // Pfadadresse speichern sTemp=GetInipfad()+"Pfad.ini"; // Dateipfad erzeugen stream_r1=_fsopen(sTemp,"r",_SH_DENYWR); // Dateipfad öffnen fgets(cTemp,290,stream_r1); // Auslesen der ersten Zeile in der Datei In der Release-Version bekomme ich im fgets-Schritt die Fehlermeldung, dass Microsoft Visual Studio C Runtime Library in der Exe-Datei einen fatalen Fehler entdeckt hat und ich debuggen soll. Aber in der reinen Debug-Version läuft das Programm ohne Probleme und führt die Anweisungen korrekt aus. Zur Info: char cTemp[300]; Kann mir jemand auf die Sprünge helfen? Mit Dank im voraus KK

Hat sich erledigt. Wie immer saß das eigentliche Problem vorm Pc :floet:

Ach ja, ich vergaß zu erwähnen, dass ich im VS 2005 in C++ programmiere! Nur zur Info

Hallo an Alle, ich habe ein Programm im VS 2003 geschrieben und wollte das nun auf VS 2005 adaptieren. Dies muss geschehen, da einige Fehler im Programm auftauchten und mittlerweile auf VS2005 umgestiegen wurde. Ich habe nun das Problem, dass mein Programm in VS2005 gar nicht erst startet. Ich habe alle "alten" Befehle auf den neuen Stand gebracht, (wie z.B. statt sprintf, sprintf_s usw.) und beim Kompilieren auch keine Fehler mehr. Mein Programm läuft unter 2003 bis auf die kleinen Randfehler reibungsfrei. Ich wollte nun mal fragen, ob andere Leute, die von 2003 auf 2005 umgestiegen sind, dieselben Probleme hatten und ob Sie ein gutes Buch empfehlen können. Zum Beispiel werden bei mir Dialoge über ----.DoModal() gar nicht mehr aufgrufen und geben direkt -1 zurück, obwohl sie bei VS 2003 genau so aufgerufen werden und laufen. Wenn ich den Dialog-Instanzen jedoch Werte übergebe ist das fehlerlos möglich. Wäre für eine Auskunft dankbar Gruß KK

Ich denke doch mal, davor müsste der VorDialog also die Page, die davor im "Show"-Modus war auf dem Stack liegen und danach, die Page, die man danach auswählt. Das können aber immer andere sein, ich habe ja keine Wizard-Struktur.

Ich habe die Sache ein wenig modifiziert, wenn Du erlaubst. Denn Str_W_End steht in meiner Datenklasse, auf die alle Pages Zugriff haben und in der alle Daten gespeichert werden. Die Str_W_End-Funktion wird also von jeder Page benutzt. Da es auf den anderen Pages auch Bereiche gibt, die mehr als 80 Zeichen haben können, habe ich also aus 'laenge >80' 'laenge >195' gemacht. Damit wurden dann alle Funktionsbenutzungen vom gesamten Programm überprüft und es tauchte kein "Hoppla" auf.

Die längste Zeichenfolge in der Datei hat 43 Zeichen. Die Zeichenfolgen können auch bei Erweiterung aufgrund der Werte aber niemals über 80 Zeichen kommen. Das würde ich als geprüft ansehen. Jetzt mal anders gefragt: Wie kann ein Array über seinen Bereich hinaus beschrieben werden, wenn es 199 char-Werte aufnehmen kann und immer nur 190 zugewiesen bekommt? Ich habe noch ein CList-Objekt. Da ich dieses aber nicht dazu zähle, da es sich selbst verwaltet, habe ich keine weiteren Arrays mehr.

Hallo phax, Wie gesagt, die Datei schreibe ich selber, so dass hinter dem Namen, mit dem ich meine ComboBox befülle immer ein Komma steht, das gibt mir auch mein Debugger aus. Er befüllt darüber hinaus die ComboBox mit den richtigen Namen. Bei einem eingelesenen Char-Feld ist das letzte Zeichen, wenn die Zeichenfolge kürzer als die eingelesenen Zeichen war, immer das End-of-Line-Zeichen. Da dieser Fall bei mir immer eintritt, sehe ich dort keine Probleme. Wenn diese Funktion nicht korrekt arbeiten würde, würde es mir zeimlich schnell auffallen.

Da ich die Datei, die eingelesen wird, selber schreibe, sehe ich ja wieviele Zeichen pro String ich erhalte. Wenn es 50 sind, ist das viel. Kann man so sehen, muss man aber nicht. Ich habe dieses nicht zu den Feldern gezählt, weil es cTemp[200] ist und immer nur mit 190 befüllt wird. Wo soll da ein Fehler liegen? Darüber hinaus ist mir wohl nicht daran gelegen, den Leuten, die mir helfen möchten ans Bein zu pinkeln. meine andere Funktion: String Str_W_End(char cTemp[]) { int laenge; CString String; laenge=strlen(cTemp); String=CString(cTemp,laenge-1); return String; }

Natürlich ist cTemp ein Array, aber cTemp ist so groß, dass es nur Überladen werden würde, wenn der String mehr als 199 Zeichen hätte und das hat er nicht mal im Ansatz. Ich habe cTemp extra so groß gewählt, damit ich diese Fehler ausschließen kann. PS: Zumal ich cTemp ja mitteile, wieviel Zeichen es einlesen soll. Gruß KK

Code meiner Funktion: int Cursor; sTemp=pDaten->GetDateiPfad()+"ComboHauptRadialLager.vorg"; stream_r_Vorgabe=fopen(sTemp,"r"); fgets(cTemp,190,stream_r_Vorgabe); while(!feof(stream_r_Vorgabe)) { sTemp=pDaten->Str_W_End(cTemp); //Löscht \n-Zeichen Cursor=sTemp.Find(',',0); sTemp=sTemp.Mid(0,Cursor); ComboHaRaLager.AddString(sTemp); ListHaRaLager.AddTail(sTemp); fgets(cTemp,190,stream_r_Vorgabe); } Zur Erklärung: in der Datei stehen Lagernamen, sowie deren Werte, alles durch Komma getrennt. Die Werte werden bei Auswahl des Lagers aus der ComboBox in Felder des Dialogs eingetragen. Daher suche ich im String jeweils nach den Kommas.

Ja, ich lese aus einer Datei Werte aus, die in eine Liste und eine ComboBox übertragen werden

Ja, das leuchtet mir ein, da sich der Fehler den, ich hatte (habe), ja auch erst jetzt bemerkbar gemacht hat. Allerdings habe ich im gesamten Dialog keine Felder, sondern nur normale Variablen. Mir ist nicht klar, wie ich mit Variablen falschen Speicher beschreiben kann. Es ist ja nicht so, dass ich die Variablen im Speicher komplett selber anlege. Gruß KK

Habe nun herausbekommen, dass es an meiner FILE-Variablen lag. Ich habe in einer Funktion einen Stream erzeugt, der offenkundig das Problem vertursachte. Ist es problematisch einen Stream innerhalb einer Funktion zu deklarieren? Auf jeden Fall danke für Deinen Hinweis Klotzkopp. Gruß KK

Hallo Klotzkopp, danke für die schnelle Antwort. Kann ich aufgrund der Fehlermeldung davon ausgehen, dass sich der Fehler auf den Dialog3 beschränkt, oder interpretiert der Debugger nur die Symptome, so dass er eine Fehlermeldung raushaut, die die möglichen Symptome beschreibt, aber nicht die Ursache? Gruß KK

Hallo an Alle, ich habe zur Zeit ein Fehler, bei dem ich nicht recht weiterkomme. Ich habe eine PropertySheet-Struktur, deren Pages verschiedene Dialoge sind. So weit, so gut. Wenn ich nun in einem Dialog (Dialog 3) aber weitere Variablen deklariere, startet das Programm ohne Probleme. Beim Beenden jedoch, kommt folgende Fehlermeldung: und der Debugger beendet sich nicht. Dabei ist es egal, ob ich Variablen oder Pointer anlege. Im Klartext, wenn ich zu meinem jetzigem Dialog auch nur eine Variable dazu anlege, kommt diese Fehlermeldung. Beim Belassen des Dialogs in seinem Grundzustand, kann ich keine Fehler feststellen. Ich kann mir nicht vorstellen, dass der Stack keinen freien Speicher mehr hat. Hat jemand einen Tip? Gruß KK

Danke Klotzkopp, dann werde ich mir noch mal den Feld_laden -Teil angucken, dort scheint der Fehler zu sein.

Hallo Klotzkopp, Das ist ja kein Problem: "Debug Error ... DAMAGE: after Normalblock(#57207) at 0x01800040" Hier noch ein bisschen Code: long *VirtNodeFeld= new long [Feldindex]; if((VirtNodeFeld)) { for(int i=0; i<Feldindex; i++) VirtNodeFeld[i]=0; //Nullen des Feldes Feld_laden(VirtNodeFeld); // Wird an das Programm übergeben ... delete []VirtNodeFeld; } Zur Erläuterung: das Feld VirtNodeFeld wird über eine for-schleife die deutlich kleiner ist als Feldindex teilweise bestückt. Und das Feld wird auch nur bis Feldindex angesprochen. Gruß KK

Hallo an Alle, ich habe in einer Unterfunktion, also einer Funktion, die von einer anderen aufgerufen wird ein Array mit new erzeugt. Als ich dann am Ende der Unterfunktion das Array mit delete wieder löschen wollte, hat er mir einen dicken Fehler ausgegeben. Ließ ich dieses delete weg hat er sauber kompiliert und das Programm auch einwandfrei ausgeführt. Was ich komisch finde ist, dass wenn ich das delete des dynamischen Arrays, welches ich in der Funktion, die die Unterfunktion aufruft, weglasse, dann beendet er das Programm nicht sauber. Der Debugger bleibt wieterhin aktiv. Ich habe also in einer Funktion und in der Unterfunktion je ein dynamisches Array erzeugt und darf nur das Array der "Über"Funktion deleten. Das kommt mir irgendwie spanisch vor, denn es steht doch überall, dass man "new" erzeugte Variablen oder Felder auch wieder "deleten" muss. Kann das irgendjemand erklären? PS: Es geht mir nur erstmal darum, zu erfahren, ob und wenn ja, warum das möglich ist. Sollte es nicht möglich oder falsch programmiert sein (wovon ich ausgehe), werde ich Code posten Gruß KK

Danke für Deine Antwort Klotzkopp, ich denke damit komme ich klar.