Messages abfangen/mitlesen

[Monday]

Zitat von Schwedenbitter:

Hallo,

ich habe folgendes Problem: ich will/muss eine große Anzahl von bmp-Dateien in jpg-/png-Dateien umwandeln. Das wollte ich in einen Thread auslagern, u.a. um die Forms flüssig laufen zu lassen. Allerdings scheitert das an dem nicht threadsicheren TBitmap(.Canvas).

Also habe ich die Idee, die Berechnung in einem (unsichtbaren) Konsolenprogramm ausführen zu lassen und dieses wiederum über Messages vom Hauptprogramm zu steuern. Den Rumpf stelle ich mir so vor:

Ich habe eine andere Idee:
Wenn die Messages nicht viel oder zu komplex sind; Vielleicht kannst du die Daten über einfache Textdateien austauschen?

[Mavarik]

Warum machst Du es nicht in einer DLL? Soweit ich weiß, hat jede DLL eine eigene VCL-Instance...

Theoretisch solltest Du die DLL 4x Laden können und hättest so 4 Worker-Threads...

Mavarik

Oder?

[Delphi-Laie]

Kann man nicht Nachrichten per postthreadmessage an den (Haupt-)Thread des Konsolenprogrammes schicken?

[Zacherl]

Zitat von Delphi-Laie:

Kann man nicht Nachrichten per postthreadmessage an den (Haupt-)Thread des Konsolenprogrammes schicken?

Die API nimmt kein Thread-Handle, sondern eine Thread-Id. Thread-Ids sind aber Prozess-spezifisch. Demnach vermute ich, dass man nur Messages an Threads im eigenen Prozess schicken kann.

[Delphi-Laie]

Zitat von Zacherl:

Zitat von Delphi-Laie:

Kann man nicht Nachrichten per postthreadmessage an den (Haupt-)Thread des Konsolenprogrammes schicken?

Die API nimmt kein Thread-Handle, sondern eine Thread-Id. Thread-Ids sind aber Prozess-spezifisch. Demnach vermute ich, dass man nur Messages an Threads im eigenen Prozess schicken kann.

Was meinst Du mit "prozeßspezifisch"? Vermutlich "prozeßeigen", dem gleichen Prozesse zugehörig o.ä.

Diese (per Threadschnappschuß beschaffbaren) Thread-IDs sind genauso systemeinmalig wie einige andere Werte (Prozeß-IDs, Heap-IDs, Fensterhandle, sicher gibt es noch mehr).

Ich hatte mal mit postthreadmessage experimentiert, weil ich das Wissen um diese Problematik für ein anderes Programm benötigte, und konnte sehr wohl Messages auch an "prozeßfremde" Threads schicken. Da die Frage für mich beantwortet war, habe ich das Programm schon wieder gelöscht, es war auch nicht allzu kompliziert.

[Delphi-Laie]

Angehängtes Programm habe ich soeben noch einmal schnell zusammengebastelt, ganz so ähnlich wie damals.

Man kann damit vom VCL-Thread aus einem weiteren Thread des eigenen Programmes eine Botschaft schicken (einfach Thread-ID von einem Edit zum anderen hinüberkopieren).

Startet man das Prgramm zweimal und kopiert die Threadnummern "über Kreuz", so kann man Messages auch munter zum Thread eben eines anderen Programmes versenden.

[Schwedenbitter]

Danke für Eure Hilfe bis hierhin.
Ich habe es jetzt so gelöst, dass ich die erforderlichen Daten an ein Fenster ("normale", zweite VCL-Anwendung) sende und in diesem dann die Grafikbearbeitung nebst Umwandlung in png bzw. jpeg erfolgt. Das jeweilige Fensterhandle bekomme ich dabei mittels FindWindow(); .

Jetzt beschäftige ich mich bereits damit, dass beide Programme jeweils nur einmal gestartet werden können. Ansonsten wäre Datensalat vorprogrammiert. Das wiederum bewerkstellige ich über einen Mutex. Dieser liefert mir eine aus meiner Sicht eindeutigeres Handle.
Jetzt ist meine Idee, FindWindow nicht mehr zu benutzen und stattdessen das Handle über OpenMutex() zu erfragen.
Bevor ich das jetzt ausprobiere und es evtl. zufällig funktioniert und dann irgendwann einmal nicht mehr:

Kann man das so machen?

Es ist ja theoretisch nicht auszuschließen, dass ein anderes Programm durch Zufall denselben Fensternamen trägt...

[SneakyBagels]

Da das hier am besten reinpasst frage ich hier.

Wenn ich mit PeekMessage eine Message entgegennehme, ist nach abarbeiten des Codes der Aufruf von TranslateMessage und DispatchMessage dann zwingend erforderlich?

[Zacherl]

Zitat von SneakyBagels:

Wenn ich mit PeekMessage eine Message entgegennehme, ist nach abarbeiten des Codes der Aufruf von TranslateMessage und DispatchMessage dann zwingend erforderlich?

Nein, zwingend ist das nicht. Nur, wenn du die jeweilige Funktionalität benötigst:

Zitat von TranslateMessage:

Translates virtual-key messages into character messages. The character messages are posted to the calling thread's message queue, to be read the next time the thread calls the GetMessage or PeekMessage function.

Zitat von DispatchMessage:

Dispatches a message to a window procedure. It is typically used to dispatch a message retrieved by the GetMessage function.

PeekMessage entfernt die Nachricht allerdings nicht aus der Message-Queue. Wenn du das brauchst, dann nimm GetMessage.

[SneakyBagels]

GetMessage zusammen mit einem WM_QUIT am Ende klappt in der Tat besser als PeekMessage.
Ich verwende GetMessage innerhalb eines Threads und PostThreadMessage von außerhalb.
Muss ich die MessageQueue im Thread auch leeren?