Klotzkopp

http://msdn.microsoft.com/workshop/browser/webbrowser/webbrowser.asp#wb_using_cpp

Dann hol dir mit GetModuleFileName den Pfad zu deiner Exe, schneid mit PathRemoveFileSpec den Dateinamen ab und häng den Namen der Textdatei an.

Vermutlich, weil ShellExecute nicht mit relativen Pfaden zurechtkommt. Wozu ist dein Pfad denn relativ? Zum Pfad deines Programms?

Ja. So in der Art. Du schreibst eben einen HTTP-Client. Der Ansatz ist nicht falsch, allerdings ist das kaum notwendig. Viele Entwicklungsumgebungen und Bibliotheken haben fertige Funktionen für HTTP-Requests. Wenn du sagst, was du benutzt, können wir dir womöglich sagen, wie das viel einfacher geht. Und weil das nichts mit Standard-C++ zu tun hat: Verschoben -> C++: Compiler, IDEs, APIs

Hast du eine Quelle für diese Behauptungen, oder ist das ein Gerücht?

Der Compiler tut das, wenn man C++-Funktionen aus DLLs exportiert. Die Name Decoration, mit der die Aufrufkonvention und die Rückgabe- und Parametertypen in den Namen integriert werden, dient allerdings nur dazu, auch bei DLL-Importen Überladung anbieten zu können. Ein generischer Mechanismus ist das eigentlich nicht. C++-Funktionen importiert man ja üblicherweise auch nicht mit GetProcAddress. Wenn man so etwas selbst machen will, muss man die Typinformationen irgendwie anders transportieren, denn Namen hat man zur Laufzeit nicht, und dynamic_cast gibt's bei Funktionszeigern auch nicht. Das riecht nach schlechtem Design.

Nein, GetProcAddress gibt dir immer einen Funktionszeiger vom Typ FARPROC zurück, das ist eine Funktion, die keine Parameter hat und int zurückgibt. Weil das in den wenigsten Fällen stimmt, und weil es eben bei Funktionszeigern keine impliziten Konvertierungen gibt, musst du den Rückgabewert ja meistens mit einem Cast explizit umwandeln.

Die müssen genau übereinstimmen. Es gibt bei Funktionszeigern keine automatischen Konvertierungen. Bei C++ kommt bei bei Memberfunktionszeigern noch der Typ der Klasse hinzu, außer bei statischen Memberfunktionen. Etliche Compiler unterscheiden auch noch nach Aufrufkonvention.

zeig2 ist definiert als Funktion mit dem Rückgabetyp void. zeig ist eine Funktion, die void* zurückgibt. Das passt nicht.

Steht in der MSDN Library: ON_MESSAGE(WM_THREAD_END, DeineMemberFunktion) Die Funktion muss so aussehen: afx_msg LRESULT DeineMemberFunktion( WPARAM wParam, LPARAM lParam); Und es muss natürlich eine nichtstatische Memberfunktion der Klasse sein, zu der die Messagemap gehört. Die Namen den Parameter sind wurscht. Da drin landen Parameter 2 und 3 von Post-/SendMessage.

Wofür? Dafür, dass niemand Lust hatte, in deinem Code, der nicht eingerückt ist, weil du keine Code-Tags benutzt hast, den Fehler zu suchen? Dafür, dass niemand versucht hat, ohne irgendeine Fehlerbeschreibung von dir sich den Code genauer anzusehen? Übrigens: "komm nicht weiter" und "probs mit der konvertierung" sind keine brauchbare Fehlerbeschreibung. Dafür, dass niemand raten wollte, ob du eine Frage hast und wie sie lauten könnte? Gestellt hast du nämlich keine. Dass du bisher keine Antworten bekommen hast, liegt hauptsächlich an dir.

Der Trick ist ja, mit der Tastatur eben nicht die Mausbewegungen nachzuahmen. Wenn man einigermaßen geübt ist, lässt sich Windows mit der Tastatur viel schneller bedienen als mit der Maus. Ausnahmen sind Webbrowser oder Programme mit schlechtem UI.

