Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Messages abfangen/mitlesen (https://www.delphipraxis.net/187980-messages-abfangen-mitlesen.html)

Monday 22. Jan 2016 10:04

AW: Messages abfangen/mitlesen
 
Zitat:

Zitat von Schwedenbitter (Beitrag 1327639)
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 22. Jan 2016 10:10

AW: Messages abfangen/mitlesen
 
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 22. Jan 2016 17:05

AW: Messages abfangen/mitlesen
 
Kann man nicht Nachrichten per postthreadmessage an den (Haupt-)Thread des Konsolenprogrammes schicken?

Zacherl 23. Jan 2016 00:21

AW: Messages abfangen/mitlesen
 
Zitat:

Zitat von Delphi-Laie (Beitrag 1327872)
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 23. Jan 2016 09:34

AW: Messages abfangen/mitlesen
 
Zitat:

Zitat von Zacherl (Beitrag 1327896)
Zitat:

Zitat von Delphi-Laie (Beitrag 1327872)
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 23. Jan 2016 15:00

AW: Messages abfangen/mitlesen
 
Liste der Anhänge anzeigen (Anzahl: 1)
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 27. Jan 2016 13:29

AW: Messages abfangen/mitlesen
 
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
Delphi-Quellcode:
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
Delphi-Quellcode:
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 15. Mai 2017 20:30

AW: Messages abfangen/mitlesen
 
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 15. Mai 2017 20:35

AW: Messages abfangen/mitlesen
 
Zitat:

Zitat von SneakyBagels (Beitrag 1371525)
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:

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:

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

MSDN-Library durchsuchenPeekMessage entfernt die Nachricht allerdings nicht aus der Message-Queue. Wenn du das brauchst, dann nimm MSDN-Library durchsuchenGetMessage.

SneakyBagels 15. Mai 2017 21:11

AW: Messages abfangen/mitlesen
 
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?


Alle Zeitangaben in WEZ +1. Es ist jetzt 19:09 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz