Fehler in XBASE ??? [erledigt]

[messing]

Original Beispiel von Xbase liefert NIL obwohl die Beschreibung was anderes verspricht.

Code: Alles auswählen

// PARAMETERS Beispiel
// Das Beispiel demonstriert, wie sich LOCAL Variablen auch in einer
// .XPF-Datei für Speichervariablen sichern und wieder einlesen
// lassen. Dazu sind zwei benutzerdefinierte Befehle mit der
// #command-Direktive formuliert, die vom Präprozessor zu einem Aufruf
// der Prozeduren SaveLocal() oder RestLocal() übersetzt werden.
// In beiden Prozeduren sind die formalen Parameter mit PARAMETERS
// deklariert. Sie gehören damit der Speicherklasse PRIVATE an, die

// mit dem Befehl SAVE oder RESTORE gesichert und wieder eingelesen
// werden können.
// Bei SaveLocal() werden den Parametern die Werte von LOCAL-
// Variablen zugewiesen und die Parameter werden gespeichert.
// Bei RestLocal() werden die LOCAL-Variablen per Referenz übergeben.
// Dadurch wird ihnen der Wert der eingelesenen PRIVATE-Variablen
// (gesicherte Parameter) zugewiesen.
// Wenn man die Parameterlisten von SaveLocal() und Restlocal()
// verlängert, können mehr als nur 10 LOCAL Variablen gespeichert

// werden.

#command SAVE TO <(file)> LOCAL <var,...> ;
 =>      SaveLocal( <(file)>, <var> )

#command RESTORE FROM <(file)> LOCAL <var1> [,<varN>] ;
 =>      RestLocal( <(file)>, @<var1> [, @<varN>] )


   PROCEDURE Main
      LOCAL cString:= "Xbase++", ;     // LOCAL Variablen deklarieren
            dDate  := Date()   , ;     // und initialisieren
            nNumber:= 100      , ;
            lLogic := .T.

      SAVE TO TestFile ;               // Wert der LOCALs sichern
        LOCAL cString, dDate, nNumber, lLogic

      cString := dDate := ;            // Alle Werte der LOCALs
      nNumber := lLogic:= NIL          // löschen (NIL zuweisen)

      RESTORE FROM TestFile ;          // Werte wieder einlesen
        LOCAL cString, dDate, nNumber, lLogic

      ************************************************************
      * Der PPO-Code für RESTORE FROM...LOCAL lautet:            *
      *                                                          *

      * RestLocal( "TestFile", @cString,@dDate,@nNumber,@lLogic) *
      *                                                          *
      * Die LOCAL Variablen werden per Referenz übergeben!       *
      ************************************************************

      ? cString                        // Ergebnis: "Xbase++"
      ? dDate                          // Ergebnis: Date()
      ? nNumber                        // Ergebnis: 100
      ? lLogic                         // Ergebnis: .T.


   RETURN

   ** PARAMETER werden als PRIVATE Variablen angelegt und
   ** können deshalb in einer .XPF-Datei gespeichert werden
   PROCEDURE SaveLocal
      PARAMETERS cFile, p1,p2,p3,p4,p5,p6,p7,p8,p9,p10

      SAVE TO (cFile) ALL LIKE p*
   RETURN

   ** PARAMETER werden als PRIVATE-Variablen angelegt und
   ** können deshalb aus einer .XPF-Datei eingelesen werden.
   ** Wenn LOCAL-Variablen per Referenz übergeben werden, bekommen
   ** sie die eingelesenen Werte der PRIVATE-Variablen zugewiesen.

   PROCEDURE RestLocal
      PARAMETERS cFile, p1,p2,p3,p4,p5,p6,p7,p8,p9,p10

      RESTORE FROM (cFile) ADDITIVE

   RETURN

Hat von Euch einer den gleichen Fehler?
Gibts dafür eine Lösung?
Ist das ein BUG?

[Tom]

