Klotzkopp

Wie kopierst du denn? Mit strcpy? In einen Zeiger, den du als Referenz übergeben hast, und der mit "\0" initialisiert wurde? Ohne neuen Speicher anzufordern? Das kann nur in die Hose gehen. Dein Zeiger zeigt auf das Stringliteral "\0", da darfst du gar nichts reinkopieren. Übrigens: "\0" ist sowieso Quatsch. Stringliterale sind automatisch nullterminiert. Das Literal "" besteht aus einem Stringendezeichen, das Literal "\0" also aus zweien. Ich würde dir dringend empfehlen, das ganze auf eine Stringklasse, z.B. std::string umzustellen, die dir die Speicherverwaltung abnimmt.

Projekteigenschaften > General > Use of MFC

Wenn du die C-Runtime statisch linkst, musst du auch die MFC statisch linken.

Das steht unter "Statically linking the executables"

Das Problem ist ja auch nicht die MFC-DLL, sondern (zunächst) die C-Runtime-DLLs. Bei denen reicht es bei VS2005 eben nicht mehr, sie irgendwohin zu kopieren. Der für dich wichtige Teil fängt an bei "Installing the shared CRTs". Entweder du tust, was da steht, oder du linkst statisch.

Schau mal hier rein: Bootstrapper for the VC++ 2005 Redists (with MSI 3.1) - The Code Project - C++ / MFC Zusammenfassung: Statisch linken oder DLLs mitliefern. Letzteres ist aber nicht mehr so einfach wie mit früheren Versionen von VC.

Und was hast du für i übergeben?

Ja. Wenn man sich die Dokumentation zu diesem GlovePie mal durchliest, sieht man, dass das eine recht eigenartige Skriptsprache ist. Da werden Zuweisungen benutzt, um Tasten umzubelegen.

Was machen diese Methoden denn? Geben sie einen Zeiger auf dynamisch angeforderten Speicher zurück? Oder statischen? Oder gar lokalen? Mit strlen hast du dasselbe Problem wie mit strcat. Strlen sucht nach der Nullterminierung, um die Länge zu bestimmen, funktioniert also nicht mit Strings, die gar nicht nullterminiert sind. Wenn deine Stringdaten tatsächlich nicht nullterminiert sein sollten, musst DU wissen, wie lang die Daten sind. Du kannst das nicht nachträglich ermitteln. Wo kommen diese Daten denn her?

Das bringt überhaupt nichts. Strcat sucht nach einer Nullterminierung, um herauszufinden, wo es anfügen muss. Dieser Code fügt also nur dort eine Nullterminierung ist, wo schon eine ist, ansonsten schreibt es dir irgendwo dahinter im Speicher herum. Und wie halten es diese Methoden mit der Speicherverwaltung? Zeiger zurückzugeben ist nicht trivial.

Und was passiert zur Laufzeit? Sprich: was liefert CreateFileMapping / OpenFileMapping zurück?

Lass doch mal die Prozentzeichen weg. Wir sind doch hier nicht in der Shell. Es gibt übrigens auch eine GetEnvironmentVariable-Methode in CString. Dann kannst du dir das Gehampel mit dem Puffer sparen

Versuchs mal so: if key.Left = True mouse.CursorPosX = mouse.CursorPosX + 1 end if[/code] Mit deinem Code legst du IMHO keine neuen Variablen an, sondern belegst die Tasten x und y neu.

CopyFile enthält ja auch nicht die Funktionalität, auf magische Weise Umgebungsvariablen in der Pfadangabe umzuwandeln. Das musst du schon selbst tun, mit einer Funktion, die seltsamerweise GetEnvironmentVariable heißt.

Damit ich das jetzt richtig verstehe: Wenn du die Taste nach links drückst, soll der Cursor nach rechts wandern?

Das halte ich für ein Märchen. Ich kann mir nicht vorstellen, wie das funktionieren soll, und ich glaube, ich bin nicht der einzige. Kannst du die Vorgehensweise grob umreißen, oder ist das ein Geheimnis?

In diesem Zusammenhang vielleicht ganz passend: Security through obscurity - Wikipedia

:confused: Da steht doch, was du tun musst. Muss ich wirklich vorlesen?

Dachte ich mir SCNR. Das sollte aber nicht davon abhängen, ob du es aus dem ersten oder einem weiteren Thread startest. Bei Konsolenprogrammen ist das immer etwas schwierig. Gibt es eine Ausgabe, die du umleiten und auswerten könntest?

Ich kann das hier bei mir nicht reproduzieren. Der Fehlercode ist auch sehr ungewöhnlich: Sicher, dass du dir nicht vorher schon den Heap zerschossen hast?

Den Wert kann CommDlgExtendedError laut Doku nicht zurückgeben. Wie sieht denn der ganze relevante Code jetzt aus?

Anders geht's gar nicht. Dein Programm hat immer mindestens einen Thread, wenn es den nicht gäbe, würde sich ja nichts tun. Dein eigenes Programm, oder eines von denen, die du startest?

Beschreib doch mal, warum du so etwas brauchst. Nach all den Kommentaren sollte ja mehr oder weniger klar sein, dass das nicht umsetzbar ist. Aber vielleicht lässt sich das, was du damit bezweckst, auch anders erreichen.

Das ist CDERR_MEMALLOCFAILURE. Der Windows-Fehlercode ERROR_INVALID_BLOCK ist auch 9, was den Text der Fehlermeldung erklärt. Du kannst die CommDlg-Fehlercodes nicht mit FormatMessage umwandeln, weil sie sich mit den normalen Windows-Fehlercodes überschneiden.

Nein, da ist nichts verlorengegangen. Das (erste) T in LPCTSTR steht für TCHAR. Das ist aber in VS2005 per default nicht mehr char, sondern WCHAR, als ein wide character. Alle Literale, die mit TCHAR zu tun haben, müssen in _T() eingeschlossen werden, damit das Literal je nach Compilereinstellung mit einem führenden L versehen wird, also: LPCTSTR extensions = _T("Hallo Welt"); Mann kann natürlich auch in den Projekteinstellungen den Zeichensatz wieder von Unicode auf Multibyte stellen. Für die Portierung eines bestehenden Projekts ist das sicher einfacher.