In meinem Programm möchte ich, dass wenn man eine weitere Instanz des Programms startet, die neue Instanz einen Zeiger an die erste Instanz "übergibt" und sich dann schließt. Allerdings funktioniert das wie ich es mache nicht.

Am Anfang des Programms erstelle ich einen Mutex, wodurch das Programm erkennen kann, ob schon eine Instanz existiert. Exisitiert schon eine Instanz, dann soll ein Zeiger zu dieser "gesendet" werden:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) {
    HANDLE mutex = CreateMutex(NULL, FALSE, "MutexName");

    if(mutex == NULL)
        return -1;
    else if(GetLastError() == ERROR_ALREADY_EXISTS) {
        HWND hwnd = FindWindow("ClassName", "Title");
        //jetzt soll __argv[1] an die erste Instanz übermittelt werden
        if(__argc > 1)
            SendMessage(hwnd, WM_USER, (WPARAM)__argv[1], 0);

        return 0;
    }
    //usw... mit WinMain

Da WPARAM ja ein typedef von unsigned int ist, müsste WPARAM ja die richtige Größe für den Pointer haben. Und SendMessage wartet ja, bis die andere Instanze die WM_USER Nachricht abgearbeitet hat bevor sie returned, also bleibt __argv[1] ein gültiger Zeiger solange er verarbeitet werden soll.

Nun soll __argv[1] zu Testzwecken mal der Titel der ersten Instanz werden. Das steht also in meiner WndProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam):

case WM_USER:
    SetWindowText(hwnd, (LPCTSTR)wParam);
    break;

Allerdings wird mit dieser Methode letztendlich kein neuer Text in der Titelleiste angezeigt, sondern gar keiner. Woran liegt's? Gibt es womöglich einen bessern Weg, diesen Zeiger zu übergeben?

Bier schrieb:

...
also bleibt __argv[1] ein gültiger Zeiger solange er verarbeitet werden soll.
...

joa fuer deine aktuelle Instanz, aber da ja deine erste Instanz afaik seinen eigenen virtuellen Speicher hat, steht an der Adresse irgendein Wert. Was z.B. eine Idee waere: in eine Datei deine Werte zu speichern, eine Message an deine erste Instanz zu schicken und diese ließt die Datei dann wieder aus. Oder eine anderes Stichwort waere: Memory-Mapped File.

Gruessli C0de4Fun

COPYDATASTRUCT cds;
cds.dwData = 0;
cds.cbData = lstrlen(nCmdLine);
cds.lpData = nCmdLine; //<-Zeiger, der "auf Speicher zur zweiten Instanz gehörend" zeigt

und nicht zu vergessen, dass man SendMessage selbst ja einen Zeiger übergibt:

SendMessage(hwnd, WM_COPYDATA, (WPARAM)NULL, (LPARAM)&cds);

Funktioniert ja alles wunderbar, aber wenn C0de4Fun Recht hat, ist das ja eher Glück als sonstwas.

Übrigens habe ich mit __argv noch etwas rumgefiemelt und bemerkt, dass __argv gar nicht das ist bzw. macht, was ich dachte und wie ja auch einige Quellen behaupten. Zumindest arbeitet es bei mir eben nicht wie argv in einer Konsolenanwendung, sondern enthält doch die gesamte Kommandozeile. Dann kann ich aber statt __argv[0] auch gleich bei lpCmdLine bleiben.

Ist zumindest bei mir so...

Den Umweg über eine Datei (bzw. Registry) würde ich letztendlich machen, aber nur wenn's nicht anders geht.

Übrigens habe ich mit __argv noch etwas rumgefiemelt und bemerkt, dass __argv gar nicht das ist bzw. macht, was ich dachte und wie ja auch einige Quellen behaupten. Zumindest arbeitet es bei mir eben nicht wie argv in einer Konsolenanwendung, sondern enthält doch die gesamte Kommandozeile. Dann kann ich aber statt __argv[0] auch gleich bei lpCmdLine bleiben.

Nöööö! __argv ist bei MS in der CRT eineKopie von argv!
Schau doch in den Sourcecode...

int i;
for(i = 0; i < __argc; i++)
    MessageBox(NULL, __argv[i], NULL, MB_OK);

