Serv,

ich habe 2 eigene "Kontextmenü" Einträge im Windows-Explorer per Registry Änderung hinzugefügt.

- Add items
- Process items

Meine Anwendung ist so gebaut, das diese die 2 Parameterarten verarbeiten kann.
Das Funktioniert problemlos für "Einzelne" Dateien und Ordner.

Es gibt eine art Queue wo die Parameter (Directories oder Dateien) gespeichert werden.
- Bei Add werden sollten sie nur hinzugefügt werden
- Bei Process sollte der vorherige Inhalt geleert werden, der neue hinzu und die Verarbeitung gestartet werden.

Falls die Anwendung schon läuft, erkennt es den vorhanden Mutex und Sendet den Parameter direkt mit WM_COPYDATA an das Hauptfenster der offenen Anwendung und beendet sich selbst.



Nun kommt aber mein problem:

Die Anwendung braucht einige Sekunden um Hochzufahren.
Während dieser Zeit ist das Hauptfenster nicht sichtbar, somit können keine WM_COPYDATA nachrichten empfangen werden.

Sobald ich nun mehrere Dateien oder Ordner markiere und im Contextmenü eintrag "Add" oder "Process" auswähle, dann kommt effektiv nur der letzte parameter oder mal 2-3 an und die Logik der Anwendung fängt an Rumzuspinnen, weil für jeden Parameter der per WM_COPYDATA reinkommt, sofort behandelt wird.

Halt aus dem Grund weil die Parameter an die Anwendung geschickt werden die zuerst gestartet wurde und diese Botschaft aber nicht ankommen kann, weil das Hauptfenster ne zeit zum laden brauch.



Dazu kommt noch das man auch einfach im Windows Explorer Eingabe drücken kann nachdem man was markiert hat und die jeweiligen Anwendungen die der Erweiterung zugeordnet sich gestartet werden.

Somit meine Anwendung pro markierten Eintrag gestartet wird, aber trotzdem irgendwie nur den letzten Eintrag davon in die Queue haut und verarbeitet.



Was macht man in dem Fall ?

Was gibts da für möglichkeiten, vor allem dingen was gibt es für andere Wege von Anwendung > Anwendung zu kommunizieren, ausser WM_COPYDATA.

Hm, also ich hab zwar nicht wirklich Ahnung davon, aber vllt kann man die Daten in eine Memory Mapped File schreiben.
Ich hab allerdings lange nicht damit gearbeit und weiß garnicht was passiert, wenn die File vergessen wird, ob die dann noch die ganze Zeit im Hauptspeicher rumliegt.
Auf jeden Fall ist das eine Möglichkeit unter Anwendungen Daten zu verschicken.

steht vielleicht was in paramstr(1) usw.?
oder verstehe ich dich gerade völlig falsch (was ich nicht ausschließen mag)
Falls du Lazarus nutzt, dann gugg dir mal das an.

Mermory Mapped File dürfte unter Vista aus Sicherheitsgründen nicht mehr gehen (es sei denn die Anwendung ist ein System Service).

Insofern ich dein Problem richtig Verstanden haben hier 2 Möglichkeiten:

Ich würde versuchen das message handling in ein seperates Fenster auszulagern (welches direkt beim start der Anwendung - also bevor irgendetwas anderes gemacht wird erzeugt wird). So kannst du wenigstens immer auf die WM_COPYDATA Nachrichten reagieren und sie dann in ne Queue kopiere die ausgeführt wird sobald die Anwendung ready ist.

Alternativ das senden der WM_COPYDATA so lange verzögern bis die Anwendung richtig hochgefahren ist.
(Am besten existens des empfänger Fensters per FindWindow überprüfen oder mit mehreren MUTEX Objekten arbeiten).

Die einzige andere mir bekannte Möglichkeit zum Datenaustausch wären COM Interfaces (viel spaß damit )

Per WindowsAPI ein unsichtbares Fenster erstellen, dasz noch vor dem Mutex erstellt wird, koennte dein Problem loesen Dann kann die Anwendung auch noch ne Weile blockieren, in der MessageQueue des Fensters landen die Nachrichten schon.

Warum MMFs unter Vista nicht gehen sollten ist mir aber nicht klar. Klappt imho fast wie immer nur dasz Services jetzt ihre MMFs global ablegen und User-Anwendungen "lokal" suchen - da musste dann ein bischen Tricksen, ... Siehe auch http://msdn.microsoft.com/en-us/library/aa382954.aspx , http://blogs.msdn.com/maartenb/archive/ ... vista.aspx . Ist fuer das Mutex auch nicht schlecht, wenn man da ein Global\\ vorsetzt.