Klotzkopp

Irgendwie passen ifstream und ios::out nicht recht zusammen...

Ich habe erst letzte Woche testweise ein Projekt mit > 500.000 Zeilen konvertiert. Da gibt's einiges: Die IDE hat sich verbessert Der Compiler hat sich stark verbessert Eine ganze Reihe Macken aus MFC und ATL sind weg Wer hat was von fertig gesagt?

Du hast zwar nicht mich angesprochen, aber trotzdem: Wieso nicht? Das klappt eigentlich ganz gut.

Hat da jemand vielleicht diese Datei dem Projekt hinzugefügt oder per include-Direktive eingebunden? Diese Datei gehört zum MFC-Quellcode, und den compiliert man ja normalerweise nicht, die DLLs liegen ja vor.

Alle Klassen der "neuen" Standardheader stehen im Namespace std. Also entweder überall std::ifstream schreiben, oder am Anfang using std::ifstream; // für jede verwendete Klasse oder (Rundumschlag) using namespace std;

In den DWORD, dessen Adresse du als zweiten Parameter angibst, schreib GetFileSize das High-DWORD der (64-Bit) Größe. Das Low-DWORD (also alles unter 4 GByte) steht im Rückgabewert...

Ich wüsste nicht, wieso. Es reicht wahrscheinlich völlig aus, wenn du #include <fstream> (also ohne .h) benutzt. Die Headerdateien mit .h sind einfach nur veraltet und werden von VC7.1 nicht mehr unterstützt.

Shellsort verwendet ja sozusagen einen "Unter-Algorithmus", um die "Spalten" zu sortieren. Dazu nimmt man überlicherweise Insertion Sort, weil der bei vorsortierten Folgen effizient ist. Und das ist gerade beim letzten Schritt, wo Insertion Sort auf die gesamte Folge angewendet wird, von Vorteil. Man kann dafür natürlich auch jeden anderen Sortieralgorithmus benutzen. Die Frage ist, ob das sinnvoll ist.

Ich würde die Größe des Datenblocks variabel machen. Setz dir eine Unter- und eine Obergrenze, und nimm dazwischen einen bestimmten Anteil der Dateigröße (z.B. 1%). 1000 Byte sollte eher die Untergrenze sein. Es bringt jedenfalls nichts, wenn du bei einer 20-MByte-Datei 20.000mal dein ProgressBar aktualisierst.

Um ausw mit einer Zeichenkette vergleichen zu können, musst du den Typ von ausw erstmal so ändern, dass da auch eine Zeichenkette reinpasst. Ich vermute, dass ausw ein char - also ein einzelnes Zeichen ist. Ändere das mal in std::string, dann kannst du auch mit Zeichenketten vergleichen.

Üblicherweise nimmt man dafür ein List Control. Das unterstützt auch gleich die verschiedenen Anzeige-Modi (Icons, Liste, Details etc.).

Es wäre schon hilfreich, wenn du uns die beanstandete Zeile zeigst.

Hast du konkrete Anhaltspunkte dafür, dass das passiert? Bei normaler Navigation wird OnSelChangeTree immer schön nacheinander aufgerufen, weil die Funktion, die OnSelChangeTree aufruft, mit dem nächsten Aufruf wartet, bis der vorherige beendet ist. Ein erneuter Aufruf ohne vorheriges return könnte nur dann passieren, wenn in Funktion irgendwie OnSelChangeTree aufgerufen wird, d.h. wenn du eine Rekursion in deinem Code hast.

DLLs gibts nur unter Windows, das hat also nichts mit Standard-C/C++ zu tun. Darum schiebe ich dein Thema gleich mal ins richtige Forum. Wie du eine DLL erstellst, hängt davon ab, welchen Compiler bzw. welche Entwicklungsumgebung du verwendest. Üblicherweise gibt es dafür eigene Projekttypen. Wenn du Funktionen aus einer DLL nutzen willst, muss die DLL die Funktionen exportieren (das hängt auch vom Compiler ab), und das Programm, das die Funktionen nutzen soll, muss die Funktionen importieren. Hier gibt es mehrere Möglichkeiten, z.B. mit den Windows-API-Funktionen LoadLibrary und GetProcAddress. Du kannst ja einfach mal das Forum nach diesen beiden durchsuchen.

Es gibt eine fertige Funktion dafür: ExpandEnvironmentStrings

Ich würde zuerst mal den Rückgabewert von fopen und fscanf prüfen.

Ich sehe da kein Problem. Solange GotoPage und NächsteFunktion nicht blockieren (d.h. sie warten auf ein bestimmtes Ereignis, und kommen erst zurück, wenn das Ereignis eintritt), ist das so OK.

Klar kannst du das. Ich verstehe aber irgendwie das Problem nicht. Kannst du einen Beispielcode posten?

Im zweiten if steht != (im ersten steht ==). Ist vielleicht nicht das, was du meintest...

Tritt das bei allen mailto-URLs auf, oder nur bei diesem?

getenv

Ja. CoInitialize (bzw. CoInitializeEx) muss für jeden Thread, der COM benutzen will, aufgerufen werden.

AFAIK sind Dateien, die mit CreateFile geöffnet wurden, immer im Binärmodus.

Du verursachst eine Schutzverletzung in GDI32.DLL, wahrscheinlich indem du einen ungültigen Zeiger an eine API-Funktion übergibst. Finde mit dem Debugger heraus, wo das passiert, und schau dir genau die Inhalte der Variablen an dieser Stelle an.

@Prohet: "Netzwerk-Fragen" sind hier so ziemlich alle Beiträge. Bitte achte beim Threadtitel darauf, dass ein Rückschluss auf den Inhalt des Problems möglich ist. Das hilft den Antwortenden und damit auch dir. Ich hab das mal für dich geändert.