Liebe KollegInnen, lieber Herr Prof. Flatscher,
meine Kollegin Martina und ich würden um Hilfe bei einem Problem bitten, an dem wir uns schon seid 2 Tagen die Zähne ausbeissen:
Um einige Werte aus einer Routine in einer anderen verwenden zu können, möchten wir diese in den GlobalScope schreiben. Aus uns unbekannten Gründen funktioniert dies bei unserem Programm nur nicht, es wird kein Wert übertragen. Leider erhalten wir gleichzeitig auch keine Fehlermeldung, die uns eventuell weiterhelfen könnte. Wahrscheinlich liegt irgendein banaler Fehler vor, wir sehen allerdings "den Wald vor lauter Bäumen nicht mehr".
EIn Kollege aus dem Kurs hatte sich dankenswerterweise den Code schon einmal angesehen, konnte uns aber auch nicht weiterhelfen. Daher kommen wir nun auf alle im Verteiler zurück.
Anbei findet ihr das betroffene Programm; es geht konkret um die Routine "VokFertig" (Codezeilen 74 - 104) bzw. "VokAuswertung" (Codezeilen 166 - 171).
Wir sind für jeglichen Input dankbar
Christopher & Martina
Lieber Herr Herrmann,
eine Antwort, nachdem wahrscheinlich niemand Ihnen hier zeitnah helfen kann (im Unterschied zu den Fragen der Gruppe, die momentan mit JDBC Probleme hat).
Eine Frage vorab: ich habe mir als Gruppe 3 die Herren Herrmann und Landa notiert, nicht Frau Oppermann, die mit Herrn Letenyei als Gruppe 4 führe, ist die Gruppenzusammensetzung eine andere oder arbeiten Sie gruppenübergreifend zusammen (was durchaus erwünscht wäre)?
Einige Anmerkungen zu ihrem Rexx-Programm:
* es ist nicht notwendig, dass Sie bsf.import() aufrufen (die import-Anweisung in Java ist hingegen notwendig, damit der Compiler genau weiß, welche Javaklassen das Programm benötigt); bsf.import() ist dafür da, eine Java-Klasse als Rexx-Klasse zu importieren, sodass man der Proxy-Rexx-Klasse einfach mit der Nachricht "new" neue Instanzen der Java-Klasse erzeugen kann (wie wenn es sich wirklich um eine Rexx-Klasse handeln würde); in Ihrem Programm verwenden Sie .bsf~new(javaklasse), was genau im Sinne des Erfinders ist! :)
* das ScriptContext-Objekt existiert solange die Javaseite eine Referenz darauf vorhält; abhängig von der Ausführungslogik kann es sein, dass beim nächsten Aufruf ein neues ScriptContext-Objekt erzeugt wird, sodass Ihre Einträge dann nicht mehr enthalten sind,
* eine mögliche Lösung ist, dass Sie die ooRexx-Umgebung verwenden, im Konkreten die globale Umgebung namens ".environment", die immer allen Rexxinterpreterinstanzen zur Verfügung steht; in Ihrem Fall könnte dies z.B. wie folgt aussehen:
... .environment~a.eingabe =eingabe~getText .environment~a.eingabe1=eingabe1~getText ... .environment~a.eingabe4=eingabe4~getText ...
Anschließend können Sie von jedem Rexxprogramm im selben Prozess wie folgt zugreifen:
... say .a.eingabe /* oder auch: say .environment~a.eingabe */ say .a.eingabe1 /* oder auch: say .environment~a.eingabe1 */ ... say .a.eingabe4 /* oder auch: say .environment~a.eingabe4 */ ...
Einträge in den ooRexx-Umgebungen .environment, .local sowie .context~package~local werden in Rexx-Directories gespeichert. Der Zugriff auf Einträge in diesen ooRexx-Umgebungen kann mit Umgebungssymbolen erfolgen. Umgebungssymbole beginnen mit einem Punkt, gefolgt vom Namen des Eintrags. ooRexx wird dann automatisch die ooRexx-Umgebung in der Reihenfolge .cotext~package~local -> .local -> .environment nach Einträgen durchsuchen und den ersten Treffer mit dem gespeicherten Wert zurückgeben.
Viel Erfolg!
Mit freundlichem Gruß
Rony G. Flatscher
On 26.01.2022 23:17, Christopher Herrmann wrote:
Liebe KollegInnen, lieber Herr Prof. Flatscher,
meine Kollegin Martina und ich würden um Hilfe bei einem Problem bitten, an dem wir uns schon seid 2 Tagen die Zähne ausbeissen:
Um einige Werte aus einer Routine in einer anderen verwenden zu können, möchten wir diese in den GlobalScope schreiben. Aus uns unbekannten Gründen funktioniert dies bei unserem Programm nur nicht, es wird kein Wert übertragen. Leider erhalten wir gleichzeitig auch keine Fehlermeldung, die uns eventuell weiterhelfen könnte. Wahrscheinlich liegt irgendein banaler Fehler vor, wir sehen allerdings "den Wald vor lauter Bäumen nicht mehr".
EIn Kollege aus dem Kurs hatte sich dankenswerterweise den Code schon einmal angesehen, konnte uns aber auch nicht weiterhelfen. Daher kommen wir nun auf alle im Verteiler zurück.
Anbei findet ihr das betroffene Programm; es geht konkret um die Routine "VokFertig" (Codezeilen 74 - 104) bzw. "VokAuswertung" (Codezeilen 166 - 171).
Wir sind für jeglichen Input dankbar
Christopher & Martina
Werter Herr Prof. Flatscher,
Vielen Dank für ihre schnelle Rückmeldung und ihre Ausführungen.
Bez. Ihrer Frage zur Gruppenzusammensetzung: Sie meinten zu Beginn des Kurs 2, es würde die selbe Zusammensetzung wie in Kurs 1 gelten, die meines Wissens nach wie folgt ist:
Gruppe 3: Letenyei & Hashem Gruppe 4: Herrmann & Oppermann
Der Kollege Landa ist mit Wang & Zhulov in Gruppe 5.
Liebe Grüße Christopher Herrmann
Rony G. Flatscher Rony.Flatscher@wu.ac.at schrieb am Do. 27. Jän. 2022 um 12:43:
Lieber Herr Herrmann,
eine Antwort, nachdem wahrscheinlich niemand Ihnen hier zeitnah helfen kann (im Unterschied zu den Fragen der Gruppe, die momentan mit JDBC Probleme hat).
Eine Frage vorab: ich habe mir als Gruppe 3 die Herren Herrmann und Landa notiert, nicht Frau Oppermann, die mit Herrn Letenyei als Gruppe 4 führe, ist die Gruppenzusammensetzung eine andere oder arbeiten Sie gruppenübergreifend zusammen (was durchaus erwünscht wäre)?
Einige Anmerkungen zu ihrem Rexx-Programm:
- es ist nicht notwendig, dass Sie bsf.import() aufrufen (die
import-Anweisung in Java ist hingegen notwendig, damit der Compiler genau weiß, welche Javaklassen das Programm benötigt); bsf.import() ist dafür da, eine Java-Klasse als Rexx-Klasse zu importieren, sodass man der Proxy-Rexx-Klasse einfach mit der Nachricht "new" neue Instanzen der Java-Klasse erzeugen kann (wie wenn es sich wirklich um eine Rexx-Klasse handeln würde); in Ihrem Programm verwenden Sie .bsf~new(javaklasse), was genau im Sinne des Erfinders ist! :)
- das ScriptContext-Objekt existiert solange die Javaseite eine
Referenz darauf vorhält; abhängig von der Ausführungslogik kann es sein, dass beim nächsten Aufruf ein neues ScriptContext-Objekt erzeugt wird, sodass Ihre Einträge dann nicht mehr enthalten sind,
- eine mögliche Lösung ist, dass Sie die ooRexx-Umgebung verwenden, im
Konkreten die globale Umgebung namens ".environment", die immer allen Rexxinterpreterinstanzen zur Verfügung steht; in Ihrem Fall könnte dies z.B. wie folgt aussehen:
... .environment~a.eingabe =eingabe~getText .environment~a.eingabe1=eingabe1~getText ... .environment~a.eingabe4=eingabe4~getText ...
Anschließend können Sie von jedem Rexxprogramm im selben Prozess wie folgt zugreifen:
... say .a.eingabe /* oder auch: say .environment~a.eingabe */ say .a.eingabe1 /* oder auch: say .environment~a.eingabe1 */ ... say .a.eingabe4 /* oder auch: say .environment~a.eingabe4 */ ...
Einträge in den ooRexx-Umgebungen .environment, .local sowie .context~package~local werden in Rexx-Directories gespeichert. Der Zugriff auf Einträge in diesen ooRexx-Umgebungen kann mit Umgebungssymbolen erfolgen. Umgebungssymbole beginnen mit einem Punkt, gefolgt vom Namen des Eintrags. ooRexx wird dann automatisch die ooRexx-Umgebung in der Reihenfolge .cotext~package~local -> .local -> .environment nach Einträgen durchsuchen und den ersten Treffer mit dem gespeicherten Wert zurückgeben.
Viel Erfolg!
Mit freundlichem Gruß
Rony G. Flatscher
On 26.01.2022 23:17, Christopher Herrmann wrote:
Liebe KollegInnen, lieber Herr Prof. Flatscher,
meine Kollegin Martina und ich würden um Hilfe bei einem Problem bitten, an dem wir uns schon seid 2 Tagen die Zähne ausbeissen:
Um einige Werte aus einer Routine in einer anderen verwenden zu können, möchten wir diese in den GlobalScope schreiben. Aus uns unbekannten Gründen funktioniert dies bei unserem Programm nur nicht, es wird kein Wert übertragen. Leider erhalten wir gleichzeitig auch keine Fehlermeldung, die uns eventuell weiterhelfen könnte. Wahrscheinlich liegt irgendein banaler Fehler vor, wir sehen allerdings "den Wald vor lauter Bäumen nicht mehr".
EIn Kollege aus dem Kurs hatte sich dankenswerterweise den Code schon einmal angesehen, konnte uns aber auch nicht weiterhelfen. Daher kommen wir nun auf alle im Verteiler zurück.
Anbei findet ihr das betroffene Programm; es geht konkret um die Routine "VokFertig" (Codezeilen 74 - 104) bzw. "VokAuswertung" (Codezeilen 166 - 171).
Wir sind für jeglichen Input dankbar
Christopher & Martina
--
Prof. Dr. Rony G. Flatscher Department Wirtschaftsinformatik und Operations Management Institut für Wirtschaftsinformatik und Gesellschaft D2c 2.086 WU Wien Welthandelsplatz 1 A-1020 Wien/Vienna, Austria/Europe http://www.wu.ac.at __________________________________________________________________________________
-- Aj2021w mailing list Aj2021w@alice.wu.ac.at http://alice.wu.ac.at/mailman/listinfo/aj2021w
-
Christopher Herrmann -
Rony G. Flatscher