ThreadedForm?

[PeterPanino]

Wie kann man erreichen, dass ein Nebenfenster (eines Hauptformulars) automatisch in einem eigenen Thread läuft? Gibt es für sowas eine Komponente, die man einfach auf dem Formular des Nebenfensters platziert?

[Bernhard Geyer]

Gar nicht. Die VCL (und die Win32-API) ist nicht Thread-Save.

[PeterPanino]

Zitat:

Zitat von Bernhard Geyer

Gar nicht. Die VCL (und die Win32-API) ist nicht Thread-Save.

Ist die .Net-VCL thread-sicher?

[mr2]

meines Wissens nach nicht, da die VCL.net "nur" die auf .net portierte VCL ist und nach wie vor mehr als 95% der Aufrufe direkt an die Windows-API gehen

mr2

[PeterPanino]

Das Problem ist nämlich folgendes:

Im Hauptfenster laufen ziemlich aufwendige Prozesse ab, und wenn ich dann im Nebenfenster auf einen Button klicke, dann reagiert der nicht. Und ich kann bei den aufwendigen Prozessen im Hauptfenster nicht Application.ProcessMessages aufrufen, weil diese aufwendigen Prozesse von ActiveX-Komponenten verursacht werden, auf die ich keinen Einfluss habe.

Oder wie könnte man das Problem des Button-Klicks im Nebenfenster sonst lösen?

[BUG]

Zitat:

Zitat von PeterPanino

Das Problem ist nämlich folgendes:
Im Hauptfenster laufen ziemlich aufwendige Prozesse ab

:!:
Das wäre doch ein Ansatzpunkt: vielleicht kannst du diese Prozesse in einen Thread packen und das Hauptfenster für die Zeit sperren.

MfG,
Bug

[PeterPanino]

Zitat:

Zitat von BUG

Das wäre doch ein Ansatzpunkt: vielleicht kannst du diese Prozesse in einen Thread packen und das Hauptfenster für die Zeit sperren.

Diese ActiveX laufen schon in einem ThreadedTimer-Event (also in einem eigenen Thread). Sie greifen aber auf das Hauptformular zu (ist notwendig) und legen deshalb den Application-Thread lahm.

[PeterPanino]

Gibt es so etwas wie einen systemweiten Mausklick-Event? Ich könnte dann prüfen, ob der Mausklick über dem Button des besagten Nebenfensters erfolgte und in diesem Fall die gewünschte Aktion auslösen.

[PeterPanino]

Ich habe jetzt versucht, im Timer-Event eines weiteren Thread-Timers (500 ms) mit GetAsyncKeyState abzufragen, ob eine bestimmte Taste gedrückt ist. Aber offensichtlich ist GetAsyncKeyState auch auf die Windows-Botschaftswarteschlange angewiesen, sodass auch hier erst nach einer längeren Zeit auf den Tastendruck reagiert wird.

Gibt es nicht eine LowLevel-Funktion, mit der man außerhalb der Windows-Botschaftswarteschlange abfragen kann, ob eine bestimmte Taste gedrückt ist?

[alzaimar]

Zitat:

Zitat von PeterPanino

Zitat:

Zitat von BUG

Das wäre doch ein Ansatzpunkt: vielleicht kannst du diese Prozesse in einen Thread packen und das Hauptfenster für die Zeit sperren.

Diese ActiveX laufen schon in einem ThreadedTimer-Event (also in einem eigenen Thread). Sie greifen aber auf das Hauptformular zu (ist notwendig) und legen deshalb den Application-Thread lahm.

Hmm.. Wie greifen die denn darauf zu?

[PeterPanino]

Zitat:

Zitat von alzaimar

Hmm.. Wie greifen die denn darauf zu?

Auf dem Hauptformular findet eine Visualisierung der Ergebnisse der ActiveX-Komponenten statt.

[Reinhard Kern]

Zitat:

Zitat von PeterPanino

Wie kann man erreichen, dass ein Nebenfenster (eines Hauptformulars) automatisch in einem eigenen Thread läuft? Gibt es für sowas eine Komponente, die man einfach auf dem Formular des Nebenfensters platziert?

Hallo,

brutal, sollte aber immer möglich sein: du startest als 2. Fenster eine eigenes Programm (und beschäftigst dich mit Inter-Prozess-Kommunikation). Wenn man das geschickt macht, fällt es garnicht auf, und wenn man weiss wie, können Programme auch sehr eng zusammenarbeiten.

Empfehlenswert: 1 x EXe für Data Processing, 1 x Exe für GUI.

Gruss Reinhard

[mschaefer]

Wenn ich ein MDI-Fenster habe und zwei Client-Fenster, dann könnte ich den Arbeitsthread in einem Clientfenster alufen lassen und die Eingabesteuerung im zweiten. Ich bin mir da allerdinga nicht sicher, aber ich meine, dass die Zeiten zwischen den Clientfenstern aufgeteilt wird.

Grüße // Martin