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