Da das Beispiel überhaupt keine Funktion enthält, dürfte es kein NIL zurückliefern, sondern überhaupt nichts. Du musst das Programm mit dem Namen der zu speichernden XPF-Datei als Parameter aufrufen, also beispielsweise "TEST.EXE c:\Mist\Krempel.XPF". Diese Datei sollte entstehen. Und mit dieser Angabe dürfte das Programm auch ein paar Werte anzeigen.

[messing]

Doch, das Beispiel hat zwei Fuinktionen.
Save... und Restore...
mit der Anweisung, die Variablen anzuzeigen, welche wiederhergestellt wurden.

Code: Alles auswählen

      ? cString                        // Ergebnis: "Xbase++"
      ? dDate                          // Ergebnis: Date()
      ? nNumber                        // Ergebnis: 100
      ? lLogic                         // Ergebnis: .T.

[Tom]

Jo, aber das geht nur, wenn Du beim Start als Parameter den Namen einer XPF-Datei angibst. Das hast Du vergessen.

[messing]

Ob Funktion oder Prozedur, naja zwei Prozeduren sind dabei. Und die Ausgabe ? = PRINT / Bildschirmausgabe.

[Tom]

Hast Du's jetzt mal mit Parameter gestartet?

Und, nein, da ist kein Fehler in Xbase. Jedenfalls nicht an dieser Stelle.

[messing]

Wenn ich dieses hübsche Beispiel laufen lasse, erstellt mir dieses kleine Prog. eine Datei mit Namen Testfile.xpf.
Kann die Datei gern mitschicken.

[messing]

Das Beispiel ist voll funktionsfähig, Vars definieren, Vars speichern, Datei wird angelegt, Vars werden laut Beispiel leergefegt,nur beim RESTORE FROM werden diese nicht wiederhergestellt.

[messing]

Hast Du's jetzt mal mit Parameter gestartet?

Und, nein, da ist kein Fehler in Xbase. Jedenfalls nicht an dieser Stelle.

Das Beispiel ist vollständig, mit allem was es braucht, ODER???
Auch die Beschreibung ist dabei, und nach dieser müssten die vier Vars in dem Beispiel wieder den Wert zugewiesen bekommen und angezeigt werden.

[Tom]

Ups. Mein Fehler. Ich habe den Code nur überflogen und mich an die erste Zeile erinnert - aber die ist ja auskommentiert. Also, Kommando zurück. Das war mein "Manfred" für heute.

[Tom]

Das Beispiel restauriert die Daten tatsächlich nicht. Ich schaue noch.

[Markus Walter]

Das war mein "Manfred" für heute.

Ist das jetzt eine offiziell eingeführte Einheit? Vielleicht sollten wir das bei der ISO einreichen?
Sorry Manfred, ist liebevoll gemeint.

[brandelh]

Ich melde gleich mal Marken und Urheberrechtsschutz an, sorry Manfred, wirst dir einen neuen Namen suchen müssen

[Manfred]

Euer Spott trifft mich nicht...

[messing]

Servus, also egal wie ich auch bastel, ich bekomm immer nur leere Vars. Hab jetzt das ganze Wochenende versucht, etwas zu bewirken ,leider ohne Erfolg. Hat einer eine Lösung? Ist das doch ein BUG?

[georg]

Hallo, messing -


der Code erscheint sauber. Was ich an Deiner Stelle machen würde: den Code mit DEBUG=YES compilieren, das Programm im Debugger starten und schauen, was in der Restore-Routine passiert, besonders nachdem Du Monitor => Private eingeschaltet hast.

Wenn ich etwas mehr Zeit habe, bilde ich es hier mal nach.

Update:

in der Funktion RestLocal zeigen sich folgende Variablen:

Code: Alles auswählen

