VisPro REXX (Editor, zusätzliche Objekte)

(DE) Anwendungen für Office, Multimedia und Spiele, Werkzeuge, Hilfsprogramme, etc
(EN) Applications for Office, Multimedia or Games, Tools, Utilities, e.g.
Antworten
Rolf Stephan
Beiträge: 66
Registriert: Fr 3. Jan 2014, 21:16

VisPro REXX (Editor, zusätzliche Objekte)

Beitrag von Rolf Stephan »

Hallo OS/2-Freunde,

Editor:
Der enthaltene Editor scheint mir ein Schwachpunkt dieser ausgeklügelten Entwicklungsumgebung zu sein. Abgesehen davon, daß auch er drag- und dropfähig ist, bietet er ja keinerlei besondere Eigenschaften für das Programmieren.

Nicht mal die Tabs sind einstellbar! Sie sind auf 8 Zeichen gesetzt. Obwohl merkwürdigerweise sie bei eingefügten Vispro-Code nur Zeichen lang sind. Oder gibt es doch Einstellmöglichkeiten, die ich nicht gefunden habe, oder Tricks, die ich nicht kenne?

Meinen gewohnten Editor einbinden möchte ich nicht. Der würde sich leider nicht in das objektorientierte Konzept einfügen.

Zusätzliche Objekte:
Ich habe von Euch ja bereits das Data Entry Objekt Pack erhalten, mit dem ich die Werkzeugleiste mit zusätzlichen Objekten ergänzt habe. Gibt es noch weitere Zusätze?
Beispielsweise zur Gestaltung der Programmoberfläche. Wie unterschiedliche Rahmen und Flächen (box). Zum Beispiel zur Aufnahme von Ikons für eine Toolbar. Auf der CD des 'Das REXX-Buch für OS/2' ist schon ein anpassbares Rahmenobjekt enthalten. Als Rahmen aber eben flächenlos und somit ohne änderbare Hintergrundfarbe, was ich mir aber wünschen würde. Die Vispro Group-Box ist bis auf die Beschriftungsmöglichkeit ebenfalls nur ein Rahmen.

BestenDank,

Rolf Stephan
Benutzeravatar
wilfried
Beiträge: 667
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitrag von wilfried »

Hier findet sich noch einiges http://zeryx.com/English/vpdownload.shtml

Hier einige interessante Codingbeispiele: http://www.pillarsoft.net/os-2-software/rexx/
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Rolf Stephan » Sa 17. Jan 2015, 20:41 hat geschrieben: Der enthaltene Editor scheint mir ein Schwachpunkt dieser ausgeklügelten Entwicklungsumgebung zu sein. Abgesehen davon, daß auch er drag- und dropfähig ist, bietet er ja keinerlei besondere Eigenschaften für das Programmieren.

Nicht mal die Tabs sind einstellbar! Sie sind auf 8 Zeichen gesetzt. Obwohl merkwürdigerweise sie bei eingefügten Vispro-Code nur Zeichen lang sind. Oder gibt es doch Einstellmöglichkeiten, die ich nicht gefunden habe, oder Tricks, die ich nicht kenne?

Meinen gewohnten Editor einbinden möchte ich nicht. Der würde sich leider nicht in das objektorientierte Konzept einfügen.
Der enthaltene "Editor" ist ja wirklich kaum einer. Immerhin lässt sich der Font so einstellen, dass der eingetippte Code noch überschaubar bleibt.

Das "objektorientierte Konzept" gilt für die IDE selbst und mag durchaus für die grafischen Elemente gelten, schließlich leiten sie sich von der WPS ab. Die mitgelieferten VpXXX-Funktionen sind dann aber Schnittstelle zu rein prozeduralem 'classic' Rexx. Da muss man sich dann als User-Entwickler etwas Disziplin einfallen lassen, um dem oo-Konzept näher zu kommen, und schon kommt der (separate!, nicht: eingebundene) Lieblings-Editor sowieso ins Spiel: zum Codieren von "SubProcs".

