Inoffizielles deutsches Xbase-Forum

Hallo,

ich hab beruflich wieder mit Xbase++ zu tun. Jetzt würde ich gerne wieder in die Sprache reinkommen und ein paar Dinge ausprobieren. Gibt es nicht einen Interpreter oder ein kleines Programm, mit dem man 'on the fly' Variablen deklarieren und direkt verwenden kann?

Ich meine mich zu erinnern, dass das mit dem Debugger möglich war, wenn man mal ein Programm im Debugging-Mode aufgerufen hatte.

Sebastian

Moin,

wenn Du mit der Workbench arbeitest gibt es dort das Befehlsfenster. Da kann man Funktionen aufrufen und Variablen belegen. Achtung. In den allermeisten Fällen ist es sinnvoll bis wichtig, die Zeile mit einem . zu beginnen.

Jan

Danke Jan,

ich hab zuletzte mit der 1.90.331 gearbeitet. Was ist denn die Workbench?

Sebastian

Hallo Sebastian,

OK, in der 1.9 gab es nur VX als Vorgänger der Workbench. Das extra installiert werden muß (schau mal die CD durch, da gibt es ein Verzeichnis VXW32), und nicht so viel kann wie die Workbench. Ich weiß nicht mehr ob das auch ein Befehlsfenster hatte. Müsstest Du mal ausprobieren.

Jan

ja, hatte sie. War eigentlich auch sehr ähnlich der WB von heute

Einen Interpreter - eigentlich aber reden wir über ein CLI, denn ein Interpreter arbeitet anders - kann man sich relativ einfach selbst bauen, über die Makrofähigkeit von Xbase++. Für Funktionsaufrufe geht das sogar fast ohne Vorarbeiten (einfach nur klammern und ein & davorsetzen und dann ausführen - oder einen Codeblock bauen und Eval() nutzen), bei Kommandos muss man ein bisschen tricksen (indem man den PP verwendet), ebenso für die Verwendung von Includes. Dinge wie LOCALs usw. gehen da natürlich nicht. Die Gegenfrage aber lautet: Wozu?

oder ein kleines Programm, mit dem man 'on the fly' Variablen deklarieren und direkt verwenden kann?

Eine Variable, die man über ein CLI instantiiert (x := 'Hallo') ist automatisch PRIVATE aus Sicht des CLI. Würde man im CLI also in der Folge eine Funktion oder Prozedur aufrufen, die eine solche Variable verwendet, ginge das. Andersherum geht es nicht, also quasi nach oben.

Hallo Sebastian

klammerauf hat geschrieben: ↑Do, 21. Sep 2023 7:40 Gibt es nicht einen Interpreter oder ein kleines Programm, mit dem man 'on the fly' Variablen deklarieren und direkt verwenden kann?

Als Gedankenanstoß...
Aufruf der Funktion irgendwo, irgendwann im Programm
Alle eingetragenen Variablen werden in diesem Beispiel "public" deklariert und sind somit
ab dem Zeitpunkt des Aufrufes der Funktion global verwendbar.

Warum wir das überhaupt so angedacht haben ist relativ einfach.
Trotz aller Akribie und Checks ist irgendwo eine Variable nicht deklariert und nur die Aktion eines
Users bringt eines Tages diesen Fehler zum Vorschein.
Statt einem Bugfix und Update können wir dann alleine durch das Speichern dieser Datei
am PC beim betroffenen Kunden SOFORT das Problem zumindest via diesem "Workaround" beseitigen.
Das erspart ein sofortiges Update und ein Rollup an alle Kunden dieses Programms.
Unsere Programme rufen diese Funktion gleich zu Beginn auf.

Aber natürlich ist diese Funktion auch entsprechend adaptiert wohl auch im Sinne von Sebastian eine Möglichkeit.

Code: Alles auswählen