<Local>       @PARA0 C: "TestFile"
<Local>       @PARA1 C: "Xbase++"
<Local>      @PARA10 U: NIL
<Local>       @PARA2 D: 20120213
<Local>       @PARA3 N: 100
<Local>       @PARA4 L: .T.
<Local>       @PARA5 U: NIL
<Local>       @PARA6 U: NIL
<Local>       @PARA7 U: NIL
<Local>       @PARA8 U: NIL
<Local>       @PARA9 U: NIL
<Private>      cFile C: "TestFile"
<Private>         p1 C: "Xbase--"
<Private>        p10 U: NIL
<Private>         p2 D: 20120213
<Private>         p3 N: 100
<Private>         p4 L: .T.
<Private>         p5 U: NIL

Es sieht also so aus, als würden die Parameter als LOCAL übergeben, und zwar in den @PARA Feldern, und dann in die PRIVATE Variablen übertragen. Diese werden dann geändert durch den RESTORE, aber nicht in die @PARA Felder zurück übertragen, weshalb die Rückgabe an die aufrufende Funktion scheitert.

Hinweis: ich habe Dein Beispiel abgeändert und auch im Debugger Werte geändert.

Du könntest es etwa so versuchen:

Code: Alles auswählen

FUNCTION RestLocal (cFile, p1, p2, p3, p4, p5, p6, p7, p8, p9, p10)
Private xL1, xL2, etc.

xL1 := p1
xL2 := p2
etc.

RESTORE FROM (cFile) ADDITIVE

p1 := xL1
p2 := xL2
etc.

RETURN(.T.)

Das gleiche ist dann aber auch in der Save Routine erforderlich, da die SAVE die Namen der Private Variablen zum Speichern verwendet, und sonst Dein Restore in die Hose geht.

Auch müssen die Variablen IMMER in der gleichen Reihenfolge vorgegeben werden.

Ich habe das Thema XPF und MEM inzwischen abgeschrieben und verwende eine UserSettings DBF-Datei, in der ich solche Werte verwalte. MEM und XPF sind im Zeitalter der Netzwerke doch Anachronismen.


Gruss,

Georg

[Tom]

MEM und XPF sind im Zeitalter der Netzwerke doch Anachronismen.

So ist es. Es existieren keine Locking- oder Schutzmechanismen (weshalb man SAVE TO/RESTORE FROM in entsprechende eigene Prozesse einbetten muss), XPF-Dateien sind Favoriten für Korruptionen, und ganz haarig wird es, wenn sie zwischenzeitlich mal auf einem mobilen Laufwerk gespeichert waren, was nämlich zur Komprimierung führt, mit der Xbase++ (oder das Betriebssystem?) offenbar an dieser Stelle nicht umzugehen in der Lage ist. Deshalb sollte man sie etwa durch Tabellen, XML-Dateien, meinetwegen INIs ersetzen. Mit SymbolInfo() kann man abfangen, was Parameter wie "ALL LIKE ..." tun, und der Makroexpander sowie Funktionen wie Var2Char() helfen, die Speicherdaten so aufzubereiten, dass sie ausgelagert werden können. Für benutzer-/arbeitsplatzbezogene Optionen ist die Registry der Speicherort der Wahl.

Dennoch. Der Code sieht auch für mich sauber aus. Allerdings enthält die XPF-Datei neben p1 ... pX noch ein paar andere seltsame Variable, und restauriert wird offensichtlich nicht. Es scheint so, als wurde PARAMETERS keine PRIVATEs, sondern LOCALs initialisieren. Oder etwas in der Art.

[georg]

Hallo, Tom -


der Restore funktioniert sauber, nicht aber die Rückübertragung in die Private Variablen, die jedoch nicht IDENTISCH sind mit den PARAMETER Variablen. Meine Vermutung ist wie folgt:

Code: Alles auswählen

FUNCTION IRGENDWAS
   PARAMATER EINS

wird übersetzt in:

Code: Alles auswählen

FUNCTION IRGENDWAS (@PARA0)
   PRIVATE EINS := @PARA0

Und wer das mal versucht hat:

Code: Alles auswählen

FUNCTION IRGENDWAS
   PARAMETER EINS
   LOCAL ZWEI