So gehe ich am liebsten folgendermaßen vor:
(1) Der Code im Event-View-Editor beschränkt sich auf das Definieren GLOBAL verwendeter Variablen und einer höchstens rudimentären Logik mit einem Aufruf einer bestimmten SubProc-Funktion. Oder meinetwegen anfangs mal mehr nur zum "Prototypen". Das macht es im weiteren bequem, mit dessen genannten Schwächen zu leben.
(2) (nahezu) Alle SubProc-Funktionen werden als PROCEDURE deklariert (um möglichst Vieles zu kapseln), ordentlich strukturiert und einheitlich mit einem Return-Wert beendet (notfalls '0'). Nur wo ich darin eigentlich eine Stem-Variable übergeben möchte, muss ich das 'Procedure' weglassen, verberge dann aber wieder möglichst viel Logik in eine oder weitere Unterroutinen davon. Dabei halte ich Routinen, die VpXXX-Funktionen enthalten sollen, möglichst klein und lagere alles rein Fachliche weiter aus. Das alles vernünftig im Lieblings-Editor, das ist viel handlicher und übersichtlicher auch zum Testen und späteren Ändern - und gelegentlichem Wiederverwenden.
(3) Hinterher ist die Gesamtzahl der Zeilen im eingebauten Editor totsicher umgekehrt proportional zur Qualität der eigenen Programmierung :geek:. In einem "echten" Projekt mit interessanter Fachlichkeit können nämlich ganz leicht einige Hundert Lines-of-Code zusammenkommen... :o

Aber nebenbei: der Spass kommt mit dem Einfach-mal-Anfangen :) Das erste Übungsprojekt braucht ja nicht gleich alle verfügbaren grafischen Gimmicks umfassen. Die Überraschungen beim Testen kommen nach und nach ganz von alleine :mrgreen:
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Ich stimme Lothar zu, wobei ich gerne den (recht primitiven) internen Editior benutze und vieles direkt in die Events reinschreibe. Subprozeduren im Sinne von externen Dateien benutze ich meistens nur für Funktionen, die ich öfter benutze, und sonst mehrfach den gleichen Code im Programm hätte. Ein schickes Feature ist Multithreading, wenn die Proceduren zu lange brauchen und die Oberfläche blockieren würden, kannst Du die Prozeduren in eigenen Threads starten.

Du wirst noch auf einige andereLimitierungen in Vispro kommen. Es geht nicht alles, was unter os2 möglich wäre. Aber im Vergleich ist Vispro schon extrem leistungsfähig.

Eine Toolbar kannst Du Dir zB. mit Buttons (Knöpfen) erstellen. Statt Text kannst Du auch Icons oder Bitmaps in die Buttons laden. Alternativ kannst Du auch ein Container-Objekt benutzen, und dort Icons reinladen, und diese mit entsprechenden Fuktionen belegen (etwas auwendiger). Container sind ev. nicht gerade was für Einsteiger (es ist aber auch keinen Zauberei). Die Container müssen korrekt eingerichtet werden (teilweise auch mit Code, nicht alles geht über die Einstellungsseiten des Objektes). Manche Grafiksachen sieht man allerdings auch erst nach einem Build, d.h. beim Testen (starten aus der Entwicklungsumgebung) werden diese nicht angezeigt. Ich hab jetzt nicht im Kopf, wo sich das genau so verhält, aber wenn Du mal was nicht seihst einfach mal einen Build machen und run.exe starten.

Man kann auch Objekte überlappen lassen, und zB. mit dem Grafikobjekt die Oberfläche gestalten. Es gibt auch eine Transparent-Funktion (Clip...) Allerdings führt das manchmal zu Redraw-Problemen und unschönen Effekten, deshalb verzichte ich darauf.

Die einfachste Toolbar wäre eine Anreihung von Buttons, in die die Bitmaps lädtst, zB. wie hier in einem Addressmanager:
http://subsys.de/contact/gif/!main.gif
Rolf Stephan
Beiträge: 66
Registriert: Fr 3. Jan 2014, 21:16

Beitrag von Rolf Stephan »

Danke, für den Link zu den zusätzlichen VisPro REXX Objekten.

Was den Editor betrifft, hatte ich gehofft, daß es doch noch Einstellmöglichkeiten gibt. Gar nicht zu fassen, daß dieses wichtige Werkzeug so vernachlässigt wurde. Die Vorstellung, für den erklickten Code und den zu schreibenden unterschiedlichen Editoren zu gebrauchen, gefällt mir gar nicht.

Bislang schrieb ich mein Programm - auch objektorientiert -,mit einem sehr anpassbaren Editor (konfigurierbares Syntax highlightning) compilierte und linkte es und fügte Resourcen hinzu. Mit einem Editor und einem OS/2-Fenster.

