Klotzkopp

Der Sprungantrieb verbraucht Energiezellen aus deinem Laderaum.

Aber wenn du nach dem Setzen des Timers auf das Ende des Threads wartest, ist deine Nachrichtenschleife wieder blockiert. Warum setzt du die "Weitere Anweisungen" nicht in die Timerfunktion?

Wenn du die Abarbeitung anhalten willst, um auf das Ende des Threads zu warten, warum dann überhaupt ein eigener Thread?

Das ist das Travelling Salesman Problem (wenn man die Rückkehr zum Startpunkt weglässt). Bisher ist kein Algorithmus bekannt, der das Problem schneller als exponentiell löst. Du kannst natürlich alle möglichen Routen durchprobieren, aber bei vielen Punkten wird das sehr bald sehr langsam. Um wieviele Punkte geht es denn?

Wie kommt diese Information in site rein? In dem Code auf Seite 1 dieses Threads ist site ein Array von 20 char, das nicht initialisiert wird. site kann nichts speichern, weil nirgendwo im Code irgendein Inhalt in site abgelegt wird.

Aber im ursprünglichen Code doch, oder? Wie soll diese Abfrage funktionieren, wenn site nie mit Daten gefüllt wird?

Was ich nicht verstehe: Wenn du die strcpy-Anweisung rausgenommen hast, wie wird site dann überhaupt mit Inhalt gefüllt?

Ich bitte vielmals um Entschuldigung :floet: Gehört die Datei main.c auch zu diesem Programm? Falls ja, gibt es da drin auch eine main-Funktion? Stellt sich der Fehler noch so dar, wie du ihn zu Anfang beschrieben hast?

Hallo Kitty82, Er programmiert in C, d.h. das getline ist nicht std::getline. Er kann auch mit ifstream nichts anfangen. @Quoth: Irgendwo muss getline herkommen. Vielleicht aus einer Headerdatei?

strcpy (site, "site"); ... if(0 == strcmp(site, "test")) [/PHP] Du setzt site auf "site" und vergleichst dann mit "test"? [PHP] if(prog == 1) fprintf(dynp, "document.forms[0].program[0].checked=true;\n"); else if (prog == 2) fprintf(dynp, "document.forms[0].program[1].checked=true;\n"); else if (prog == 3) fprintf(dynp, "document.forms[0].program[2].checked=true;\n"); Machs doch so: fprintf(dynp, "document.forms[0].program[%d].checked=true;\n", prog-1); [/PHP] Mit deinen anderen if-if/else-Kaskaden kannst du das gleiche machen. [PHP] getline(&line,&l, setup); Wie sieht getline aus? Ich vermute da ein massives Speicherleck. if (lang == 1) fprintf(setup, "document.SetupForm.language[0].checked=true;\n"); else if (lang == 2) fprintf(setup, "document.SetupForm.language[1].checked=true;\n"); if (unit == 1) fprintf(setup, "document.SetupForm.torqueunit[0].checked=true;\n"); else if (unit == 2) fprintf(setup, "document.SetupForm.torqueunit[1].checked=true;\n"); else if (unit == 3) fprintf(setup, "document.SetupForm.torqueunit[2].checked=true;\n"); else if (unit == 4) fprintf(setup, "document.SetupForm.torqueunit[3].checked=true;\n"); else if (unit == 5) fprintf(setup, "document.SetupForm.torqueunit[4].checked=true;\n"); else if (unit == 6) fprintf(setup, "document.SetupForm.torqueunit[5].checked=true;\n"); [/PHP] Auch hier reicht je eine Zeile: [PHP] fprintf(setup, "document.SetupForm.language[%d].checked=true;\n", lang - 1); fprintf(setup, "document.SetupForm.torqueunit[%d].checked=true;\n", unit - 1);

Zeig bitte mal den aktuellen Code.

Ändere if (site=="test") in if(0 == strcmp(site, "test"))

Ist site ein char-Array oder char-Zeiger? Falls ja: Die kannst du nicht mit == vergleichen, da dann nur ein Adressenvergleich durchgeführt wird. Du musst die Funktion strcmp verwenden.

Die Meldungen zeigen, dass SilentHunter das Programm mit dem Debugger gestartet hat. Da passiert das nicht.

Dein Programm stürzt nicht ab. Die Meldungen stellen auch keine Fehler dar. Das Programm beendet sich nur ganz normal, wenn es fertig ist. Dabei schließt sich das Konsolenfenster. Das bewirkt natürlich, dass du die letzte Ausgabe nicht mehr siehst. Du kannst das verhindern, indem du am Ende des Programms noch eine Eingabe einbaust.

Du "selektierst" den Pen in den Device Context - Stichwort SelectObject. Nicht vergessen, hinterher den alten Pen wieder reinzusetzen.

Du könntest mehrfach einlesen und die gemessene Zeit durch die Anzahl der Lesevorgänge teilen.

Das Standard-Windows-Listcontrol kann weder Sub-Steuerelemente darstellen (außer Eingabefelder in der ersten Spalte) noch mehrzeilige Texte darstellen. Wenn du MFC nicht benutzen willst, bleibt dir nichts anderes, als entweder die Comboboxen selbst zu erstellen oder das Listcontrol komplett selbst zu malen. Mit MFC ließe sich sicher bei CodeProject etwas passendes finden. Auf jeden Fall kannst du dir da aber Anregungen holen.

Anscheinend ist das ein Bug in Visual C++ 6. Der Compiler akzeptiert das hier: int x = sizeof(char*) 3; Dabei wird die 3 komplett ignoriert. Visual C++ 7.1 gibt eine Fehlermeldung aus.

Sicher ein Leerzeichen, kein Leerstring? Aber selbst dann kannst du nicht mit != vergleichen, du musst strcmp benutzen. Wenn du den Zeiger nach dem free auf NULL setzt, kannst du doch gar nicht mehr doppelt freigeben. Und du setzt doch am Anfang alle Zeiger auf NULL, oder? free(NULL) tut nichts. Darum ist die Abfrage für den free-Aufruf sinnlos.

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.