Fenster von Rexx aus manipulieren? ("To Front")

amiga-news.de Forum > Programmierung > Fenster von Rexx aus manipulieren? ("To Front")

[ - Suche - Neue Beiträge - Registrieren - Login - ]

-1-

[ - Beitrag schreiben - ]

24.06.2015, 19:32 Uhr

cgutjahr
Posts: 2783
[Administrator]

Ich bin auf der Suche nach einer Möglichkeit, ein beliebiges Fenster von einem Rexx-Skript aus in den Vordergrund zu holen. Für Screens bietet die rexxtricks.library eine entsprechende Funktion an, für Windows ist mir allerdings nichts bekannt.

Gibt es sowas zufällig?

[ - Antworten - Zitieren - Direktlink - ]

24.06.2015, 22:29 Uhr

thomas
Posts: 7718
Nutzer

Tut's auch ein Shell-Kommando? Kann man per address command ja auch aus Rexx benutzen.

http://thomas-rapp.homepage.t-online.de/downloads/wtf.lha

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 01:33 Uhr

DaxB
Posts: 1422
Nutzer

Ab OS3.5 kann man das Workbench ARexx Interface benutzen.

Selber erstellte Fenster geht z.B. mit rexxarplib.library oder tritonrexx.library.

Für beliebig fremde Fenster ist mir nichts bekannt.

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 14:40 Uhr

DaxB
Posts: 1422
Nutzer

Die rx3h.library (Aminet) von Chris Young bietet folgendes:

RESOLVELINK (follows web redirects)
GETHEADER (get the HTTP headers of a URL)
GETSCREENLIST (gets the public screen list)
SCREENTOFRONT (brings a named public screen to the front)

Vielleicht kannst du ihn Fragen, ob der diese erweitert mit GETWINDOWLIST und WINDOWTOFRONT?

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 15:46 Uhr

igracki
Posts: 22
Nutzer

Zitat:
Original von thomas:
Tut's auch ein Shell-Kommando? Kann man per address command ja auch aus Rexx benutzen.

http://thomas-rapp.homepage.t-online.de/downloads/wtf.lha

Du hast vergessen FreeArgs() am Ende aufzufrufen!

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 16:54 Uhr

thomas
Posts: 7718
Nutzer

@igracki:

Ich wollte nur prüfen, ob einer aufpasst

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 17:11 Uhr

DaxB
Posts: 1422
Nutzer

@thomas:
Auch wenn es offtopic ist. Kannst du bei Gelegenheit dein RequestString 1.1 (27.8.2014) testen, ob X=LEFT für die Fensterposition bei dir funktioniert? Hier erscheint das Fenster immer am linken (X=0) Bildschirmrand, egal was ich für X angeben. Y=TOP funktioniert hier.

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 17:48 Uhr

thomas
Posts: 7718
Nutzer

@DaxB:

Du hast recht. Aber Y kann auch nicht gehen. Weder X noch Y hat eine Funktion, wenn REQPOS nicht angegeben wird. Die Position ist dann immer relativ zum Mauszeiger.

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 23:10 Uhr

cgutjahr
Posts: 2783
[Administrator]

Wow, Tausend Dank an Thomas, das nenne ich mal Service am Kunden

Werde das morgen mal ausprobieren - Klasse!

[ - Antworten - Zitieren - Direktlink - ]

25.06.2015, 23:24 Uhr

DaxB
Posts: 1422
Nutzer

@thomas:
Ja, X und Y alleine funktioniert nicht. REQPOS Y 200 geht hier aber z.B.. Das ganze mit X geht nicht.

[ - Antworten - Zitieren - Direktlink - ]

26.06.2015, 01:55 Uhr

geit
Posts: 332
[Ex-Mitglied]

Da muß eigentlich noch ein Forbid()/Permit() hin, auch wenn das die Sache nicht wirklich besser macht.

Also um LockIBase() und die Window#?() Funktionen noch Forbid() und Permit(). Ansonsten kann da alles passieren bevor die *drei* Fensterfunktionen überhaupt aufgerufen werden.

100% Absturzsicher ist es dann zwar auch nicht, aber die Wahrscheinlichkeit ist sehr gering.