Ich bin die drei Programmbeispiele von Vispro durchgegangen. Es macht mir auch Spaß mit diesem raffinierten Baukasten zu arbeiten und zu probieren, auf diese Weise zu programmieren. Aber gerade wenn es umfangreicher wurde, wie beim anlegen weiterer Formulare (Fenster) und Bezüge zwischen ihnen herzustellen, wurde es mir doch ganz schön unübersichtlich und unverständlich. Was klicke ich in welchem Fenster und von wo ziehe ich etwas wohin. Noch nie hatte ich auf meinem Desktop deratig viele Fenster auf einmal geöffnet. Es herrscht regelrecht Platzmangel und die Fenster sind gelegentlich zu verschieben, daß man zwei durch drag und drop erreicht. Und dabei sind lleider die großzügig dimensionierten, immer wieder benötigten Setting-Fenster nicht dauerhaft kleiner zu stellen.

Frank, auf was für eine Datenbank greifst Du in dem Contact/2 (Dein Screenshot) zu?

Die von mir erwähnte Toolbar war ja nur ein Beispiel. Allgemein ging es mir um Gestaltungsmöglichkeiten der Programmoberfläche. Mein XBase++ stellt konfigurierbare Flächen und Rahmen zur Verfügung, die auch als Hintergrund für Pushbuttons, Eingabefelder, usw. verwendet werden können.

Ich werde bestimmt noch mit der einen oder anderen Frage auf Euch zukommen.

Besten Dan, für Eure Antworten,

Rolf Stephan
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Rolf Stephan » So 18. Jan 2015, 21:16 hat geschrieben: Was den Editor betrifft, hatte ich gehofft, daß es doch noch Einstellmöglichkeiten gibt. Gar nicht zu fassen, daß dieses wichtige Werkzeug so vernachlässigt wurde. Die Vorstellung, für den erklickten Code und den zu schreibenden unterschiedlichen Editoren zu gebrauchen, gefällt mir gar nicht.
Dafür ist das Werkzeug mittlerweile gratis :D. Die (berechtigte) Kritik an den verbliebenen Schwächen erreicht keinen Autor mehr, also wird sich nichts mehr am Tool ändern, wir können uns nur schlau damit arrangieren.

Ich kenne auch keine IDE, die am Ende nicht ohne separaten - oder zumindest: aufklappbaren - Editor auskäme. Der in Visprorexx integrierte (Pseudo-)Editor ist doch nur etwas zum schnellen Prototyping im Anfangsstadium eines Projekts oder einfach so zum Üben (staune aber, was Frank trotzdem damit schafft :roll: ). Es ist m.E. ein Unding, dass ich zu jedem Fenster-Objekt einen eigenen Editor benutzen soll. Will ich einen 'Link' etc. von einem Objekt her 'ziehen', dann landet der halt per "Einfügen/Paste" in meinem Lieblings-Editor und fertig. Dort ist dann zu >90% mein gesamter handgetippter und sonstiger Code versammelt., ordentlich strukturiert und aufgeräumt (-meine- Aufgabe...), damit ich auch was wiederfinde. Stichwort: "single point of control". Aber jeder auf seine Weise :)

Die schönen Drag&Drop-Operationen sind zwar nützlich und machen Eindruck in Präsentationen; sie werden vor allem gern budget-verantwortlichen Managern "verkauft", die dann auch noch echt glauben, so ein Software-Projekt sei damit -wusch- fertig. :evil:
Beispiel "VisualAge": Was lassen sich da endlos viele bunte Pfeile quer über den Bildschirm ziehen, Popups öffnen und den andächtigen Betrachter entzücken ;) . Guckt man sich aber im (zugehörigen Lpex-) Editor den produzierten Code an, so geht's zuerst ans Glätten und Ausmisten, bevor man die komplexe Fachlichkeit hinter jedem Button doch zeichenweise von Hand eintippen muss. Wie sollte es auch anders gehen. Ich hab's aber damit aufgegeben und bin inzwischen mit Rexx (und PHP...) als Gelegenheits-Hobby ganz zufrieden :D Umso mehr Respekt habe ich deshalb vor jedem aktiven "richtigen" Entwickler, ob Profi- oder Freizeit-Experte.
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hi Lothar, ich bin halt mit e.exe aufgewachsen. ;)

