Inoffizielles deutsches Xbase-Forum

jetzt habe ich mir mal die Zeit genommen, und einen kurzen Blick auf die Dataobjects geworfen.
Das erste was ich versucht habe war, meine Datanbankklasse davon erben zu lassen.
Das scheint zu klappen, aber sobald ich dann im Debugger der WB das neue Objekt anklicke um mir anzeigen zu lassen was denn da jetzt evtl. so alles (neues) drinsteht, gibt es gleich eine Fehlermeldung:

: dataobject1.PNG (11.6 KiB) 14239 mal betrachtet

:classDecsribe() scheint da wohl Probleme zu machen. Ob das wohl versucht nur die members und methods des Dataobjects anzuzeigen? Die sind natürlich zu dem Zeitpunkt noch nicht vorhanden, aber es gibt ja etliches in dem Objekt, was von DO geerbt hat.

Hallo Manfred,

ansich sollte das gehen. Allerdings sind diese netten internen Fehler ja ohnehin mies. Weil die nie sagen, was denn nun wirklich los ist. Bei mir sind das entweder total bescheuerte Programmierfehler (das aber hier seltener), oder irgendwelche unbekannten temporären Fehler (das schon öfters mal).

Ich habe mir selber schon öfters das DO im Objectinspector angesehen. Ohne jedes Problem.

Jan

Mmh. Deine Datenbankklasse beerbt die DataObjects-Klasse. Das hier wäre das ClassDescribe()-Ergebnis für ein leeres DataObject:

Code: Alles auswählen

 o:Classdescribe(): {"DataObject", {}, {}, {{"setNoIVar", 3, NIL, "", {1}}, {"className", 3, NIL, "", {1}}, {"classObject", 3, NIL, "", {1}}, {"init", 3, NIL, "", {1}}, {"merge", 3, NIL, "", {1}}, {"noMethod", 3, NIL, "", {1}}, {"copy", 3, NIL, "", {1}}, {"classDescribe", 3, NIL, "", {1}}, {"defineMethod", 3, NIL, "", {1}}, {"isDerivedFrom", 3, NIL, "", {1}}, {"getNoIVar", 1027, NIL, "", {1}}, {"new", 3, NIL, "", {1}}}}

Wie sieht der Code in Zeile 142 genau aus? Und vielleicht der in 141 und 140 noch?

das ist nur die Zeile auf der der Debugger steht, wenn ich oben im Variablenfenster das Objekt anklicke um anzusehen, was da drin steht. Also direkt nach der Erzeugung des Objektes. Wenn ich die Zeile ausremme wird die nächste genommen.

OK, nachdem ich gerade versucht habe für Alaska ein Beispiel zu bauen, mußte ich feststellen das es dabei geklappt hat. Also mache ich bei dem vorgenannten Code wohl etwas falsch.
Aber mit der Antwort von Alaska kann ich jetzt nicht viel anfangen. Hat jemand einen kleinen Hinweis, was gemeint ist?

Man kann von DataObject ableiten. Aber folgendes ist uns ganz ganz wichtig:
Das DataObject ist ein zustandsloser Container der durch alle Schichten einer Anwendung durchgereicht werden kann. Das sind auch solche Schichten, die zu einem anderen Prozess gehören.
Mit dem Einführen von Methoden und Membervariablen ist das Objekt nicht mehr zustandslos. Wandert es in einen anderen Prozess kann es unter Umständen nicht mehr wieder hergestellt werden.
Wenn du Methoden und spezielle Member Variablen brauchst, dann implementiere eine eigene Klasse.

Manfred hat geschrieben: ↑Fr, 26. Jan 2018 18:20 Aber mit der Antwort von Alaska kann ich jetzt nicht viel anfangen. Hat jemand einen kleinen Hinweis, was gemeint ist?

"Meine" Übersetzung : lass es und baue dir selbst was mit Array ... das ist dann auch "abwärts kompatible"

---

das was Alaska mit "Dataobject" uns anbietet ist eine Frechheit da es den Eindruck erweckt es wäre "das" DataObject was z.b. bei "echtem" DragDrop verwendet wird.

Hallo Jimmy !

das was Alaska mit "Dataobject" uns anbietet ist eine Frechheit da es den Eindruck erweckt es wäre "das" DataObject was z.b. bei "echtem" DragDrop verwendet wird.

Das habe ich anders in Erinnerung. Das hat mit Drag&Drop überhaupt nichts zu tun sondern ist dafür da ein ausgewähltes DataSet einer Datentabelle zu halten.
In C/C++/C# wird dies auch DataSet genannt.

Die Umsetzung der SQL-Abfragesprache bei Xbase++ verwendet für die Ergebnis-Menge eben ein DataObject.

... und in VFP nennt sich das CURSOR

HaPe hat geschrieben: ↑Fr, 26. Jan 2018 20:16Das habe ich anders in Erinnerung.

sorry, genau gesagt meine ich das IDataObject Interface
https://msdn.microsoft.com/de-de/librar ... s.85).aspx

HaPe hat geschrieben:Die Umsetzung der SQL-Abfragesprache bei Xbase++ verwendet für die Ergebnis-Menge eben ein DataObject.
... und in VFP nennt sich das CURSOR

dafür ist es wohl auch gedacht .... und dann sollte man es auch so "nennen"

Code: Alles auswählen

   ... INTO ARRAY
   ... INTO XbpCursor

wie schon gesagt spielt bei mir die Kompatibilität eine grosse Rolle.
mein Code "sollte" auch mit einem "kompatiblen" xBase Compiler/Linker laufen.

