Hallo,
@tröööt:
... zumindest nicht ohne das der focus wechselt ...
Genau. so hatte ich das ja auch gemeint. Der Focus muss natürlich nur für eine sehr kurze Zeit an das versteckte Fenster gegeben werden.
Dann wird ein Mausklick simuliert und der Focus wieder an das vorher aktive Fenster gegeben.
Ich behaupte nicht, dass es elegant ist, auch nicht, dass es super laufen muss, aber es kann funktionieren. Dem Ansatz liegt ja zugrunde, dass nicht zwei Fenster gleichzeitig den Fokus haben können.
Gerade für die Fensterwechsel braucht man Zugriff auf die Windows-Api-Funktionalität, ob nun über Libs, Interfaces (wie JNI, JNA oder JACOB). Hooken der Mausklicks in die VM, ok, aber da man ohnehin Zugriff auf native Windows-Funktionalität bräuchte, könnte man gleich alles so erledigen.
und wie du schon sagtest : es ist nicht wirklich sinnvoll java dazu zu verwenden um Win-COM aktionen ablaufen zu lassen ... dafür würde sich C oder eine seiner ab-arten deutlich besser eignen ... zu mal C# (also DotNET) direkt COM anbietet ...
So habe ich das nicht gesagt. Ich habe lediglich ausgedrückt, dass damit natürlich die Plattformunabhängigkeit verloren geht. Darüber hinaus habe ich gesagt, dass es in der Praxis Fälle gibt, wo das sogar erforderlich ist, die Existenz der o.g. Technologien beweist das ja geradezu.
Ansonsten ist es doch legitim, das aus Java heraus zu lösen, vor allem, wenn man es nur auf seinem eigenen System einsetzen will.
Ob die Lösung dann auch einigermaßen flüssig läuft und nicht zu sehr nervt, steht doch erstmal noch auf einem anderen Blatt.
Und das alleine machen zu wollen, ist doch eher positiv. Das bedeutet, dass man was lernen will. Und der Zugriff auf native Betriebssystemfunktionen kann in bestimmten Anwendungsfällen auch aus Java heraus sogar sehr nützlich sein. Dann ist es gut, wenn man schon mal Erfahrung damit hat.
Du verweist an anderer Stelle im Forum (zur Simulation von Mausklicks) auf die Klasse java.awt.Robot. Die greift auch auf native Betriebssystem-Funktionen zu und schreibt in die jeweiligen OS-MessageQueues. Dass Robot auf manchen OS zusätzliche Berechtigungen für den Zugrif auf Low-level Betriebssystemfunktionen braucht, auf manchen Betriebssystemen sogar zusätzliche Bibliotheken, zeigt, dass die Plattform-Unabhängigkeit damit auch nur noch bedingt gegeben ist. Worüber regst du dich also auf?
Natürlich ist es ok, es zum Ausdruck zu bringen, wenn man etwas nicht sinnvoll findet. Das kann man aber auch sachlicher machen.
Jemanden seinen vermeintlichen geringen Kenntnisstand vorzuhalten, finde ich übrigens keinen guten Stil, und es ist überheblich. Wie ich in meinem vorherigen Beitrag schon geschrieben habe, haben wir alle mal angefangen. Und ganz sicher mit einem deutlich geringeren Kenntnisstand als heute - und dafür, beim Weiterkommen zu helfen, sind solche Foren schließlich auch da.
Und typographisch laut zu werden (ganze Wörter und Sätze in Großbuchstaben), finde ich stilistisch auch nicht gerade vorteilhaft.
Du hättest zum Beispiel ja was in der Art schreiben können, wie "zwei Fenster gleichzeitig können nicht fokussiert sein. Deshalb kannst du nicht ohne weiteres Mausklicks im einen Fenster simulieren, während Du in einem anderen spielst oder arbeitest. Für die Simulation von Mausklicks kann ich dir aber die Klasse Robot empfehlen. ..." Und dann noch ein freundlicher Link auf die Java-API... - das wäre doch was gewesen. Auf die Idee, den Fokus der Fenster zu wechseln (in einer Schleife, und mit sleep), hättest Du ja auch kommen können.
Mit Robot gibt es keine Möglichkeit, direkt einen Handle auf ein anderes Fenster zu beziehen. Deshalb wäre eine andere Schnittstelle (die die native WinAPI-Methode findWindow kapselt) in diesem speziellen Fall vielleicht sinnvoller. Aber "geht gar nicht" stimmt schon mal auf dieser Ebene nicht.
In deiner ersten Antwort auf oOJavaNeulingOo hast du geschrieben
also DAS geht SO schon mal überhaupt nicht ...
du kannst nicht mal eben ein programm im "hintergrund" laufen lassen ... schon gar nicht wenn es diese funktion selbst nicht anbietet ... ein OS kann hier keinen einfluss drauf nehmen ...
weiterhin kannst du auch nicht in einem nicht-existierenden fenster mit einer nicht-vorhandenen "zweiten maus" einen klick machen ...
sorry ... aber alleine auf eine solche idee zu kommen zeigt das man scheinbar überhaupt keinen plan hat was überhaupt im hintergrund so alles abläuft ... ich weis gar nicht wie ich es anders ausdrücken soll ...
klar dürfte es möglich sein mehrere von ein ander unabhängige zeige-geräte nutzen zu können ... aber selbst dann kann man nicht auf etwas klicken was nicht da ist ...
Aber der von oOJavaNeulingOo angedachte Weg geht eben auch. Auch sowas, was quasi kein echter Mausklick ist, diesen aber ersetzt. Das geht dann auch im Hintergrund. Dazu darf das Fenster sogar unsichtbar sein. Das erfordert aber schon ein sehr fortgeschrittenes Grundlagenwissen von Java. Frameworks wie Spring, Struts, Hibernate, um nur wenige zu nennen, nutzen die dem zugrundeliegenden Technologien, sonst ginge das, was diese Frameworks machen nämlich überhaupt nicht. Findest du es heraus?
Vielleicht stellst du dich ansonsten mal vor einen Spiegel. Der reflektiert dann dich und du villeicht ein wenig über dich selbst. Dann kommst du vielleicht zu der tiefgreifenden Erkenntnis, dass du, wie alle anderen auch, sehr viel mehr nicht weißt, als du weißt. Es gibt also keinen Grund für Überheblichkeit.
In diesem Sinne einen schönen Gruß
Wie gesagt will ich dabei auch was lernen.