Das ist nicht gut. Busy-Waiting ist bei Multitaskingbetriebssystemen böse, und Threadsynchronisierung mittels Variablen muss nicht funktionieren. Der C++-Standard sagt nichts über Threads, also muss kein Compiler dafür sorgen, dass beide Threads den Variablenwert immer wieder aus dem Speicher lesen. Du solltest dich mit den Synchronisierungsobjekten vertraut machen: Events, Critical Sections, Mutexe. Wenn du eine Stelle im Code vor gleichzeitiger Ausführung in mehreren Threads schützen willst, mach das mit Critical Sections. Die haben unter Windows sehr wenig Overhead. Wenn ein Thread auf den anderen warten muss, mach das mit Events.

Zeig doch bitte mal einen Beispielquellcode.

Der erste Schritt bei der Fehlersuche ist die Prüfung der Rückgabewerte. Also, was gibt ShellExecute zurück?

Du sagst mir, für welches Betriebssystem das sein soll, und ich verschiebe dich dann ins richtige Forum

Sleep mit großem S. Und weil das kein Standard-C++ ist: Verschoben -> C++: Compiler, IDEs, APIs

Mit seekg kannst du die Position des Lesezeigers in der Datei ändern. So setzt du ihn an den Anfang: datei.seekg( 0, ios_base::beg ); Dann kannst du aber immer noch nicht viel damit machen, weil das Fehlerbit für das Lesen über das Dateiende hinaus gesetzt ist. Die Fehlerbits kannst du aber mit datei.clear(); zurücksetzen. Übrigens ist deine Leseschleife möglicherweise fehlerhaft, je nachdem, was du mit der eingelesenen Zeile machst. eof liefert erst dann true, wenn getline schon einmal fehlgeschlagen ist. Du kannst aber auch getline selbst in der Schleifenbedingung benutzen: while(getline(datei, zeile)) oder while(!getline(datei, zeile).eof()) Beide Beispiele nutzen die Tatsache, dass std::getline eine Referenz auf das Stream-Objekt zurückgibt. Das erste Beispiel nutzt zudem noch aus, dass der Stream selbst als Bedingung genutzt werden kann. Effektiv liefert das true, wenn keines der Fehlerbits gesetzt ist. Das zweite Beispiel testet natürlich nur auf eof.

Eine Schleife seh' ich jetzt nicht... Gar nichts. Es geht darum, formal zu beweisen, dass er tut, was er soll.

Das ist kein formaler Beweis, und obendrein Quatsch. Wenn ich mit zwei Werten rechne, kann dabei auch etwas ganz anderes herauskommen.

Ich bin sicher, es geht ihm darum: @Student02: Das ist ein ziemlich weites Feld, es gibt mehrere Möglichkeiten der Verifikation. Welche Ansätze wurden in der Vorlesung denn vermittelt? Ansonsten gibt's hier ein paar allgemeine Infos: http://en.wikipedia.org/wiki/Verification

Das kenne ich. Nichts macht das Design so sehr kaputt wie nachträglich eingebaute Features

DLLs benutzt man nicht, weil das Programm zu groß ist. Es ist richtig, dass durch die Benutzung von DLLs das Hauptprogramm kleiner wird, aber das ist nicht der Hauptgrund, warum man das tut. DLLs benutzt man, weil sie Schnittstellen bieten und austauschbar sind. Sie vermeiden Redundanz, wenn sie Funktionen beinhalten, die mehr als ein Programm benötigt. Wenn dein Programm nicht von Anfang darauf hin entworfen wurde, kann es schwierig werden, Funktionen in DLLs auszulagern, es sei denn, du hast beim Design gut auf saubere Schnittstellen geachtet. DLLs kann man entweder über Load Time Dynamic Linking einbinden - dazu brauchst du eine Importbibliothek - oder mittels Run Time Dynamic Linking (LoadLibrary, GetProcAddress). Bei Load Time Dynamic Linking startet dein Programm gar nicht erst, wenn die DLL nicht da ist. Bei Run Time Dynamic Linking kannst du darauf zur Laufzeit reagieren.

Läuft Word möglicherweise schon? Ein Prozesshandle bekommst du nur, wenn durch ShellExecuteEx auch wirklich ein Prozess gestartet wird. Was gibt ShellExecuteEx zurück? Was steht in lpExecInfo.hProcess? Was gibt WaitForSingleObject zurück?