Klotzkopp

Ich denke, die werden durchaus geschrieben, nur nicht dort, wo du es erwartest. Wenn sie in dem Verzeichnis erstellt werden sollen, in dem auch die Quelldatei liegt, musst du den Pfad aus argv[1] extrahieren und vor die Dateinamen der Ausgabedateien setzen.

Ich habe vorher nicht so genau reingeschaut. Wie kommst du auf die Idee, argv[64] zu benutzen? Es ist ziemlich unwahrscheinlich, dass dein Programm mit 64 Parametern gestartet wird. In argv[0] steht der Name deines Programms, also steht der erste Kommandozeilenparameter in argv[1]. Generell solltest du für argv keinen größeren Index als argc - 1 benutzen.

Du musst nicht, das ist "nur" eine Warnung. Aber am Wert von argc kannst du erkennen, ob dein Programm mit Parametern (z.B. durch Drag&Drop) gestartet wurde oder nicht.

Wie Guybrush Threepwood schon sagte, die Signatur deiner main-Funktion ist falsch. int main(int argc, char* argv[]) Die Namen der Parameter sind egal, aber du darfst den int-Parameter nicht weglassen.

Bei CopyFileEx kannst du eine Callbackfunktion angeben, die aufgerufen wird, wenn ein Teil des Vorgangs abgeschlossen ist. Damit kannst du feststellen, wann die Datei kopiert ist.

Ein Hinweis, dass das so nur mit Literalen funktioniert und ein Zeiger auf const char als Rückgabewert wären IMHO angebracht gewesen. Aber ansonsten ist ja alles gesagt worden.

Leider ist conio.h nicht Bestandteil des Standards, daher ist deine Lösung nicht portabel. Sieh dir einfach mal den Link an, den c_m gepostet hat, da steht, wie es standardkonform geht

sizeof(g_csFiles) / sizeof (g_csFiles[0])

C-Strings (also char-Arrays und char-Zeiger) kann man nicht inhaltlich mit == und != vergleichen. Dabei werden nur die Adressen verglichen. Stichwort strcmp.

Der Ruf nach einer Eval-Funktion ist oft (nicht immer) ein Hinweis auf ein Designproblem. Du solltest dich von diesem ganzen Konzept verabschieden. Mal ganz davon abgesehen, dass es nicht funktioniert, weil Bezeichner wie "Feld1" und "Feld2" zur Laufzeit im Programm gar nicht mehr drin sind: Dieser Ansatz ist nicht sinnvoll. Du verwendest interne Eigenschaften der Implementierung für die Datenschnittstelle. Dadurch schaffst du zusätzliche Abhängigkeiten in deinem Code, die später, wenn du etwas ändern möchtest, zu Problemen führen. Ich empfehle dir, die Struktur der Datei zu ändern, so dass nicht der Bezeichner des Steuerelements, sondern der Sinn des zugeordneten Textes drinsteht: Begruessung1 = "Hallo" Begruessung2 = "Wie gehts?" Titeltext = "Welcomescreen" Diese Sinnbezeichner kannst du dann im Programm den Steuerelementen zuordnen.

Generell ist es nicht sicher, MFC-Methoden aus einem anderen Thread als dem, der das Fenster erstellt hat, aufzurufen. Es geht zwar oft gut (was hauptsächlich daran liegt, dass viele MFC-Methoden nur hauchdünne Wrapper um die WinAPI sind), aber manches eben nicht (z.B. UpdateData). Im Zweifelsfall ist es immer besser, aus dem Thread eine Message an irgendein Fenster zu senden, und dort die gewünschte Aktion auszulösen. Wie sieht denn CMainFrame::SendTextToStatusbar aus?

Warum wird AFXSTATE.cpp überhaupt kompiliert? Hast du die dem Projekt hinzugefügt? Falls nein: - Temporäre Dateien löschen (ncb, opt, plg), Alles neu erstellen Wenn das nicht hilft: - Hast du irgendwo eine #include-Direktive hinter das DEBUG_NEW-define des MFC-Assistenten gesetzt? Das könnte die Meldung mit dem new erklären. - Neuestes Service Pack für VC installiert? - Funktioniert der Code, wenn du ihn in ein neues Projekt kopierst?

