Fenster Handle umleiten?
-
Morgen,
ich habe doch die Funktionen GetParent und SetParent. Ich könnte doch nun den Vaterhandle das Fensterhandle von Anwendung A mit dem Vaterhandle der Anwendung B vertauschen. Dann und umgekehrt. d.h. beide anwenundugnen haben eine veratuschte oberfläche wobei die Programmlogik noch in den ursprünglichen Prozesesn bleibt oder?
Die Fensterhandle an sich haben ja nicht mit dem Progranm zu tun, sie dienen nur für die grafische anordung aufm Desktop? Klrät mich mal auf:)
-
Noch was...
Es gibt ja noch das Prozess Handle.. also bspw. thread-handle.. aber das ist ja was ganz andere wie fenster handles... wie ist das zusammenspiel wie funktioniert das in windows? gibt ne seite wo das beschrieben ist? google hilft mir net viel:(
-
1. Fenster sind Thread afin, d.h. sie gehören zu einem Thread über dessen Nachrichten Loop Sie Ihre Nachrichten erhalten. Die Zurodnung erfolgt einfach indem Moment in dem CreateWindow aufgerufen wird.
2. Der Threadbezug eines Fensters kann nicht geändert werden.
3. Threads gehören unübertragbar somit zu einem Prozess.
4. Fenster eines Prozesses / Threads werden terminmiert, wenn der Thread / Prozess terminiert.
5. Aus den oben gegebenen Infos folgt, dass man Fenster nicht an andere Prozess übertragen kann.Ich würde es tunlichst vermeiden Parent und Child in unterschiedlichen Threads zu halten. Das endet früher oder später schnell in einem Deadlock.
Einfach in der MSDN nachlesen:
http://msdn.microsoft.com/en-us/library/ms632597(VS.85).aspx
-
Danke,
aber dennoch erlaubt mir die API das Parent HANDLE eine Fesnter HANDELs zu verändern, so das ein Fenster in einem anderen "Parent" Fenster zugewiesen werden kann!?! Das ich quaise die Oberfläche einer anwendung in meine anwendung projeziere....!?!?
-
@ Martin Richter hat das wesentliche mitgeteilt.
Zur Ergänzung: Die Fenster-Handles weist allein das System zu und verwaltet diese. Man kann sie abfragen und dann damit Nachrichten austauschen. Mehr sollte man tunlichst nicht versuchen!
-
Fenster Handler... schrieb:
aber dennoch erlaubt mir die API das Parent HANDLE eine Fesnter HANDELs zu verändern, so das ein Fenster in einem anderen "Parent" Fenster zugewiesen werden kann!?! Das ich quaise die Oberfläche einer anwendung in meine anwendung projeziere....!?!?
SetParent wird und sollte nur für Fenster innerhalb eines Threads durchgeführt werden.
Hintergrund ist hier einfach, dass mit dieser Funktion Docking und Floating von Fenstern ermöglöicht wird.Aber sicherlich nicht das übertragen eines Fensters Cross Application!
BTW: Ich muss das jedoch wieder etwas einschränken, ganz so hart snd die Grenzen hier nicht. Via Objekt Linking und Embedding wird durch COM natürlich so etwas gemacht. Allerdings wird hier wirklich nur ein Frame Window gehostet. Wer wirkliich Owner und Parent der Fenster ist ist noch ne andere Geschichte. Zudem hier COM als Zwischenschicht auch noch mitspielt....
Andere Frage:
Was willst Du eigentlich tun?
Welchen Zweck hat die Frage?
-
naja ich hab eine fremde Anwendung, und meine eigene Anwendung... beide anwendung kommunizieren mit einem gemeinsamen externen System.
Um nun zu vermeinden das der "Kunde" mit beiden Anwendungen arbeiten muss, ( (also hin und her switchen), mach ich die Fremde anwendung unsichtbar, und projekziere das Fensterhandle in meine Answendung. So das der Kunde nur eine Anwendugn vor sich hat, und denkt er wäre alle eine anwendung...
-
Und was erlaubt diese Fremde Applikation an Automationsschnittstellen?
Das wäre für mich Ansatzpunkt Nummer 1!
-
du meinst diese Fremde Anwendung über Fesntermessage steuern? Versteh nich gannt "Automatisierungs" schnittstellen?
Ist diese Vorgehen wie ich beschrieben habe schlecht? unsicher? gefährlich?
-
Automatisirung==ActiveX/COM Schnittstelle.
Ich empfinde sie extrem Low/Level und die andere Applikation braucht einfach nur mit sowas simplen zu rechnen wie: GetParent() liefert zeiger auf Fenser von Klasse XYZ, wasbei Dir nicht mehr der Fal ist und schon geht nichts mehr.
Dieses Verfahren ist so extrem speziell, dass ich es nie verwenden würde. Buggy/unsicher/gefährlich/nicht funkionabel ist es evtl. auch schon deshalb weil Du Threaddeadlocks provozierst, unter Vistae mag es gar nicht gehen, wenn der eine Prozess elevated ist, evtl. etc. etc. etc.