[ Dieser Beitrag wurde von geit am 26.06.2015 um 01:55 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

26.06.2015, 16:02 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von geit:
Also um LockIBase() und die Window#?() Funktionen noch Forbid() und Permit().

Ist nicht der Sinn von LockIBase(), Änderungen am Fenstersystem auszuschließen und somit Forbid() und Permit() unnötig zu machen?
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

26.06.2015, 16:49 Uhr

geit
Posts: 332
[Ex-Mitglied]

Zitat:
Original von Holger:

Zitat:
Original von geit:
Also um LockIBase() und die Window#?() Funktionen noch Forbid() und Permit().
Ist nicht der Sinn von LockIBase(), Änderungen am Fenstersystem auszuschließen und somit Forbid() und Permit() unnötig zu machen?

Ja, aber hier wird vor dem Benutzen des WindowPointers UnlockIBase() gemacht und genau da liegt das Problem. Der Pointer wird außerhalb von lock/unlock benutzt. Damit ist er eigentlich schon wieder potentiell ungültig, weil das Fenster ja geschlossen werden kann.

Dazu muß der User je nach Konfig oft nur ESC drücken.

Und nun wird hier dreimal was aufgerufen, dass den ungültigen Pointer nutzt. ScreenToFront() wird knallen. Vielleicht wird sich auch WindowToFront() bedanken. Oder aber ActivateWindow(), wenn da an der Speicherstelle nur Müll steht.

Das Fenster gehört einer anderen Applikation und kann jederzeit geschlossen werden und nichts hindert es daran, es genau nach dem UnlockIBase() zu machen.

Ich bin mir nicht sicher ob LockIBase()/UnlockIBase intern nicht auch Forbid() benutzen, dann ist die Chance relativ hoch, dass dem UnlockIBase() direkt ein Taskswitch folgt und der kann sonstwas machen, bevor der WindowPointer überhaupt das erste Mal genutzt wird.

Wie gesagt: 100% Sicher ist es trotzdem nicht, weil Forbid() gebrochen werden kann. Innerhalb von LockIBase()/UnlockIBase() kann man die Fenster nicht manipulieren, weil man sich da selbst ins Knie beisst.

Das Ganze ist und bleibt ein Hack. AmigaOS ist nicht dafür designt worden, dass andere Programme die Kontrolle über Fenster erlangen.

[ Dieser Beitrag wurde von geit am 26.06.2015 um 17:34 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

27.06.2015, 10:29 Uhr

thomas
Posts: 7718
Nutzer

@cgutjahr:

Ich habe den Fehler mit FreeArgs korrigiert. Gleicher Link wie oben.

@DaxB:

Auch das ist korrigiert: http://thomas-rapp.homepage.t-online.de/downloads/rtReqStr.lha

Zitat:
Original von DaxB:
@thomas:
Ja, X und Y alleine funktioniert nicht. REQPOS Y 200 geht hier aber z.B.. Das ganze mit X geht nicht.

Das ist ja auch Unsinn. REQPOS ist ein Schlüsselwort, das ein Argument erwartet, kein Schalter. D.h. das Y geht nach REQPOS und die 200 landet irgendwo, vermutlich bei ARGS.

@geit:

Ich sehe da keine reelle Gefahr. Normalerweise holt man ein Fenster nach vorne, damit der Benutzer damit arbeiten kann, weil er damit arbeiten möchte. Warum sollte er das Fenster im selben Augenblick schließen? Mal abgesehen davon, dass es recht schwierig ist, zwei Aktionen so schnell hintereinander auszuführen.

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Antworten - Zitieren - Direktlink - ]

27.06.2015, 14:03 Uhr

DaxB
Posts: 1422
Nutzer

Zitat:
Das ist ja auch Unsinn. REQPOS ist ein Schlüsselwort, das ein Argument erwartet, kein Schalter. D.h. das Y geht nach REQPOS und die 200 landet irgendwo, vermutlich bei ARGS.

Ich wusste nicht wofür REQPOS ist, bzw. was als Argument erwartet wird (Zahlen funktionierten nicht beim rumprobieren). Im Quellcode stehts: C (center) T (top left) sind möglich. Nun weiss ich es auch und Danke fürs fixen!

[ - Antworten - Zitieren - Direktlink - ]

27.06.2015, 16:20 Uhr

cgutjahr
Posts: 2783
[Administrator]

Zitat:
Original von thomas:
Ich habe den Fehler mit FreeArgs korrigiert. Gleicher Link wie oben.

Super, danke.

[ - Antworten - Zitieren - Direktlink - ]

28.06.2015, 02:46 Uhr

geit
Posts: 332
[Ex-Mitglied]

@thomas

Lib_Open/Lib_Close brauchen auch keine Semaphore. Die Chance ist verschwindend gering, das etwas passiert.

Trotzdem macht man das, sonst hat man am Ende Tonnenweise "kann eigentlich nicht passieren." und ein System das plötzlich doch instabil ist.

Du weisst ja nicht wann der User dein Tool aufruft. Vielleicht als Execute on Close bei YAM oder so. Dann knallt es vielleicht schon nicht mehr so selten. Bei MUI Programmen kommt sogar noch die Ikonify Funktion dazu. Und es gibt z..B. unter MorphOS Hotkeys, die eine Gruppe Fenster auf einmal verbergen/erscheinen lassen.

Wenn man schon "illegal" an Strukturen schraubt, die einem nicht gehören, dann sollte man wenigstens alles mögliche tun, um das ganze auch sicher zu machen.

Es absichtlich schlechter machen ist keine gute Technik, zumal nichts dabei gespart wird und das Risiko beim "Kunden" liegt.

[ Dieser Beitrag wurde von geit am 28.06.2015 um 02:47 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]

29.06.2015, 16:58 Uhr

Holger
Posts: 8116
Nutzer

Zitat:
Original von thomas:
@geit:

Ich sehe da keine reelle Gefahr. Normalerweise holt man ein Fenster nach vorne, damit der Benutzer damit arbeiten kann, weil er damit arbeiten möchte. Warum sollte er das Fenster im selben Augenblick schließen? Mal abgesehen davon, dass es recht schwierig ist, zwei Aktionen so schnell hintereinander auszuführen.

Die größte Gefahr geht von der Diskrepanz zwischen „man“ und „der Benutzer“ aus. Dein Programm soll aus einem Skript heraus aufgerufen werden, von dem niemand weiß, wie lange es läuft. Das Schließen des Fensters kann durch Benutzereingaben unmittelbar vorher ausgelöst werden. Oder aber durch andere Skripte oder Programmaktivitäten.

Und einer der größten Fehler, die man in diesem Zusammenhang machen kann, ist zu glauben, dass die Zeit für etwas zu kurz ist, als dass man Vorkehrungen treffen müsste.

Nur weil das Schließen des Fensters genau nach `UnlockIBase()` aufschlägt, bedeutet es ja nicht, dass es genau in diesem Moment ausgelöst wurde, im Gegenteil. Wenn ein Programm versucht, das Fenster zu schließen, während Deines den Lock hält, wird es ja genau bis zur Freigabe des Locks blockiert. Und vor diesem Versuch kann es ja noch beliebig lange mit dem Treffen der Entscheidung, das Fenster zu schließen, zugebracht haben.

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

03.07.2015, 10:08 Uhr

o1i
Posts: 43
Nutzer

Es gibt keine "sichere Art", auf fremde Fenster zuzugreifen, zumindest nicht unter AmigaOS 3.x.

Ich wuerde vor dem Zugriff auf ein fremdes Fenster wie folgt vorgehen:

LockIBase();
SetTaskPri(124);
Pruefen, ob Fenster existiert;
UnlockIBase();
Falls Fenster existiert (hat), Fenster nach vorne holen;
SetTaskPri(alter Wert);

Auch nicht perfekt, aber nachdem alle niedriger priorisierten Tasks (zumindest bei dem regulaeren Scheduler) keine Rechenzeit erhalten, duerfte zwischen dem UnlockIBase und dem Fensterverschieben niemand dazwischenfunken. Und es kann sich auch kein momentan bereits aktives CloseWindow einschleichen, da solange LockIBase nicht erfolgreich waere.

Da intuition aber wohl ziemlich viele Messages schickt, bis ein CloseWindow etc wirklich durch ist, kann man natuerlich nie sicher sagen, ob das wirklich zu 100% sicher ist.

Ein anderer Scheduler wie Executive kann das natuerlich voellig kaputt machen.

[ - Antworten - Zitieren - Direktlink - ]

-1-

[ - Beitrag schreiben - ]

amiga-news.de Forum > Programmierung > Fenster von Rexx aus manipulieren? ("To Front")

[ - Suche - Neue Beiträge - Registrieren - Login - ]