Klotzkopp

Nein, das ist der Code, mit der Markierung, an welcher Stelle die Assertion fehlgeschlagen ist. Soweit waren wir schon. Um festzustellen, wo der Aufruf mit dem ungültigen Index herkommt, brauchen wir die Aufrufliste (Callstack), das ist ein eigenes Fenster im Debugger, das du möglicherweise zuerst einblenden musst.

Diese Information wäre schon wichtig...

Das ist kein Fehler und hat auch nichts mit dem Problem zu tun. Starte das Programm mit dem Debugger (F5), und wenn die Assertion fehlschlägt, klick auf Wiederholen. Schreib dann hier rein, was in der Aufrufliste (Callstack) steht.

Das ist ein sehr aussagekräftiger Fehler. Du weißt ihn nur nicht richtig zu lesen. Wenn du auf Wiederholen klickst, bringt dich der Debugger an die Stelle, an der die Assertion fehlgeschlagen ist, und im Callstack kannst du ablesen, wie es dazu kam. Ich weiß nicht, welche Version von VC++ du benutzt, aber wahrscheinlich ist das diese Stelle: AFX_INLINE TYPE& CArray<TYPE, ARG_TYPE>::ElementAt(int nIndex) { ASSERT([B]nIndex >= 0 && nIndex < m_nSize[/B]);[/code] Das heißt, du greifst mit einem ungültigen Index auf dein CArray zu.

m_code_list.GetText(aryCodeList[i], Code)

GetSelItems liefert dir ein Array von ints, in denen die Indices der ausgewählten Elemente stehen. Das kannst du nicht einfach auf CString umstellen. Statt dessen musst du mit einer Schleife durch dieses Array laufen und jeweils den Text rausholen, mit CListBox::GetText. Diese Texte kannst du dann in dein Array stecken. P.S.: Verschoben nach C++: Compiler, IDEs, APIs

Und wie wäre es mit CArray<CString,CString>?

Geht's ein wenig ausführlicher als "ein Fehler"?

Lass dir doch mal ausgeben, was in den fertigen Strings drinsteht.

Diese Vorgehensweise wird dich nicht weit bringen. Dann schneid sie doch ab, bevor du sie in die Listbox schreibst. Ich weiß, welche Art Message du meinst, aber von deinen gibt es hunderte. Der genaue Text wäre schon hilfreich. Das habe ich doch geschrieben: Du sollst MFC-Steuerelementmethoden (wie CListBox::AddString) nicht aus einem anderen Thread als dem, der das Steuerelement erstellt hat, aufrufen. Mit PostMessage zum Beispiel.

Ich nehme an, das m_code_list eine Membervariable deiner Dialogklasse ist. Um von außen auf diese Variable zugreifen zu können, reicht es nicht aus, wenn sie public ist. Du brauchst auch eine Instanz (oder ein Zeiger oder eine Referenz) dieser Dialogklasse. Aus einem anderen Thread solltest du aber sowieso keine Methoden von MFC-Steuerelementen aufrufen. Die sind diesbezüglich nicht sicher. Du hättest mir ja auch einfach eine PN schicken können... :hells:

Der Einsatz solcher Programme ist dort laut AGB ausdrücklich untersagt. Ich glaube nicht, dass du dazu hier Hilfe bekommen wirst.

Rätsel Stimmt. Ich hatte nicht gesehen, dass em bei dir ein String war. Darum gings auch mit VBScript, das hat ja keine Typen.

Bei mir schon. Folgender Code, in einer .vbs-Datei, erzeugt eine schöne Folge von Messageboxen: heute = Date ende = DateAdd("yyyy", -1, heute) Do heute = DateAdd("w", -1, heute) 'hier wird der letzte Montag berechnet em = heute Loop Until Weekday(heute) = vbMonday Do While em > ende msgbox em em = DateAdd("d", -7, em) Loop[/code]

Größer, nicht kleiner.

Um einen Eintrag zu löschen, musst du NULL übergeben, keinen Leerstring.

Du solltest das Passwort im Connectstring, dem 4. Parameter der Open-Methode angeben können.

Das PSDK ersetzt viele Header- und Bibliotheksdateien von Visual Studio. Wenn du ein Programm mit installiertem PSDK erstellst, kommt etwas anderes dabei heraus, als wenn es nicht installiert ist.

Was passiert denn, wenn du in Spy++ Help -> Index auswählst?

Vom "Builder" schreibt er nichts, es könnte sich auch um eine Kommandozeilenversion handeln. Beschwert sich dein Compiler denn über "void main"?

Sind wir das? Es geht doch um Interesse an der zivilen Luftfahrt. Nur weil sich das bei dir anders darstellt als bei Anderen hier, kommen wir doch nicht vom Thema ab

Es gibt nicht "den" Borland. Viele ältere Compiler, gerade solche, die älter als der C++-Standard selbst sind, schlucken so einiges klaglos, was neuere Versionen desselben Herstellers nicht mehr durchgehen lassen. Der Rückgabetyp von main ist da nur ein Beispiel.

Von mir auch nicht. Nur ein Tipp, mehr nicht. Macht einfach nur den Eindruck, dass du etwas verwirrt bist Nein, das Platform SDK ist vom VS unabhängig. Du könntest nachschauen, ob du einen Ordner "C:\Programme\Microsoft SDK" hast. Der Callstack sieht nicht so toll aus. Das Programm kommt wirklich nicht bis InitInstance? Welches OLE-Dokument benutzt du da eigentlich?

Ein Fragezeichen tut's auch. Ich meine, dass auf einem Rechner das Platform SDK installiert ist und auf dem anderen nicht. Ist das der Fall? Bis wohin kommt es denn? Wie sieht der Callstack zum Zeitpunkt der fehlgeschlagenen Assertion aus?

Das ist in der Tat seltsam. Sind auf beiden Rechnern die gleichen Service Packs für VS installiert? Vielleicht einmal Platform SDK und einmal nicht? Bestimmt. Sollte auch nicht schwieriger sein als einzelne Satzzeichen.