Klotzkopp

Der Thread wird vermutlich ausgeführt, du siehst nur nichts davon, weil deine Schleife, in der du auf das Ende des Threads wartest, die Nachrichtenschleife deines Fensters blockierst. Damit bist du wieder am Anfang, denn die blockierte Nachrichtenschleife war ja der Grund für den Thread. Ich sehe da zwei Möglichkeiten: 1. Der Thread schickt, wenn er fertig ist, eine benutzerdefinierte Nachricht an das Fenster, damit es weitermachen kann. 2. Das Fenster prüft in einer Timer-Funktion regelmäßig, ob der Thread beendet ist, und macht dann weiter.

Mir sind zwei Dinge aufgefallen: if (row[i] != "") Das funktioniert nicht so, wie du es vermutest, falls row ein char-Pointer ist, was ich vermute. Du könntest auf != NULL testen, oder strcmp verwenden. Zweitens kannst du dir die Abfrage auf != NULL sparen, wenn du free aufrufst. Kannst du soviel wie möglich aus dem Code rauswerfen, so dass der Fehler immer noch auftritt?

Du lieferst einfach nicht genug Informationen, als dass man dir helfen könnte. Nein. Der Stack ist normalerweise 1 MB groß. Der hat mit dynamischem Speicher nichts zu tun. Es bringt nichts, den Heap zu vergrößern. Du hast einen Speicher-Bug in deinem Programm, den musst du finden. Ich vermute den Fehler irgendwo in " //Verarbeitung der Daten". Solange du aber nicht sagst, was da passiert (mit Code), können wir nur raten. Es wäre wirklich am einfachsten, eine String-Klasse zu verwenden. Die sind genau dafür da, dass du dich nicht mit dynamischem Speicher herumschlagen musst.