Drag'n Drop ist immer gut bei kleiner Anzahl der Objekte bzw. bei einem kleinen oder einfachen Projekt. Ich benutze das üblicherweise nicht. Wenn ich mehrere Forms (Fenster) habe, dann baue ich die nacheinander, aus genau den von Rolf genannten Gründen der Übersichtlichkeit. Objektorientierung auf der WPS zB. mit Daten macht ja auch nur Sinn, wenn es nicht zu viele sind. Die Link-Funktionen nutze ich auch nie. Ich arbeite immer mit Copy and Paste, oder ich tippe die Sachen halt schnell ein.

Für ein wirklich kompliziertes und oder langes Script benutze ich EPM bzw. NEPM. Manchmal benutze ich auch den VIO Editor aus FC2.
Rolf Stephan
Beiträge: 66
Registriert: Fr 3. Jan 2014, 21:16

Beitrag von Rolf Stephan »

Lothar, wenn ich Dich richtig verstehe, kreierst Du mit VisPro REXX die Objekte, gestaltest die Oberfläche, erzeugst Events und Methoden. Mit VisPro erzeugst Du das objektorientierte Programmgerüst. Allen weiteren Code schreibst Du dann in eigenen Prozeduren oder Funktionen, die Du im Projektordner SUBPROCS ablegst, wo sie von VisPro berücksichtigt werden. Für die eigene Programmierung nutzt Du einen bestimmten Editor, für die Vorarbeit den von VisPro.

So würde ich wohl auch vorgehen, um den VisPro-Editor möglichst zu meiden. Obwohl mir diese Trennung nicht gefällt. Die mit VisPro erzeugten Ereignisse und und eingesetzten Methoden bilden zusammen mit den 'SubProcs' den Programmcode. Der gehört über- und durchschaubar in einen Editor. (Bei sehr kleinen Programmen, denen je Ereigniss nur wenig selbstgeschriebene Zeilen hinzugefügt werden müssen, würde ich wohl ganz auf einen zweitenEditor verzichten).

Trotzem würde mich interessieren, wie ich einen externen Editor einbinden kann und was er eigentlich bei der Erzeugung von Ereignissen (When ...) und Methoden (Create link ...) übernimmt. Ich habe VisPros Vorschlag des EPM.EXE mitsamt den Parametern %0 '%1' mal übernommen - und gleich welche Aktion ausgefüht wird: in EPM regt sich nichts. Auch ein Paste nach einem Create Link zeigtkeine Auswirkung. Bis daß ein Dateiname in die Kopfzeile gesetzt wird - wohl die Folde der Parameterübergabe.

Mit globalen Variablen (unter (1)) meinst Du hier eine Sichtbarkeit innerhalb des Formulars in dem sie vereinbart werden und seinen Subroutinen und weiteren daraus möglicherweise aufgerufenen Formularen und Subroutinen? (Bevor ich mich mit REXX befaßte, bedeutete nämlich global für mich programmweit).

Frank, auf welche Datenbank (dBase, DB2, ...) greifst Du in Deinem Programm Contact/2 zu? Wie können Linien erzeugt werden, wie Du sie zur Absetzung Deiner Toolbar verwendest?

Gruß,

Rolf Stephan
Benutzeravatar
Frank Wochatz
Beiträge: 1112
Registriert: So 22. Dez 2013, 22:04
Wohnort: Berlin
Kontaktdaten:

Beitrag von Frank Wochatz »

Hallo Rolf,

die Daten werden in Contact/2 einfach in eine Datei geschrieben. Ich benutze dazu das OS2-eigene INI Format. Dafür gibt es Rexx Routinen (SysIni) zum Lesen und Schreiben. Den Rest habe ich selber mit Rexx programmiert. Ich kann das bei Bedarf gerne mal genauer erklären. Das die Lese- und Schreibzugriffe standardmäßig mit Sysini etwas langsam sind (bei vielen Datensätzen, die Inis werden nach jeden Einzel-Zugriff geschlossen) benutze ich weiterhin die fastini.dll. Mit Fastini werden die Inis beim Initialisieren angezogen, und dann geht alles deutlich schneller.

Die Linien sind glaube ich (muss morgen mal nachsehen, bin grad auf Windows) einfach Group-Rahmen, die breiter sind als das Fenster und damit links und rechts nicht sichtbar sind, da die linke und rechte Seite außerhalb des Fensters liegen. Schwer zu erklären, ich hoffe Du verstehts was ich meine.


Grüße
Frank
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

