Klotzkopp

char c; ReadFile( hFile, &c, 1, 0, 0 );

Kein Grund, mich zu siezen. wParam und lParam sind einfach zwei 32-Bit-Werte. Ob Du da Werte reinsetzen musst, und welche, hängt davon ab, was Du mit QuerySiblings machen willst. Verstehe ich nicht. Der Übernehmen-Button wird doch per Default angezeigt, solange Du nicht in m_psh.dwFlags der Sheet-Klasse PSH_NOAPPLYNOW setzt. Von allein machen Sheet und Pages bei QuerySibling gar nichts. Was QuerySibling macht, und wie es auf die übergebenen Werte reagiert, musst Du in den Nachrichtenbehandlungsfunktionen der Pages selbst programmieren.

Dann dürfte das, was Du oben gemacht hast, eigentlich nicht funktionieren. Besser wäre: CString strBenutzerID; strBenutzerID.Format( "%d", pRs->m_BenutzerID ); m_fgBenutzerVer.SetTextArray(7, strBenutzerID); Das ist in Ordnung.

Nicht ganz. Der erste Parameter ist die Adresse der Variablen. Bei einem Array muss da nur deshalb kein Adressoperator (&) hin, weil der Arrayname ohne Indexklammern der Adresse des ersten Elements entspricht.

Der Doppelpunkt muss weg. Außer unter Windows CE, da muss er hin.

Das dient dazu, die vier Bytes des Arrays Zeile mit 0 zu initialisieren. Es enspricht dem hier:Zeile[0] = Zeile[1] = Zeile[2] = Zeile[3] = 0; Ja, das kann jetzt weg. Hatte ich übersehen.

Boardbenutzer, die C, aber kein Fortran beherrschen, werden Dir eher weiterhelfen können, wenn Du auch noch verrätst, was das tun soll.

Brauchst Du die gesamte Erdkugel, oder kannst Du das Gebiet einschränken?

Die brauchst Du auch nicht. Vorschlag: char Zeichen; char Fehler_code[] = "\t1\t"; char Zeile[4]; char Tabulator = '\t'; char EndOfLine = '\n'; int Fehler = 0; int Tab = 0; int test = 0; long int i = 0; void __fastcall TfrmMain::FormCreate(TObject *Sender) { memset( Zeile, 0, 4 ); ifstream application("application.txt", ios::in); while(!application.eof()) { application.get(Zeichen); Zeile[0] = Zeile[1]: Zeile[1] = Zeile[2]; Zeile[2] = Zeichen; if(Zeichen == Tabulator && i != 0) { ++Tab; } if(Zeichen == EndOfLine) { Tab = 0; ++test; } if((strcmp(Zeile,Fehler_code) == 0) && (Tab == 3)) { ++Fehler; } ++i; } } [/CODE]

Ob das geht, hängt vom Datentyp von m_BenutzerID ab. Du kannst nicht einfach so auf einen LPCTSTR casten. Das kann übel ins Auge gehen. Als welcher Datentyp kommt der in Deinem Programm an?

Auch für ein leeres Stringliteral wird ein abschließendes Nullbyte erstellt.

Wenigstens sind wir uns einig

Das reserviert Dir genau ein Byte, und zwar Zeile[0]. Ist kein Fehler, aber char Tabulator = '\t'; wäre besser, denn dann sparst Du dir auch die Dereferenzierung. Du schreibst und liest hier in Speicher herum, den Du nicht reserviert hast. Nur Zeile[0] ist erlaubt (siehe oben). Mit hoher Wahrscheinlichkeit überschreibst Du andere Variablen.

Du hast auf jeden Fall vergessen, den Parametern der Funktionen einen Datentyp zu verpassen. Wenn es sicht um einen int handelt, muss das so aussehen: CLine::CLine(CPoint ptFrom, CPoint ptTo, COLORREF crColor, int m_penwidth) Außerdem solltest Du den Parametern nicht den Präfix m_ geben, um Verwechslungen mit Membervariablen zu vermeiden.

@Guybrush: Bei beiden Vorschlägen von Dir würde ich eher Referenzen verwenden. @Woodstock: Ich würde auch zur verketteten Liste raten.