Lass mich raten, du hast bei C++ gleich mit grafischen Oberflächen angefangen? Und jetzt fragst du, wie du Daten in etwas anderem als Steuerelementen ablegst, bzw. programmübergreifend zugänglich machst. Das ist leider ein sehr häufiges Problem bei denen, die sich gleich in die Programmierung grafischer Benutzeroberflächen stürzen, ohne (z.B. an Konsolenprogrammen) die Grundlagen zu lernen. Daher ist deine Frage auch nicht in zwei oder drei Sätzen zu beantworten. Immerhin hast du erkannt, dass es nicht gut ist, Programmdaten in Steuerlementen zu speichern Ich würde dir empfehlen, ein paar Gänge zurückzuschalten, und ein paar Konsolenprogramme zu schreiben, bis du in den Grundlagen sattelfest bist. Falls du das nicht willst, musst du auf jeden Fall verraten, mit welcher Entwicklungsumgebung / GUI-Bibliothek du arbeitest.

Oder einfach Mid

Das ist jetzt aber ein bißchen dünn, von dir hätte ich etwas handfesteres erwartet Über 0,|9 == 1 wird viel diskutiert, aber zweifelt wirklich jemand an, dass 0,|3 == 1/3? Hast du einen Link?

Dann nenn mir eine Zahl, die dazwischen liegt Äh, 1/3 ist eine rationale Zahl.

Da dereferenziert irgendeine Software einen Nullzeiger. Wenn das immer bei unterschiedlichen Programmen auftritt, könnte das vieles sein: Eine Shell-Extension, eine Hooking-DLL, womöglich sogar schädliche Software. Hast du einen Debugger auf dem System?

Ich hatte das schon mal. Das trat auf, nachdem ich zuerst Outlook 2003 und danach eine ältere Version installiert hatte. Ist das bei dir auch der Fall?

Das ist eine Division durch 0.

In deiner Methode CBuildings::OnButtonBuild erstellst du eine Instanz von CRecordset, nicht von CDbtest4Set. Ist also logisch, dass du so nicht auf die Datenmember von CDbtest4Set zugreifen kannst, ein SQL Statement angeben musst und dich mit GetFieldValue abmühen musst. - Instanz von CDbtest4Set erstellen und öffnen - Zum zu ändernden Datensatz navigieren - Edit - Datenmember den neuen Wert zuweisen - Update

Nö. SetFieldValue gibt es nicht. Dafür kann man Klassen von CRecordset ableiten. Das hast du ja auch getan: Du hast die Klasse CDbtest4Set. Nur leider benutzt du sie nicht.

Verschoben --> Delphi/RPG+CL/C#/Sonstige

Und wenn du MoveNext so lässt, gehst du solange durch die Datensätze, bis es keinen "aktuellen" mehr gibt. Ich frage nochmal: Welchen Datensatz willst du ändern? Wie äußert sich das denn? Bekommst du eine Fehlermeldung, oder passiert einfach nichts? Letzteres ist wie gesagt kein Wunder, weil du hinter dem letzten Datensatz stehst. Da gibt es nichts zu ändern.

Der Client baut keine zweite Verbindung auf. Du hast ja dafür gesorgt, dass connect nur einmal aufgerufen wird. Der Client schickt alle Daten über denselben Socket raus, der Server erwartet nach jedem recv/send-Paar einen neuen Verbindungsaufbau. Das kann nicht funktionieren.

Und welchen? Was du bisher machst, sieht so aus: Du gehst alle Datensätze durch, und nach dem letzten versuchst du, einen Datensatz zu ändern, der nicht da ist. Um alle Datensätze zu ändern, solltest du das in der while-Schleife machen. Hier wäre es aber wohl effektiver, gleich ein UPDATE-Statement abzusetzen.