Rolf Stephan » Fr 23. Jan 2015, 20:14 hat geschrieben: Mit globalen Variablen (unter (1)) meinst Du hier eine Sichtbarkeit innerhalb des Formulars in dem sie vereinbart werden und seinen Subroutinen und weiteren daraus möglicherweise aufgerufenen Formularen und Subroutinen?
Richtig, im Prinzip ;)
Grundsätzlich strebe ich an, Rexx-Module (=Unterroutinen) als PROCEDURE zu definieren. Dann ist der Datenfluss von/nach "außen" per (parse) Arg bzw. Return klar und alles Innere bleibt lokal versteckt. Die Event-Module in Vispro-Rexx sind jedoch offen (nicht-Procedure), damit sind alle dort benutzten Variablen automatisch anwendungsweit sichtbar. Das kann riskant sein (naja: oder lästig...), deshalb stecke ich gern die ganze "Fachlichkeit" (Datenaufbereitung, -zugriffe) in eine ausgelagerte SubProc. Andererseits kann es aber auch nützlich sein, wenn ich mich für wenige bewusst "globale" Variablen nicht lehrbuchmäßig verrenken wollte. Nebenbei: das Übergeben von Stem.s geht nicht in Procedures, dann sollte man sie halt im Auge behalten und wenigstens auffällig benamsen. Allein die Tatsache, dass zu jedem neuen "Project" gleich ein SubProcs-Ordner mitgeliefert wird, ruft eigentlich danach, den auch zu benutzen :)
Was generell solche Modularisierung betrifft, bin ich ein Anhänger von "Structured Design" (Buch von Yourdon/Constantine, oder ganz kurz hier skizziert). Diese Prinzipien finden sich stringenter im objektorientierten Design wieder. Nur offtopic am Rande :geek:
Trotzem würde mich interessieren, wie ich einen externen Editor einbinden kann
Da bin ich mehrfach überfragt. :( Aber ich kann damit leben, solange der Code im "Event-Editor" (immerhin objektorientiert!) nur aus ein paar Zeilen Steuerung besteht und der eigentliche Tanz im separaten Editor stattfindet. Vor Zeiten hatte ich für mich den "MEd" entdeckt, mit allem, was ein Programmierer-Editor so mindestens haben sollte. Für meine geringen Belange reicht's.
Benutzeravatar
wilfried
Beiträge: 667
Registriert: Mo 23. Dez 2013, 18:26
Wohnort: Barsinghausen
Kontaktdaten:

Beitrag von wilfried »

LotharS » Sa 24. Jan 2015, 11:45 hat geschrieben:
Rolf Stephan » Fr 23. Jan 2015, 20:14 hat geschrieben: Die Event-Module in Vispro-Rexx sind jedoch offen (nicht-Procedure), damit sind alle dort benutzten Variablen automatisch anwendungsweit sichtbar.
...
Nebenbei: das Übergeben von Stem.s geht nicht in Procedures,
Ich werfe mal meine "two cents" dazu. ;-)
Wenn Du Event-Module kapseln willst, steck den Code in eine Subproc-Datei und schreibe im Event nur den Call darauf.

Zu der Aussage über Stems im Zusammenhang mit Procedures muss ich widersprechen. Kennst Du diese Schreibweise?
ROUTINE: procedure expose stem_name.
Der abschliessende '.' ist wichtig. Damit werden alle Stem-Elemente sichtbar.
Problematisch wird es nur wenn man Threads oder externe Rexx-Programme mit dem Inhalt von Stems oder anderen Variablen versorgen muss. Aber auch dafür gibt es eine Umgehungslösung. Ich lege dann die entsprechenden Wertzuweisungen in eine Queue oder auf den Stack (je nach Situation) und lese die im Thread oder externen Rexx-Programm aus und wende sie mit INTERPRET an.
Es gibt allerdings auch eine, etwas umständliche, Vispro/Rexx-spezifische Lösung (siehe VpAppVariable).
Benutzeravatar
LotharS
Beiträge: 968
Registriert: So 29. Dez 2013, 20:07
Wohnort: Düsseldorf
Kontaktdaten:

Beitrag von LotharS »

wilfried » Sa 24. Jan 2015, 12:08 hat geschrieben: Der abschliessende '.' ist wichtig.
ach: auf den eigentlich so nahe liegenden PUNKT war ich nie gekommen :oops: :evil:
Danke für den super Tipp :D
Antworten