bekommt vom Compiler den Kommentar, dass eine Local Deklaration nicht auf ein ausführbares Statement (?!) folgen kann.

Damit ist natürlich die "Verbindung" von

Code: Alles auswählen

IrgendWas(@cVariable)

"kaputt", da keine Rückübertragung

Code: Alles auswählen

@PARA0 := EINS

im Return-Fall durchgeführt wird.

Drücke ich mich verständlich aus?


Gruss,

Georg

[UliTs]

Der Fehler ist doch offensichtlich (kleiner Scherz ).
Wenn die Parameter mittels "PARAMETERS" angegeben werden, handelt es sich um CALL by VALUE und NICHT um CALL by REFERENCE!
Daran ändert sich auch NICHTS durch die Angabe des @-Zeichens beim Aufruf!

Richtig ist (ohne es getestet zu haben):

Code: Alles auswählen

PROCEDURE RestLocal( cFile, p1,p2,p3,p4,p5,p6,p7,p8,p9,p10 )
  RESTORE FROM (cFile) ADDITIVE
RETURN

Uli

[brandelh]

PARAMETERS übernimmt PRIVATE Variablen, somit sind diese nicht "per Value" sondern änderbar auch im aufrufenden Programm.
PRIVATES sind dafür gedacht mit dem Befehl gespeichert und später wieder gelesen zu werden. Denn diese sind mit NAMEN zur Laufzeit bekannt.

Bei der Übergabe mit Klammer hinter dem Funktionsnamen wird LOCAL übergeben und hier spielt es eine große Rolle, ob "per Value" (Standard) oder
"per Referenz" ( @ im Aufruf ) oder ÜBERGEBEN wird. Das @ in der Funktionsparameterleiste kann aber nur ein Tippfehler sein.

Laut Handbuch und meiner Erinnerung dürfte der Befehl nur funktionieren, wenn PRIVATE gespeichert werden,
eventuell irre ich mich aber auch und die Beschränkung gilt nur für Clipper.

Auf jeden Fall ist es bedeutend besser den Empfehlungen anderer erfahrener Programmierer zu folgen und
das TEIL in die TONNE zu entsorgen. Es gibt in der Wissensbasis die INI Dateifunktionen (mit und ohne API),
Man kann sich eine einfache CSV Datei erstellen oder ganz modern (wenn auch nicht mein Fall) die Registry nutzen.

Alles ist besser als dieses Relikt aus DBASE aus DOS / SINGLE Rechner, SINGLE Task Zeiten.

[georg]

Hallo,


was messing so irritiert hat, ist dass dieses Beispiel so in der Xbase++ Dokumentation drin steht ... Einfach mal über Index, Reiter Index nach parameters suchen ...

Also sollte eine entsprechende Funktionalität unterstellt werden (unabhängig davon, ob es sich um guten oder schlechten Stil oder was auch immer handelt).


Gruss,

Georg

[brandelh]

Hi,

es soll schon mal vorkommen, dass man sich einen Tippfehler erlaubt ... hier ist es der Präprozessor !
Wenn man sich tatsächlich den PPO Code ansieht, dann stellt man dies fest:

Code: Alles auswählen

RestLocal( "TestFile", @cString , @ dDate, @ nNumber, @ lLogic )
richtig wäre aber so ...
RestLocal( "TestFile", @cString , @dDate, @nNumber, @lLogic )
das dürfte ein Fehler sein, der irgendwann entstanden ist ...

[brandelh]

Zu früh gefreut, das @ Var sah zwar für mich ungewöhnlich aus, aber bei der Funktion ändert sich nichts.
Wie schon bemerkt lädt die Routine zwar die PRIVATE Variablen, aber im Gegensatz zu der Behauptung von
der Erläuterung zur Routine werden diese NICHT intern umgebogen auf die LOCALs ...
ob das jemals funktioniert hat weiß ich nicht, mit der 1.90.331 und 1.90.355 geht es nicht.