liefert alles korrekt.
Sorry, hab ich wohl vorher Mist gebaut.

> ist das ja eher Glück als sonstwas

Nein, WM_COPYDATA erzeugt im Adressbereich des Zielprozesses eine Kopie des Datenblocks.

> cds.cbData = lstrlen(nCmdLine);

Korrekt ist übrigens

cds.cbData = lstrlen(nCmdLine) + sizeof(TCHAR);

da sonst der abschließende Null-Char nicht kopiert wird und im Zielprozess dann fehlt (falls da nicht zufällig sowieso eine Null im Speicher steht.

Strings ohne Endekennung können zu interessanten Effekten führen ...

xl schrieb:

> cds.cbData = lstrlen(nCmdLine);

Korrekt ist übrigens

cds.cbData = lstrlen(nCmdLine) + sizeof(TCHAR);

da sonst der abschließende Null-Char nicht kopiert wird und im Zielprozess dann fehlt (falls da nicht zufällig sowieso eine Null im Speicher steht.

Strings ohne Endekennung können zu interessanten Effekten führen ...

Jo, und du glaubst gar nicht, wie lange ich jetzt gerade noch nach dem Fehler gesucht habe. Bis ich dann endlich mal genauer in die Doku von lstrlen geschaut und gelesen habe, dass das Terminierungszeichen gar nicht mitgezählt wird. Hab dann Gott sei Dank alles fehlerfrei zum laufen gekriegt.
Nach meinem faux pas mit __argv und dem lstrlen-Dilemma insgesamt eine schwere Geburt für ein eigentlich leicht lösbares Problem

> ist das ja eher Glück als sonstwas

Nein, WM_COPYDATA erzeugt im Adressbereich des Zielprozesses eine Kopie des Datenblocks.

Genau.
Das System "kennt" WM_COPYDATA, und kopiert die Daten entsprechend in den Zielprozess. Der Zeiger auf den Datenblock wird dabei auch entsprechend angepasst. Das bedeutet auch, dass du in dem über WM_COPYDATA kopierten Block a) keine absoluten Adressen verwenden darsft und b) sowieso keine Zeiger ablegen darfst, die auf ausserhalb des kopierten Datenblocks zeigen.
Falls du zeiger *innerhalb* des Datenblocks brauchst, musst du diese relativ kodieren. z.B. als Offset zum Anfang des Datenblocks, oder als Offset zur Adresse wo der Zeiger selbst abgelegt ist.

Die Daten sind solange gültig, bis der Message-Handler (=die Window-Procedure) fertiggelaufen ist. D.h. wenn man die Daten später noch braucht, muss man sie im Message-Handler nochmal kopieren.

Das System "kennt" WM_COPYDATA, und kopiert die Daten entsprechend in den Zielprozess. Der Zeiger auf den Datenblock wird dabei auch entsprechend angepasst. Das bedeutet auch, dass du in dem über WM_COPYDATA kopierten Block a) keine absoluten Adressen verwenden darsft und b) sowieso keine Zeiger ablegen darfst, die auf ausserhalb des kopierten Datenblocks zeigen.
Falls du zeiger *innerhalb* des Datenblocks brauchst, musst du diese relativ kodieren. z.B. als Offset zum Anfang des Datenblocks, oder als Offset zur Adresse wo der Zeiger selbst abgelegt ist.

Okay, ich muss sowieso nur den einen Speicherbereich von __argv[1] kopieren, von daher ist ja alles paletti:
Der Speicherbereich von

__argv[1][0] bis __argv[1][lstrlen(__argv[1]) + sizeof(TCHAR) - 1]

wird also in den Adressraum des Zielprozesses in einen Speicherbereich gleicher größe kopiert und der

cds.lpData

wird auf den neuen Speicherbereich umgelenkt (wobei lParam=&cds während der WM_COPYDATA wohl auch auf eine kopierte Struktur von cds zeigt, nehm' ich jetzt mal frech an)

Die Daten sind solange gültig, bis der Message-Handler (=die Window-Procedure) fertiggelaufen ist. D.h. wenn man die Daten später noch braucht, muss man sie im Message-Handler nochmal kopieren.

Jupp, alles klar.

Danke,
ciao.