Ich sagte doch, in der Threadfunktion hast du keinen Zugriff auf nichstatische Member. m_cSmiley ist ein nichtstatischer Member. Ich sagte auch, dass der Zeiger, den du bei AfxBeginThread übergibst, als LPVOID-Parameter in der Threadfunktion landet. Dumusst dann deinen ListControl-Zeiger wieder aus dem void-Zeiger rausholen: UINT Dlg::ArbeitsFunktion(LPVOID param) { CListCtrl* pMeinListCtrl = reinterpret_cast<CListCtrl*>(param); pMeinListCtrl->GetItemCount(); // usw. }[/CODE]

Bei dem Compiler, den du benutzt, vielleicht. Man mag über den Sinn streiten können, aber der Standard sagt klar int main, und es gibt durchaus Compiler, die "void main" als Fehler ansehen.

Für AfxBeginThread brauchst du jetzt wieder UINT, nicht DWORD, als Rüclgabetyp.

Vor einer öffnenden Klammer darf keine Zahl stehen, dahinter kein Operator (außer unäres + oder -, also als Vorzeichen). Vor einer schließenden Klammer kein Operator, dahinter keine Zahl.

Die Threadfunktion darf keine nichtstatische Memberfunktion sein.

Sondern? Zeig bitte mal den Aufruf. Wie kommst du darauf? get_Project sollte eigentlich nur ein LPDISPATCH zurückgeben. Die generierten Klassen sind von COleDispatchDriver abgeleitet, und damit Wrapper um Interfaces, nicht um CoClasses. Es gibt keinen Grund, da irgendetwas umzubenennen. Den Rückgabewert von get_Project solltest du an eine Instanz der Wrapperklasse von _IProjectDoc oder _EProjectDoc binden können, je nachdem, welches Interface du brauchst.

645. Gerade im Osten habe ich noch recht große Defizite. Hitzacker, gibts das wirklich?

Das geht nicht so einfach. Bei CodeProject gibt es da was: http://www.codeproject.com/staticctrl/coloredit_colorstatic.asp Dafür sind Textfelder nicht geeignet. Falls die Texte nicht (oder nur in der ersten Spalte) vom Benutzer editierbar sein sollen, könntest du ein Listen-Steuerelement (CListCtrl) benutzen.

Du musst sicherstellen, dass die CFont-Instanz, deren Adresse du mit SetFont übergibst, mindestens solange existiert wie das Fenster, dem du sie zugewiesen hast. In deinem Fall ist font aber eine lokale Variable, die zerstört wird, wenn die Methode ShowText beendet ist. Dass das in dem anderen Dialog funktioniert, ist Zufall. Wenn du aus der lokalen Variablen einen Member der Dialogklasse machst, dann sollte es funktionieren. Siehe dazu auch: http://support.microsoft.com/support/kb/articles/q85/5/18.asp

Musst du nicht. Bei main darf man laut Standard das return weglassen.

Da fehlt dazwischen irgendwie der Punkt "Programm starten". Machst du das? Wenn ja, wie? Ich möchte einfach nur, dass du das Programm nicht normal, sondern mit dem Debugger startest.

Wenn du das Programm mit F5 startest, und Datensätze ins Spiel kommen, stürzt es also nicht ab? Und wenn du es ohne Debugger startest (Strg-F5), und Datensätze ins Spiel kommen, dann schon?

Und ich sagte nichts von kompilieren. Wenn du das Programm mit F5 startest, stürzt es also nicht ab? Und wenn du es ohne Debugger startest (Strg-F5), dann schon?

OnInitDialog ist OK. Wenn du meinst. Was passiert, wenn du das Programm mit F5 startest?

Du hast mich nicht verstanden. Wie heißt die Funktion, in der der Code steht, den du oben gepostet hast? Wie lautet die Meldung, wenn du das Programm mit dem Debugger startest?

Wo (in welcher Methode) steht denn dieser Code? Wie genau lautet die Meldung beim "Crash"?

Zeigt pKunden überhaupt auf ein hinreichend großes Array? Was passiert, wenn du als erstes in der Schleife CString test = pKunden->GetVName(); machst?

Nullzeiger freigeben tut nichts. @Fraunz81: Warum verwendest du keine Stringklasse anstatt der TCHAR-Zeiger? Dann müsstest du dich nicht mehr um die Speicherverwaltung kümmern.

Es gibt keinen Grund zu schreien. Du solltest unbedingt darauf achten, ob der Kompiliervorgang ohne Fehler beendet wird, sonst brauchst du dein Programm nicht zu starten, und dich auch nicht über diese Meldung zu wundern. Wenn du dir die Fehlermeldungen des Compilers ansiehst, wird dir wahrscheinlich in dieser Zeile: cout << "In Add(), erhalten " << x << " und " << y << "\n"> oder in der darauffolgenden einen Syntaxfehler gemeldet werden. Das liegt daran, dass das > am Ende der Zeile nicht dahin gehört. Da muss ein ; hin, wie bei jeder Anweisung. Auch hier getch() fehlt das Semikolon am Ende. Zu iostream.h hat dir Guybrush Threepwood bereits etwas gesagt. Gewöhn dir bitte an, nach dem Kompilieren zu prüfen, ob Fehler oder Warnungen aufgetreten sind. Falls ja, schau dir die Zeilen, in denen der Compiler Fehler sieht, genau an. Ich bezweilfe, dass es wirklich so im Buch steht. Aber selbst wenn, darfst du dich trotzdem nicht aufs stumpfe Abschreiben beschränken, sondern musst versuchen, zu verstehen, was da falsch sein könnte. Bücher enthalten nunmal hin und wieder Fehler, deswegen ist Mitdenken gefragt. Die Fehler, die hier vorliegen, hättest du ohne größere Schwierigkeiten auch selbst finden können, oder? Falls du eine Fehlermeldung nicht verstehst oder den Fehler nicht beheben kannst, dann erst melde dich hier, und zwar mit der kompletten Fehlermeldung und dem dazugehörigen Code, vielleicht mit ein paar weiteren Zeilen davor und dahinter.

Norton Antivirus (2004) benötigt ein besonderes Update, damit es von XPSP2 erkannt wird. Das Update kann über die LiveUpdate-Funktion eingespielt werden. Allerdings muss man bei der Installation noch ein Kontrollkästchen aktivieren, damit andere Programme den Status von NAV abfragen können.

Laut MSDN Library liest InternetReadFile nicht zwangsläufig die ganze Datei auf einmal ein. Du musst InternetReadFile solange aufrufen, bis es TRUE zurückgibt und die Anzahl der eingelesenen Bytes 0 ist. Du darfst übrigens für Parameter 3 und 4 nicht dieselbe Variable benutzen, denn bevor InternetReadFile irgendwas anderes macht, setzt es die Variable, auf die Parameter 4 zeigt, auf 0.