Das ist aber bestenfalls ein Fehler des Beispiels, denn sowohl bei SAVE als auch bei RESTORE steht, dass
es nur für privates ist. Wenn man locals speichern will, muss mein eine eigene SAVE machen, die
die LOCALs in PRIVATES umlädt und das Gegestück, das diese Umlagerung wieder aufhebt ...

[UliTs]

PARAMETERS übernimmt PRIVATE Variablen, somit sind diese nicht "per Value" sondern änderbar auch im aufrufenden Programm.

Falsch!
Hubert, was ist los?
Natürlich kann man bei PARAMETERS auch LOCAL-Variablen übergeben! Das geht aber nur deshalb, weil bei es sich bei PARAMETERS grundsätzlich um CALL BY VALUE-Parameter handelt! Das heißt, als Parameter übergebene Variablen ändern ihren Wert NIEMALS in der aufrufenden Routine (Ich nenne die Routine mal Routine A)! Wie richtig erwähnt, sind die Parameter-Variablen in der aufgerufenen Prozedur oder Funktion (ich nenne sie im Folgenden Routine B) PRIVATE-Variablen. Das hat zur Folge, dass die Parameter-Variablen auch in allen von der Routine B aufgerufenen Funktionen oder Prozeduren sichtbar sind. Das würde aber der Kaspelung von Local-Variablen widersprechen!
Nichtsdestotrotz (richtig geschrieben?!???) glaube ich, dass meine angegebene Korrektur auch falsch war, da es sich ja bei den Parametern um LOCAL-Variablen handelt, die so durch RESTORE nicht mit Werten gefüllt werden. Vermutlich klappt folgendes:

Code: Alles auswählen

PROCEDURE RestLocal( cFile, p1,p2,p3,p4,p5,p6,p7,p8,p9,p10 )
PRIVATE p1,p2,p3,p4,p5,p6,p7,p8,p9,p10  // Wenn das gleiche Benennen von LOCAL- und PRIVATE-Variablen nicht funktionieren sollte, in obiger Zeile und unten einfach pp1,pp2,etc.benutzen
  RESTORE FROM (cFile) ADDITIVE
  p1 := memvar->p1
  p2 := memvar->p2
  p3 := memvar->p3
  p4 := memvar->p4
  p5 := memvar->p5
  p6 := memvar->p6
  p7 := memvar->p7
  p8 := memvar->p8
  p9 := memvar->p9
  p10 := memvar->p10
RETURN

Vielleicht hat jemand Lust, dass mal zu testen .
Ansonsten haben Tom und Hubert natürlich Recht. Heutzutage sollte man möglichst auf *.MEM + *.XPF-Dateien verzichten

Uli

[brandelh]

Natürlich kann man bei PARAMETERS auch LOCAL-Variablen übergeben!

ich halte mich ans Handbuch und da steht ...

Da die Anweisung PARAMETERS Variablen erzeugt, die der Speicherklasse PRIVATE angehören, bleiben sie so lange im Programm sichtbar, bis die entsprechende Funktion oder Prozedur beendet wird oder bis sie in einer untergeordneten Funktion bzw. Prozedur durch Variablen gleichen Namens "überdeckt" werden.

wenn man LOCAL will, dann darf man nicht PARAMETERS (als Befehl) nutzen, sondern einfach direkt die Paramter in Klammern übergeben

Hinweis: Wenn die formalen Parameter bei der Deklaration mit der Anweisung FUNCTION oder PROCEDURE als Liste mit Variablennamen in ()-Klammern angegeben werden, können die Parameter als Variablen der Speicherklasse LOCAL behandelt werden, deren Referenzen bereits zur Compile-Zeit aufgelöst werden. Das erhöht die Ausführungsgeschwindigkeit.

Ich gebe aber gerne zu, dass ich PARAMETERS schon ewig nicht mehr einsetze, daher könnte mir die eine oder andere Nebenwirkung entfallen sein