Hallo Jimmy !

Die Umsetzung der SQL-Abfragesprache bei Xbase++ verwendet für die Ergebnis-Menge eben ein DataObject.
... und in VFP nennt sich das CURSOR
dafür ist es wohl auch gedacht .... und dann sollte man es auch so "nennen"

Welche Bezeichnung meinst du jetzt genau die man so "nennen" sollte?
DataObject von Xbase++
CURSOR (CURrent Set Of Records) von VFP
DataSet von $MS in C/C++/C#
...

HaPe hat geschrieben: ↑Fr, 26. Jan 2018 22:16 Welche Bezeichnung meinst du jetzt genau die man so "nennen" sollte?
DataObject von Xbase++

ich "meckere" nur über die Bezeichnung von Alaska die "irreführend" ist

für mich ist ein DataObject "FROM" IDataObject Interface was ein ganz anderes Kaliber ist als was uns Alaska anbietet

... man sollte wenigstens ein Xbp davor setzten um zu kennzeichnen das es eine "Eigenkreation" ist

---

sorry wir weichen wieder mal vom Thema ab.

Jimmy,

quatsch. Der Präfix Xbp kennzeichne bei Alaska ein grafisches Element. Und das ist ein DataObject ja nun absolut nicht.

Abgesehen davon ist es doch vollkommen egal, was ein DataObject für Dich ist. Wichtig ist, was es in Xbase++ bedeutet. Abgesehen davon habe ioch noch nie jemanden gehört der sich außer darüber aufregt.

Und erzähl nicht, wir würde von Thema abweichen. Wer hat denn als erster in diesem Thread damit angefangen?

Jan

Jetzt habe ich statt der absoluten Superklasse die Klasse, die von der Datenbankklasse erbt, zusätzlich noch von Dataobject erben lassen. Die Fehlermeldung ist jetzt weg. Naja, wenn es so klappt, ist es ja ok. Ich möchte ja die jeweilige Tabellenklasse nus als Dataobject nutzen. Mal sehen was noch so auf mich wartet.

Ich würde ja eher DataObjects als Instanzen eines anderen Klassenobjekts verwenden.

? Ist wohl noch zu früh heute morgen. Kannst Du mir kurz einen Tipp geben.

Er wird wohl das anstatt-als meinen und nicht das für-als bzw. wie-als.

Viele Grüße,
Martin

Eigentlich habe ich Instanzvariablen gemeint.

Oder so

ein dataobject als Instanzvariable?

@Jimmy: Manchmal ist schon echt lustig, was Du so schreibst, vor allem, wenn Du aus den falschen Gründen in Rage gerätst.

Und, nein, ein DataObject ist nicht dasselbe wie ein Cursor bei SQL. Ein SQL-Cursor ("Current Record Set") bezeichnet den Iterator auf der Rückgabemenge eines SQL-Statements. Man kann DataObjects dafür verwenden, und wahrscheinlich haben die Jungs bei Alaska dieses Klassenmodell auch deshalb entwickelt, aber eben nicht nur dafür. DataObjects sind extrem flexible und schnelle und vor allem dynamische Objekte, die zur Laufzeit um Instanzvariablen ergänzt werden können, einfach dadurch, dass man diese (bislang nicht existenten) Instanzvariablen anspricht. Diese Eigenschaft erlaubt es, sehr elegant und flexibel mit Daten umzugehen. Ein DataObject könnte zum Beispiel in einer Daten(bank)klasse dafür verwendet werden, jeden beliebigen Datensatz zu repräsentieren, weil beim Design der Klasse und dieses Instanzobjekts nicht bekannt sein muss, welche Felder es gibt. Ich halte es aber für keine gute Idee, bestehende Klassen mit den Eigenschaften von DataObjekts auszustatten. Alaska Software rät auch explizit davon ab:

Entwickler sollten DataObjects allerdings nicht dazu verwenden, um das bestehende Konzept von Klassenobjekten und Objektinstanzen zu ersetzen. Vergessen Sie nie, dass reguläre Klassen und Objekte, echte Typen sind! Typ und Schnittstelle eines Objekts sind statisch und können jederzeit transparent mit ::IsDerivedFrom() ermittelt und überprüft werden. DataObjects geben diese implizite Garantie aufgrund ihres dynamischen Charakters hingegen nicht. Als Faustregel kann man festlegen, dass Klassen für die Implementierung der Geschäftslogik (Beispiel: Klasse OrderMgmt) verwendet werden sollten. DataObjects hingegen eignen sich sehr gut das Speichern der Informationen, die darin verarbeitet werden. Beispiele hierfür sind Entitäten wie Adresse, Kunde, Produkt oder auch Einkaufswagen. (Quelle: Website von Alaska Software)

Hi Tom,
Aber im letzte Satz sehe ich genau die Begründung für einen Einsatz. Ich baue eine SuperDatenbankklasse auf, in der alle übergreifenden Methoden und Membervars angegeben werden. Lasse die späteren Datenobjekte, die rein für die jeweiligen Tabellen zuständig sind aber auch von Dataobjects erben und nutze dann die Möglichkeit die einzelnen Feldvariablen dynamisch zu erzeugen um damit arbeiten zu können. Dann wäre das doch genau das, was in dem Satz steht!?

Tom hat geschrieben: ↑Sa, 27. Jan 2018 8:34 Ich würde ja eher DataObjects als Instanzen eines anderen Klassenobjekts verwenden.

+1

Inoffizielles deutsches Xbase-Forum

Dataobjects jetzt gehts los

Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los

Re: Dataobjects jetzt gehts los