Du kannst für Deine Klasse einen Cast-Operator definieren: operator char const *() const { return var; }[/CODE] Dann wird, wann immer Du eine Instanz von Test an Stelle eines char const* oder char const * const angibst, var verwendet. Damit funktioniert z.B.: [CODE]printf( t ) Folgendes wird nicht funktionieren, weil die nachfolgenden Parameter bei printf keine Typprüfung haben: printf( "%s", t ); Die Möglichkeiten wären hier: printf("%s", static_cast<char const *>( t ) ); printf("%s", (char const *)t );[/code]

Was Du hier machst, ist ein Adressvergleich. Die Adresse des Stringliterals "j" vergleichst Du mit der Adresse des ersten Elements von a. <Gebetsmühle> char-Strings vergleicht man mit strcmp. Achtung, strcmp gibt bei Übereinstimmung Null zurück. </Gebetsmühle> Falls Du wirklich nur ein einziges Zeichen vergleichen willst, solltest Du HELLmuts Vorschlag verwenden.

Networking Technologies, oberstes Thema: http://fachinformatiker-world.de/forums/showthread.php?s=&threadid=34655&werbeid=17

Bitte die Boardregeln, Punkt 9 beachten. Wenn Du glaubst, dass Dein Thema nochmal ins Gedächtnis der Leser gerufen werden muss, wende Dich bitte an einen der zuständigen Moderatoren.

Erwischt. Eigentlich schon. Ein application.close() an geeigneter Stelle wäre wohl ganz angebracht. Kann sein, dass Windows da toleranter ist, aber abstürzen sollte das Programm trotzdem nicht. An welcher Stelle passiert's denn?

Nein. Lokale Variablen werden zerstört, sobald sie ihren Gültigkeitsbereich verlassen, in Deinem Fall also spätestens beim Verlassen der Methode, in der Du die Variable angelegt hast. Im Destruktor von CStatic wird DestroyWindow aufgerufen, damit ist das Control wieder weg. Mach eine Membervariable der Dialogklasse draus, oder hole den Speicher dynamisch. Dann sollte sich aber die Dialogklasse den Zeiger merken, um ihn am Ende wieder freizugeben.

Man kann TerminateThread verwenden, um einen Thread zu beenden. Allerdings ist das eine gefährliche Sache, weil z.B. auf dem Heap allokierter Speicher, CritSecs und geladene DLLs nicht freigegeben werden. Du solltest also zuerst den Thread "sanft" beenden, z.B. indem Du ein Flag setzt, das der Thread regelmäßig prüft, und abwarten, ob er sich selbst beendet. Erst wenn das nicht klappt, solltest Du TerminateThread in Erwägung ziehen. Das Ganze könnte etwa so aussehen: DWORD dwThreadId; HANDLE hThread = CreateThread( NULL, 0, ThreadProc, (void*) pParam, 0, &dwThreadId ); // ...irgendwas tun // Jetzt soll der Thread beendet werden, Flag setzen fStopThread = TRUE; // Dem Thread Zeit geben, sich zu beenden.Hier: 5 Sekunden if( WAIT_OBJECT_0 != WaitForSingleObject( hThread, 5000 ) ) { // Thread hat nicht terminiert, dann auf die harte Tour TerminateThread( hThread, 0 ); } CloseHandle( hThread ); [/CODE]

@gajUli: Welchen Compiler verwendest Du? @LLpresident: Das zeichenweise Einlesen sollte ja klar sein. Wenn ich ein Tab finde, setzt ich den Dateizeiger um eins zurück (Offset -1 von der aktuellen Position, deswegen cur für current). Damit steht der Dateizeiger wieder vor dem Tabzeichen. Dann schreibe ich das Dollarzeichen in die Datei. Warum der zweite pubseekoff-Aufruf notwendig ist, weiß ich auch nicht, denn der macht im Prinzip nichts. Er setzt den Dateizeiger auf Offset 0 von der aktuellen Position, lässt ihn also auf gut Deutsch da, wo er ist.

Der Aufruf von DeleteContents aus OnNewDocument heraus ist schon in Ordnung. Das ist die Standardimplementierung von OnNewDocument. Aber weil DeleteContents u.a. auch zur Initialisierung eines neuen Dokuments verwendet wird, darf dieser Code da nicht rein. @007ski: Setze bitte mal den Code, der jetzt in DeleteContents steht, in die OnCloseDocument-Methode Deiner Dokumentklasse. Falls Du keine hast, kannst Du sie mit dem Klassenassistenten erstellen.

Würde mich wundern, wenn das so wäre. Ist das jetzt ein neues Problem? Hat sich das alte erledigt?