Abfrage von Mausklick in Standard-REXX
Abfrage von Mausklick in Standard-REXX
Hallo REXX-Freunde,
gibt es außer den beiden auf Hobbes verfügbaren DLLs (mruntime-1.00b und rexxmous) eine weitere Möglichkeit, einen Mausklick nebst Mauskoordinaten in Standard-REXX abzufragen?
Ich habe ein umfangreiches Programm in Standard-REXX (mit Erweiterungen REXXUtil, ydbautil, sqlrexx und PYRxUtil), das ich noch durch Maus-Interaktionen aufhübschen möchte. Leider funktionieren die beiden oben genannten Routinen nicht bzw. nicht zuverlässig.
- mruntime ist für mich nicht anwendbar, da es auf einen Mausklick wartet, ich will aber Maus und Tastatur gleichberechtigt benutzen.
- rexxmous dagegen hat das Feature, nur die Mauskoordinaten bei Klick zu melden, nicht aber auf einen Klick zu warten. Es funktioniert auch wie gewünscht. Sobald ich jedoch eine interne REXX-Prozedur oder -Funktion aufrufe, erhalte ich anschließend keine Ergebnisse mehr auf die Mausklickabfrage.
Vielleicht wäre mruntime für mich nutzbar. Ohne verfügbare Dokumentation kann ich aus dem mitgelieferten Beispiel aber nicht erkennen, wie ich das Warten auf Mausklick abschalten kann.
Viele Grüße
Wolfgang
gibt es außer den beiden auf Hobbes verfügbaren DLLs (mruntime-1.00b und rexxmous) eine weitere Möglichkeit, einen Mausklick nebst Mauskoordinaten in Standard-REXX abzufragen?
Ich habe ein umfangreiches Programm in Standard-REXX (mit Erweiterungen REXXUtil, ydbautil, sqlrexx und PYRxUtil), das ich noch durch Maus-Interaktionen aufhübschen möchte. Leider funktionieren die beiden oben genannten Routinen nicht bzw. nicht zuverlässig.
- mruntime ist für mich nicht anwendbar, da es auf einen Mausklick wartet, ich will aber Maus und Tastatur gleichberechtigt benutzen.
- rexxmous dagegen hat das Feature, nur die Mauskoordinaten bei Klick zu melden, nicht aber auf einen Klick zu warten. Es funktioniert auch wie gewünscht. Sobald ich jedoch eine interne REXX-Prozedur oder -Funktion aufrufe, erhalte ich anschließend keine Ergebnisse mehr auf die Mausklickabfrage.
Vielleicht wäre mruntime für mich nutzbar. Ohne verfügbare Dokumentation kann ich aus dem mitgelieferten Beispiel aber nicht erkennen, wie ich das Warten auf Mausklick abschalten kann.
Viele Grüße
Wolfgang
Na klar. Da fallen mir zumindest RexxBOS (http://www.logisoftar.com/ProductsRexxbos.htm) und REXXIO (http://www.lestec.com.au/lestec/lestec.cgi) ein, falls es um die Basisbetriebssystemfunktionalität geht.
Es gibt evtl. noch weitere Möglichkeiten, ohne sich selbst eine entsprechende Funktionsbibliothek basteln zu müssen.
Vielen Dank ak120 für Deine Antwort.
Ich habe mir sogleich Deine beiden Vorschläge angesehen:
Bei RexxIO ist die Mausposition etwas umständlich aus einer Datei auszulesen. Das wäre nicht das Hauptproblem. Das aus der Datei ausgelesene Ergebnis enthält jedoch leider die absolute Pixelposition auf dem Bildschirm, unabhängig davon, ob der Mausklick auf meinem REXX-Textfenster erfolgte oder daneben. Um die aktuelle Spalten und Zeilenposition im REXX-Textfenster zu erhalten müsste ich also ständig die Position meines REXX-Textfensters auf dem Bildschirm überwachen und zusätzlich anhand der Schriftartgröße berechnen. Sicherlich keine unlösbare Aufgabe, aber momentan doch etwas viel Aufwand für ein kleines "nice to have".
Ob die Funktion RmGetPtrPos im Paket RexxBos ebenfalls die Koordinaten des Mauszeigers in Pixeln auf dem Desktop angibt wie bei RexxIO oder als Spalten-/Zeileninformation im Textfenster wie bei rexxmous weiß ich nicht, dazu müsste ich mir das Paket für 59$ kaufen. Da ich nicht weiß, ob mir diese Routine etwas nützt, nehme ich doch erst einmal Abstand davon, das Paket zu erwerben.
Schade, dass rexxmous so buggy ist, ansonsten würde es genau meinen Anforderungen genügen.
Danke nochmals für die Info,
Wolfgang
Ich habe mir sogleich Deine beiden Vorschläge angesehen:
Bei RexxIO ist die Mausposition etwas umständlich aus einer Datei auszulesen. Das wäre nicht das Hauptproblem. Das aus der Datei ausgelesene Ergebnis enthält jedoch leider die absolute Pixelposition auf dem Bildschirm, unabhängig davon, ob der Mausklick auf meinem REXX-Textfenster erfolgte oder daneben. Um die aktuelle Spalten und Zeilenposition im REXX-Textfenster zu erhalten müsste ich also ständig die Position meines REXX-Textfensters auf dem Bildschirm überwachen und zusätzlich anhand der Schriftartgröße berechnen. Sicherlich keine unlösbare Aufgabe, aber momentan doch etwas viel Aufwand für ein kleines "nice to have".
Ob die Funktion RmGetPtrPos im Paket RexxBos ebenfalls die Koordinaten des Mauszeigers in Pixeln auf dem Desktop angibt wie bei RexxIO oder als Spalten-/Zeileninformation im Textfenster wie bei rexxmous weiß ich nicht, dazu müsste ich mir das Paket für 59$ kaufen. Da ich nicht weiß, ob mir diese Routine etwas nützt, nehme ich doch erst einmal Abstand davon, das Paket zu erwerben.
Schade, dass rexxmous so buggy ist, ansonsten würde es genau meinen Anforderungen genügen.
Danke nochmals für die Info,
Wolfgang
Das Betriebssystem bietet leider keine andere Möglichkeit. Das bezeichnete "Textfenster" ist leider eben auch nur ein "PM-Fenster" zumindest aus der Sicht des Zeigers.Wolfie hat geschrieben: ↑Sa 8. Dez 2018, 00:13 Bei RexxIO ist die Mausposition etwas umständlich aus einer Datei auszulesen. Das wäre nicht das Hauptproblem. Das aus der Datei ausgelesene Ergebnis enthält jedoch leider die absolute Pixelposition auf dem Bildschirm, unabhängig davon, ob der Mausklick auf meinem REXX-Textfenster erfolgte oder daneben.
Zusätzlich wären noch die weiteren Möglichkeiten zur Ereignisauslösung und Zustandsänderung zu beachten.Um die aktuelle Spalten und Zeilenposition im REXX-Textfenster zu erhalten müsste ich also ständig die Position meines REXX-Textfensters auf dem Bildschirm überwachen und zusätzlich anhand der Schriftartgröße berechnen. Sicherlich keine unlösbare Aufgabe, aber momentan doch etwas viel Aufwand für ein kleines "nice to have".
Ich habe es nicht ohne Grund zuerst aufgeführt, da es noch am ehesten den vermuteten Anforderungen entspricht. Man kann dort sicherlich freundlich für eine Probierversion anfragen.Ob die Funktion RmGetPtrPos im Paket RexxBos ebenfalls die Koordinaten des Mauszeigers in Pixeln auf dem Desktop angibt wie bei RexxIO oder als Spalten-/Zeileninformation im Textfenster wie bei rexxmous weiß ich nicht, dazu müsste ich mir das Paket für 59$ kaufen. Da ich nicht weiß, ob mir diese Routine etwas nützt, nehme ich doch erst einmal Abstand davon, das Paket zu erwerben.
Die russischen Lösungen, welche entweder nur teilweise oder nur in einer Gesamtbildschirmsitzung funktionieren, habe ich wegen der entstehenden Folgekosten bereits während der Selektion ausgesondert.
Der Aufwand die gesamte REXX-Anwendung in eine visuelle Umgebung zu übertragen ist oftmals deutlich geringer.
Man braucht kein Paket zu kaufen, es ist auch die elektronische Lieferung zu €51,98 möglich - deutlich günstiger als diese Sponsor Unit und sonstige Vaporware-Geschichten - und mit ordentlicher Dokumentation als INF-Datei. Wer unbedingt das gedruckte Handbuch benötigt, sollte weitere €60,31 für die Express-Lieferung einplanen.Wolfie hat geschrieben: ↑Sa 8. Dez 2018, 00:13 Ob die Funktion RmGetPtrPos im Paket RexxBos ebenfalls die Koordinaten des Mauszeigers in Pixeln auf dem Desktop angibt wie bei RexxIO oder als Spalten-/Zeileninformation im Textfenster wie bei rexxmous weiß ich nicht, dazu müsste ich mir das Paket für 59$ kaufen. Da ich nicht weiß, ob mir diese Routine etwas nützt, nehme ich doch erst einmal Abstand davon, das Paket zu erwerben.
Die Funktionen arbeiten Zellen-basiert und bilden die entsprechenden OS/2-Subsystemaufrufe ab. Ich hänge einfach die Beispiele in den Anhang.
Das wurde auch nur schnell aus dem Virtual Pascal Beispielen zusammengeschustert.Schade, dass rexxmous so buggy ist, ansonsten würde es genau meinen Anforderungen genügen.
- Dateianhänge
-
- RexxBOS.zip
- (344.5 KiB) 248-mal heruntergeladen
Zuletzt geändert von ak120 am Sa 8. Dez 2018, 15:26, insgesamt 1-mal geändert.
Vielen Dank Andreas für Deine Infos und Unterstützung, ich werde mal schauen, wie ich jetzt weitermache. Vorrangig bereite ich mich jetzt erst mal auf das Usertreffen in Köln vor.
Gruß
Wolfgang
Gruß
Wolfgang
Bei den Unmengen an verwendeten proprietären REXX-Bibliotheken von Drittanbietern habe ich den Ansatz über Curses ausgeschlossen, da mir der Änderungsaufwand doch etwas zu hoch erscheint. Daher habe ich die Erweiterungen, welche manche Implementierungen bzgl. der Mausunterstützung bieten, nicht näher betrachtet. Aber wenn eine gewisse Plattformneutralität erreicht werden soll, möchte ich es an dieser Stelle auch nicht verschweigen.
Ob der Aufwand gegenüber der Erstellung einer eigenen spezifischen Bibliothek in diesem Fall lohnt, kann ich leider nicht beurteilen. Das hängt zu sehr von der Ausgangslage ab. Die Ausgabe 7/95 der Zeitschrift OS/2 Inside enthält dazu u.U. einen praktischen Artikel ("Über den Tellerrand"). Das Begleitmaterial befindet sich im Anhang und die paar Seiten kann ich zur Not faxen.
- Dateianhänge
-
- exutil.zip
- OS/2 Inside 7/95 - Über den Tellerrand
- (9.57 KiB) 234-mal heruntergeladen
- Frank Wochatz
- Beiträge: 1112
- Registriert: So 22. Dez 2013, 22:04
- Wohnort: Berlin
- Kontaktdaten:
Hallo Wolfgang,
VisproRexx ist schon eine Weile frei verfügbar. Ev. kannst Du dein Programm nach Vispro übertragen, und dort die Mausfunktionen benutzen. Falls das in Frage kommt, bitte noch al die Aufgabe genau beschreiben (ich hab es noch nicht ganz kapiert), dann sehe ich mal nach ob das mit den Vispro Funktionen geht. Das wäre dann allerdings ein PM-Programm.
VisproRexx ist schon eine Weile frei verfügbar. Ev. kannst Du dein Programm nach Vispro übertragen, und dort die Mausfunktionen benutzen. Falls das in Frage kommt, bitte noch al die Aufgabe genau beschreiben (ich hab es noch nicht ganz kapiert), dann sehe ich mal nach ob das mit den Vispro Funktionen geht. Das wäre dann allerdings ein PM-Programm.
Vielen Dank für Eure Hinweise.
Das Programm, was das im Laufe der Jahre auf nunmehr über 4000 Zeilen angewachsen ist, habe ich speziell meinen Anforderungen angepasst. Die Menüsteuerung erfolgt über Hotkeys und Pfeiltasten. Letztens ertappte ich mich dabei, dass ich einen Menüpunkt mit der Maus anklicken wollte, anstelle mich dorthin mit den Pfeiltasten zu bewegen. Diese Möglichkeit wäre zwar schön, ist aber nicht essentiell wichtig. Auf jeden Fall denke ich, dass es den Aufwand nicht rechtfertigt, das Programm allein aus diesem Grunde auf eine andere Sprache umzustellen. Momentan habe ich auch noch eine Menge anderer Baustellen, so dass ich die Mausunterstützung erst einmal auf Eis gelegt habe.
Vielen Dank für Eure Hinweise.
Wolfgang
Das Programm, was das im Laufe der Jahre auf nunmehr über 4000 Zeilen angewachsen ist, habe ich speziell meinen Anforderungen angepasst. Die Menüsteuerung erfolgt über Hotkeys und Pfeiltasten. Letztens ertappte ich mich dabei, dass ich einen Menüpunkt mit der Maus anklicken wollte, anstelle mich dorthin mit den Pfeiltasten zu bewegen. Diese Möglichkeit wäre zwar schön, ist aber nicht essentiell wichtig. Auf jeden Fall denke ich, dass es den Aufwand nicht rechtfertigt, das Programm allein aus diesem Grunde auf eine andere Sprache umzustellen. Momentan habe ich auch noch eine Menge anderer Baustellen, so dass ich die Mausunterstützung erst einmal auf Eis gelegt habe.
Vielen Dank für Eure Hinweise.
Wolfgang
Ein vielversprechender Ansatz, die Mauscursor-Abfrage in mein Standard-REXX-Programm einzubauen, war die Routine rexxmous (Simple mouse DLL for REXX, with VP source), die auf Hobbes verfügbar ist. Leider funktionierte sie nicht zuverlässig. Ich sprach über dieses Problem beim Usertreffen in Köln und Frank hat sich die Mühe gemacht, die Routine anhand des Pascal-Quelltextes in C neu zu schreiben. Das Umswitchen von rexxmous auf Franks rxmous war denkbar einfach, da Aufruf und Rückgabeparameter völlig identisch sind. Franks Routine funktioniert einwandfrei, nochmals vielen Dank dafür. Ich habe die Mausabfrage schon an vielen Stellen in meinem Programm einbauen können. ![Überglücklich :D](./images/smilies/icon_e_biggrin.gif)
Gruß
Wolfgang
![Überglücklich :D](./images/smilies/icon_e_biggrin.gif)
Gruß
Wolfgang
Nachdem das klappt, will ich die dll nicht für mich behalten. Soll ich sie auf Hobbes hochladen, oder wohin sonst?Wolfie hat geschrieben: ↑Fr 4. Jan 2019, 14:11 Ein vielversprechender Ansatz, die Mauscursor-Abfrage in mein Standard-REXX-Programm einzubauen, war die Routine rexxmous (Simple mouse DLL for REXX, with VP source), die auf Hobbes verfügbar ist. Leider funktionierte sie nicht zuverlässig. Ich sprach über dieses Problem beim Usertreffen in Köln und Frank hat sich die Mühe gemacht, die Routine anhand des Pascal-Quelltextes in C neu zu schreiben. Das Umswitchen von rexxmous auf Franks rxmous war denkbar einfach, da Aufruf und Rückgabeparameter völlig identisch sind. Franks Routine funktioniert einwandfrei, nochmals vielen Dank dafür. Ich habe die Mausabfrage schon an vielen Stellen in meinem Programm einbauen können.
MfG
Frank
Hobbes wäre gut, da steht Deine Routine dann gleich neben ihrem Vorgänger.
Ich habe übrigens die Mausabfrage jetzt auch in IrxRadio eingebaut. Da kann man die Radio-Tasten direkt per Maus bedienen. Die neue Version von IrxRadio kommt dann auch auf Hobbes.
Gruß
Wolfgang
Ich habe übrigens die Mausabfrage jetzt auch in IrxRadio eingebaut. Da kann man die Radio-Tasten direkt per Maus bedienen. Die neue Version von IrxRadio kommt dann auch auf Hobbes.
Gruß
Wolfgang
Vielen Dank nochmal für das nette Gepräch gestern in Utrecht.
Ich habe mir die Version 1.7 von irxradio von hobbes geladen [1], habe aber sowohl unter ArcaOS, als auch unter Ubuntu Probleme beim entpacken des Inhalts.
Kann es sein, dass die ZIP-Datei defekt ist?
Gruß/2
Matthias
[1] http://hobbes.nmsu.edu/h-search.php?key ... ton=Search
Das ist natürlich höchst ärgerlich, dass Hobbes die Version 1.7 vom incoming-Verzeichnis sogar in das Apps-Verzeichnis übernommen hat. Beim Hochladen mit FTP hatte ich nämlich vergessen, auf binary umzuschalten und stattdessen den Standard ascii belassen. Die ZIP-Datei ist dadurch nicht verwendbar. Ich versuchte diese Datei auf die bei Hobbes angegebene Weise zu löschen. Das funktionierte leider nicht. Zwei bis drei E-Mails an den Hobbes-Support blieben unbeantwortet. Das hing möglicherweise mit der damals in den USA herrschenden Haushaltssperre zusammen, von der ja vermutlich auch die Universitäten betroffen waren.
Als die Version 1.7 aus dem Incoming-Verzeichnis verschwunden war, dachte ich, das Problem ist vom Tisch. Aber stattdessen haben die Kollegen von Hobbes damit die funktionierende Vorgängerversion 1.5 Überschrieben.
In Kürze werde ich die Version 2.0 hochladen, die ich auch bei der WSE2019 gezeigt habe. Ich warte nur auf die Überarbeitung der Dokumentation. Keith Merrington hat sich freundlicherweise bereiterklärt, meinen etwas holprigen Text in guten englischen Stil zu übertragen.
Gruß Wolfgang
Als die Version 1.7 aus dem Incoming-Verzeichnis verschwunden war, dachte ich, das Problem ist vom Tisch. Aber stattdessen haben die Kollegen von Hobbes damit die funktionierende Vorgängerversion 1.5 Überschrieben.
In Kürze werde ich die Version 2.0 hochladen, die ich auch bei der WSE2019 gezeigt habe. Ich warte nur auf die Überarbeitung der Dokumentation. Keith Merrington hat sich freundlicherweise bereiterklärt, meinen etwas holprigen Text in guten englischen Stil zu übertragen.
Gruß Wolfgang
Hallo,
Das erklärt alles...![Zwinkern ;-)](./images/smilies/icon_e_wink.gif)
Ich übe mich dann in Geduld und werde auf die Version 2.0 warten!
Gruß/2
Matthias
Das erklärt alles...
![Zwinkern ;-)](./images/smilies/icon_e_wink.gif)
Ich übe mich dann in Geduld und werde auf die Version 2.0 warten!
Gruß/2
Matthias
Das funktioniert nur kurz nach dem Upload, wie mir Steven geschrieben hat.
Ging bei mir gut. Curtis hat bei mir sogar die fehlerhafte .txt-Datei gefixt, so dass die Einsortierung die .wpi-Datei richtig verarbeiten konnte.
Einfach nochmal E-Mail an Curtis.
Das ist die andere Möglichkeit solche Probleme zu fixen.
Zuletzt geändert von aschn am So 19. Mai 2019, 23:50, insgesamt 1-mal geändert.
Andreas Schnellbacher
Hallo Andreas,
es ist ja nun nicht so, dass ich nicht versucht hätte, das Problem zu lösen, als mich Wilfried ein paar Tage nach dem Upload über das fehlerhafte ZIP-Archiv informierte. Erst der beschriebene Weg des Löschens, an mehreren Tagen. Ich dachte, irgendwann muss es doch klappen. Wer kann denn ahnen, dass das nur kurze Zeit funktioniert. Danach habe ich mich dann per E-Mail an den Archivar gewandt ( archiver@hobbes.nmsu.edu), ich kenne keinen Curtis. Wenn man dann aber auf mehrere E-Mails weder Eingangsbestätigung noch Antwort erhält, resigniert man dann irgendwann.Dass die fehlerhafte Version in dass Apps-Verzeichnis gewandert ist, hatte ich ja erst gestern erfahren, ich schaue ja nun auch nicht jeden Tag bei Hobbes vorbei. Da die Version 2.0 in Kürze fertig sein wird, investiere ich jetzt keine Zeit mehr an die 1.7.
Wer übrigens einen kleinen Vorgeschmack auf die 2.0 bekommen möchte - ich habe ein Video davon erstellt:
youtu.be/hXcY_Bv-7Do (englische Hinweise) bzw. youtu.be/VjLv3Mtlgyo (deutsche Hinweise).
Gruß
Wolfgang
es ist ja nun nicht so, dass ich nicht versucht hätte, das Problem zu lösen, als mich Wilfried ein paar Tage nach dem Upload über das fehlerhafte ZIP-Archiv informierte. Erst der beschriebene Weg des Löschens, an mehreren Tagen. Ich dachte, irgendwann muss es doch klappen. Wer kann denn ahnen, dass das nur kurze Zeit funktioniert. Danach habe ich mich dann per E-Mail an den Archivar gewandt ( archiver@hobbes.nmsu.edu), ich kenne keinen Curtis. Wenn man dann aber auf mehrere E-Mails weder Eingangsbestätigung noch Antwort erhält, resigniert man dann irgendwann.Dass die fehlerhafte Version in dass Apps-Verzeichnis gewandert ist, hatte ich ja erst gestern erfahren, ich schaue ja nun auch nicht jeden Tag bei Hobbes vorbei. Da die Version 2.0 in Kürze fertig sein wird, investiere ich jetzt keine Zeit mehr an die 1.7.
Wer übrigens einen kleinen Vorgeschmack auf die 2.0 bekommen möchte - ich habe ein Video davon erstellt:
youtu.be/hXcY_Bv-7Do (englische Hinweise) bzw. youtu.be/VjLv3Mtlgyo (deutsche Hinweise).
Gruß
Wolfgang
Die E-Mail-Adresse hatte ich auch benutzt. Curtis hat sich darauf gemeldet.
Andreas Schnellbacher
Hallo zusammen,
als Ergebnis der Gespräche mit Wolfie in Utrecht habe ich rxmous mit optionaler Doppelklick Erkennung versehen:
rxmous2.zip z.Zt. in Hobbes incoming.
Frank
als Ergebnis der Gespräche mit Wolfie in Utrecht habe ich rxmous mit optionaler Doppelklick Erkennung versehen:
rxmous2.zip z.Zt. in Hobbes incoming.
Frank
Es hat mit meiner ursprünglichen Anfrage zur Mausklick-Abfrage in eine REXX-Umgebung nur indirekt etwas zu tun, aber ich habe es nun endlich geschafft, meine Version 2.0 von IRxRadio auf Hobbes zu stellen.
Vielen Dank an dieser Stelle nochmals an Frank, der mir mit seine rxmous-Routine die Mausabfrage ermöglicht hat, und an Keith, der das Help-File fachlich und stilistisch überarbeitet hat.
Gruß
Wolfgang
Vielen Dank an dieser Stelle nochmals an Frank, der mir mit seine rxmous-Routine die Mausabfrage ermöglicht hat, und an Keith, der das Help-File fachlich und stilistisch überarbeitet hat.
Gruß
Wolfgang
-
- Beiträge: 5
- Registriert: Do 17. Okt 2019, 19:48
Wolfie hat geschrieben: ↑Mi 5. Dez 2018, 15:32- mruntime ist für mich nicht anwendbar, da es auf einen Mausklick wartet, ich will aber Maus und Tastatur gleichberechtigt benutzen.
Ohne verfügbare Dokumentation kann ich aus dem mitgelieferten Beispiel aber nicht erkennen, wie ich das Warten auf Mausklick abschalten kann.
Code: Alles auswählen
/**/
CALL RxFuncAdd 'MLoadFuncs','M','MLoadFuncs'
CALL MLoadFuncs
CALL MReset
CALL MKeyboard 'ON' /* Mouse + keyboard */
CALL MHotKey 27,255 /* Escape returns 255 */
CALL MHandle 3 /* Cold key? Beep! */
CALL MHot 128 /* Whole screen is a button, returns 128 */
SAY 'Press <ESC> to exit, or press the left mouse button to continue'
IF Mouse()=128 THEN SAY 'Continue... (selected at' MReturnPos() || ')';ELSE SAY 'Exit...'
EXIT
Zuletzt geändert von ARoederer am Fr 18. Okt 2019, 20:34, insgesamt 4-mal geändert.
Grund: MOD: CODE-Tags ergänzt
Grund: MOD: CODE-Tags ergänzt