FUNCTION VARIABLENPUSHUP()
*************************************
LOCAL i, s_x, s_t, s_td, t_tx, t_ty, x_ty
if file("VARIABLEN.DEF")
   s_x:=charrem(chr(10)+chr(26),filestr("VARIABLEN.DEF"))
   s_t:=numat(chr(13),s_x)

   for i=1 to s_t
        s_td:=token(s_x,chr(13),i)
        t_tx:=token(s_td,"\",1)
        public &t_tx                   // HIER PASSIERT ES, Variable wird zur Laufzeit "public" erstellt
        t_ty:=token(s_td,"\",2)
        &t_tx:=&t_ty                 // HIER PASSIERT ES, zur Laufzeit "public" erstellte Variable wird mit Defaultwert befüllt

        x_ty:=token(s_td,"\",3)
        if x_ty="D"            // falle erwünscht umwandeln in Datumsformat
           &t_tx:=ctod(&t_tx)
        endif

        // Nur zur Kontrolle falls etwas unklar ist oder sonstwas
        if valtype(&t_tx)="N"
           ** msgbox(t_tx+" = "+str(&t_tx))
        elseif valtype(&t_tx)="C"
           ** msgbox(t_tx+" = "+&t_tx)
        elseif valtype(&t_tx)="D"
           ** msgbox(t_tx+" = "+dtoc(&t_tx))
        elseif valtype(&t_tx)="L"
           ** msgbox(t_tx+" = "+iif(&t_tx=.t.,"TRUE","FALSE"))
        endif
    next
endif
RETURN(.T.)

Inhalt der Datei VARIABLEN.DEF Beispiel
my_var1\"Mustertext"\
my_var2\13.7603\
my_var3\.t.\
my_var4\.f.\
my_var5\"31.12.2023"\D\

Boa, schon mal was vom Compilerschalter /w und /wu gehört? Dann ist das alles überflüssig und der Code ist von Anfang an sauber. Wer es auf die Spitze treiben will, verwendet noch zusätzlich /wl.

Wrner,

so wie ich Sebastians Frage verstehe will er nicht sicher stellen, das alle genutze Variablen auch sauber deklariert sind, und alle deklarierten Variablen auch genutzt werden. Sondern das er während eines Debugger-Laufes Variablen neu belegen kann. das funktioniert meines Wissens nicht per Compiler-Schalter.

Ich selber nutze übrigens standardmäßig /wi /wl /wu /w. Hilft enorm. Aber eben nicht bei dem was Sebastian sucht.

Jan

Mein Beitrag bezieht sich auf Flanelli.

Werner,

ah, OK. Da macht das Sinn. Sorry, das hatte ich falsch zugeordnet.

Dein Vorschlag gegenüber Flanelli ist absolut korrekt. Ich erkenne lieber schon beim Kompiliren, ob ich vergessen habe etwas zu deklarieren, als in der Bananenware beim Kunden. Und wenn ich wie von Dir vorgeschlagen den passenden Schalter setze erkenn ich auch, welche Variable ich inzwischen eventuell nicht mehr nutze. Was bei PUBLICs nicht geht.

Jan

und alles PUBLIC setzen, war irgendwie noch nie eine gute Idee.
Aber vielleicht meinte Flanelli auch was ganz anderes?

PUBLICs haben zwei Nachteile - ihr Zugriff ist (u.U. aber kaum spürbar) langsamer als auf LOCALs und sie sind weder gekapselt, noch (im Gegensatz zu PRIVATEs) threadsafe. Dafür sind sie in alle Richtungen - auch im Gegensatz zu PRIVATEs sogar nach oben - sichtbar und können in Makros verwendet werden. Wenn PUBLICs ein No-Go wären, würde es sie nicht geben. Manchmal ist das ziemlich hilfreich, und gerade bei stark datengetriebenen Anwendungen kommt man nicht drumherum. Ich würde also niemanden dafür verurteilen, obwohl ich selbst weitgehend auf sowas verzichte. Wenn man nicht sauber arbeitet und z.B. Hilfsvariablen immer gleich benennt, kackt man sich auf den eigenen Teppich, wenn man sie nicht als LOCALs deklariert.

Der größte Vorteil von PUBLICs besteht darin, dass sie selbstdeklarierend sind, und dass das auch von außen und von oben geht.

Hallo Werner,

Werner_Bayern hat geschrieben: ↑Do, 21. Sep 2023 22:52 Boa, schon mal was vom Compilerschalter /w und /wu gehört? Dann ist das alles überflüssig und der Code ist von Anfang an sauber. Wer es auf die Spitze treiben will, verwendet noch zusätzlich /wl.

Selbstverständlich sind diese Compilerschalter bekannt und dennoch ist, jedenfalls für unsere insgesamten
Überlegungen und Einsatzmöglichkeiten "das alles" absolut nicht überflüssig.

"Warum wir das überhaupt so angedacht haben"
"Aber natürlich ist diese Funktion auch entsprechend adaptiert wohl auch im Sinne von Sebastian eine Möglichkeit."

Wie angemerkt, ist diese Funktion in abgewandelter Form, bei entsprechend sorgfältiger Wahl der Variablennamen
für so manches absolut effizient einsetzbar.
In unserem Fall nutzen wir diverse Varianten z.B.: für eine spezielle Abwicklung unseres selbsterstellten Listgenerators und können dadurch, ohne den Source anzugreifen sehr einfach und vor allem sehr rasch ganz individuelle Lösungen für Kunden generieren. Auch für diverse Schnittstellen war und ist eine Variante des Grundgedankens sehr hilfreich und produktiv.

Wir bevorzugen halt die Devise, den Blick stets ein wenig über den Tellerand hinaus zu richten und über 30 Jahre
recht erfolgreichen Daseins in der Konzeption und Programmierung von flexiblen und sehr stabilen Programmen
mit einem breitgefächerten großen Kundenstock gaben und geben uns die positive Bestätigung.

Hallo Tom,

Tom hat geschrieben: ↑Fr, 22. Sep 2023 13:07 PUBLICs haben zwei Nachteile - ihr Zugriff ist (u.U. aber kaum spürbar) langsamer als auf LOCALs und sie sind weder gekapselt, noch (im Gegensatz zu PRIVATEs) threadsafe. Dafür sind sie in alle Richtungen - auch im Gegensatz zu PRIVATEs sogar nach oben - sichtbar und können in Makros verwendet werden. Wenn PUBLICs ein No-Go wären, würde es sie nicht geben. Manchmal ist das ziemlich hilfreich, und gerade bei stark datengetriebenen Anwendungen kommt man nicht drumherum. Ich würde also niemanden dafür verurteilen, obwohl ich selbst weitgehend auf sowas verzichte. Wenn man nicht sauber arbeitet und z.B. Hilfsvariablen immer gleich benennt, kackt man sich auf den eigenen Teppich, wenn man sie nicht als LOCALs deklariert.

Der größte Vorteil von PUBLICs besteht darin, dass sie selbstdeklarierend sind, und dass das auch von außen und von oben geht.

Besser kann man es nicht darstellen...
Da wir zwangsläufig schon immer gewohnt sind sauber zu arbeiten ( anderenfalls hätten wir die "grausame" Zeit mit 640 kb Ram bzw. 1 MB extended mit komplexen "Monster"applikationen sicher nicht überlebt ), haben wir bis dato noch nie auf den eigenen Teppich gekackt ( auf andere tun wir das natürlich auch nicht

).
Zudem setzen wir solche Funktionen insgesamt ja für spezielle Abläufe ein und da ist ohnehin eine ganz besondere Akribie
vonnöten um sich nicht selbst ein Henkersseil zu knüpfen.

Hallo Manfred,

Manfred hat geschrieben: ↑Fr, 22. Sep 2023 12:50 und alles PUBLIC setzen, war irgendwie noch nie eine gute Idee.
Aber vielleicht meinte Flanelli auch was ganz anderes?

Es war und ist ja auch NICHT die Rede davon ALLES auf public zu setzen und wir gehen selbstverständlich mit
publics im Source sehr sparsam um.
Daher auch JA, wir verstehen solche Funktionen als ganz spezielle Sidesteps die in gewissen Abläufen eine
extrem flexible und vor allem auch spontane Reaktion auf ebenso spontane Anforderungen ermöglichen ohne
dabei den Source angreifen zu müssen und ohne dabei die Abläufe bei allen anderen Kunden die nicht davon
betroffen sind, plötzlich zu ändern.

Und letzlich ist unser posting auch nur ein Gedanke gwesen um eventuell Sebastian eine Anregung zu geben.
Ob ihm damit gedient ist oder eine gänzlich andere Handhabung gemeint hat, kann nur er uns darlegen.

Hallo Freunde,
nachdem es hier irgendwie zum Thema passt, würde mich eure Meinung interessieren.
Ich versuche nun einen Ansatz, bei dem ich ein HASH anstelle von einzelnen Variablen verwende.
Bisher habe ich das HASH "hApp" genannt.

Ich denke jedoch, der Quellcode lässt sich leichter lesen, wenn man einfach h[] als Namen verwendet.
Dann kann man den HashKey besser sehen.

Zuerst definiere ich ein Hash.
Dann, wenn ich irgendwo eine Variable benötige, füge ich einen neuen Schlüssel ein, um darauf im gesamten Programm zugreifen zu können.

Ein xBrowse(h) zeigt alle Schlüssel - Variablen - die im Programm mit ihrem aktuellen Wert verwendet werden.

LG
Otto

Servus Flanelli,

Trotz aller Akribie und Checks ist irgendwo eine Variable nicht deklariert und nur die Aktion eines Users bringt eines Tages diesen Fehler zum Vorschein.

Darauf bezog sich mein "boa"

Das mit dem Reportgenerator als Beispiel kann ich selbstverständlich nachvollziehen.

Hallo Werner,
bei dem Ansatz mit dem Hash kann ich mit einem Default-Wert auf die Variablen zugreifen.
Dann kann das nicht passieren, dass ein Wert nicht deklariert ist.
LG
Otto
hb_HGetDef()
Returns a hash value, or a default value if the key is not present

Servus Werner,

Werner_Bayern hat geschrieben: ↑Sa, 23. Sep 2023 14:00
Trotz aller Akribie und Checks ist irgendwo eine Variable nicht deklariert und nur die Aktion eines Users bringt eines Tages diesen Fehler zum Vorschein.
Darauf bezog sich mein "boa"

Ohne jetzt das Thema noch ina endlose zu vertiefen nur kurz...
Diese Funktion Variablenpushup() haben wir in Zeiten von Clipper S87 kreiert und das aus gutem Grunde weil
es gab unter Clipper zwar diverse Prüfschalter aber keiner, absolut keiner hat alle Probleme
mit undeklarierten Variablen angezeigt und somit kam es selten, aber doch zu dem einen oder
anderen "Flüchtigkeitsfehler" und da hat uns diese Funktion sozusagen schon mal das Leben gerettet.

In weiterer Folge haben wir dann, wie schon gesagt, diverse Varianten erstellt und letztendlich
das ganze Brimborium, ausgehend von der Urfunktion Variablenpushup() und allen Derivaten,
bei der Portierung zu Xbase++ auch mitgenommen und auch weiter ausgebaut.

Nach Abschluß der Umstellung der einzelnen Programme wurde die UR-Datei "Variablen.def" eliminiert
aber sollte es dennoch wider Erwarten mal notwendig sein, dann ist sie ganz einfach wiederzubeleben

Und ehrlich gesagt, ich glaube wir sind nicht die Einzigen die unter Xbase++ alles, aber auch wirklich
alles für möglich und ebenso für unmöglich halten. Alles andere wäre nun doch etwas sehr blauäugig

Beste Grüße

, Flanelli

PS.: Ich mag dein "boa" eh

Inoffizielles deutsches Xbase-Forum

Interpreter wie Python?

Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?

Re: Interpreter wie Python?