Vererbung

[Manfred]

Hi Robert,

ich kann nachvollziehen was Du damit meinst, aber das verstehe ich eben unter Vererbung.... Ansonsten würde ich die Methode neu definieren in der Unterklasse, aber nur zu dem Zweck sie dann zu überschreiben und das findet hier m.E. nicht statt.

[Markus Walter]

Hallo Manfred,

also nach meinem Verständnis von OOP sehe ich das so wie Robert.

Aus meiner Sicht wäre die richtige Implementierung so (Pseudo-Code):

Code: Alles auswählen

CLASS Vater
  Var Var1
  method Leeren
ENDCLASS

Method Vater:Leeren()
  Var1 := ""
End


CLASS Sohn FROM Vater
  Var Var2, Var3
  method Leeren
end

Method Sohn:Leeren()
  ::Vater:Leeren()
  ::Var2 := ""
  ::Var3 := ""
End

So habe ich OOP immer verstanden. Die Klasse Vater weiß nix von den Variablen und Methoden der Sohn-Klasse. Aber man kann (und muss) Methoden überschreiben und darin dann die Methode des Vaters aufrufen.

[Manfred]

Hi Markus,

und ich war bisher immer der Meinung, dass durch die Vererbung der Methoden auch die Membervar der Methode bekannt ist....

Tja, das war dann ein dicker Holzweg, auf dem ich wandelte.

Wobei ich trotzdem nicht verstehe warum das vom Konzept her so gemacht wurde? Ich will doch nichts überschreiben, sondern nur benutzen....

Naja, ich mache es dann so wie ich es in der Vergangenheit gemacht habe, ich übergebe das Objekt als Parameter.

Tsetsetse, so richtig Spaß macht diese Erkenntnis der OOP aber jetzt nicht.

[Markus Walter]

Hallo Manfred,

ich nochmal...

Ich habe mir Dein Beispiel nochmal angeschaut (das mit felderleeren).

Also nach meiner Überzeugung ist das so:
Jede Klasse kennt nur die Methoden und Variablen ihrer Ebene und die darüber, aber nicht die "unter" ihr (also der vererbten Klassen). Somit dürfte es nur so gehen, wie ich geschrieben habe.
Interessanter ist aber Dein Beispiel mit dem Array, der in der Superklasse definiert wird und dann von der erbenden Klasse besetzt wird, aber das müsste ich mir mal in Ruhe durch den Kopf (und den Test) gehen lassen...

[Manfred]

Hi,

wo wir gerade beim Thema sind. Noch ein paar Gedankengänge zur Vererbung:

Ich habe gerade festgestellt, dass ich in mindestens 2 Klassen die gleichen Variablen habe und für den gleichen Zweck benutze. Aus der einen Klasse werden verschiedene Objekte gebaut, die dann die Variablen füllen und dann einem letzten Objekt die Werte zur Zusammenrechnung übergeben. Dann wäre es doch empfehlenswert, eine Klasse zu bauen, die nur diese Variablen enthält und dann die anderen Klassen davon erben zu lassen, oder? Dann brauche ich keine Tippfehler, oder sonstwas zu fürchten, weil die ja von einem Ursprung sind. Bzw. ich brauche nur 1 Stelle zu pflegen. Ähnlich wie bei Funktionen, oder so, wenn man zusammenfassen kann? Oder macht man sowas nicht, oder anders?

[Manfred]

Weiter geht´s !

Gestern habe ich mal wieder ein wenig Zeit gefunden mich mit xbase++ zu beschäftigen. XbpBrowse erbt ja von XbpStatic, also auch ptions. Nun ein bisserl habe ich gebastelt, aber was mache ich damit? Ich habe nicht das erreicht, was ich haben wollte. Z.B. die Überschriften der Spalten zentrieren, oder so.

[brandelh]

Hi,

das zentrieren von Text in Statics geht nur bei Textstatics.
Ich denke nicht, das für jede Spaltenüberschrift ein Static genommen wurde. Vielmehr ist der ganze Bereich ein 'sonder' static, welches dann die columns zugeordnet bekommt. Aber die Überschriften können - soweit ich mich erinnere mit dem Array für die pesentation manipuliert werden.

[Sören]

Hallo Manfred,

um den Überschrifts-Text einer Spalte zu zentrieren, kannst Du die Presentation-Paramter des XbpBrowse verwenden:

Code: Alles auswählen

  aPresParam := { { XBP_PP_COL_HA_ALIGNMENT, XBPALIGN_HCENTER } }

Entgegen Huberts Annahme ist jede Spaltenüberschrift ein eigenes XbpStatic.
Man kann folgendermaßen darauf zugreifen:

Code: Alles auswählen

  oCol := oBrowse:getColumn( 1 )

  // Text-Farbe der Ueberschrift aendern
  oCol:Heading:setColorFG( GRA_CLR_RED )

Tschüs,
Sören

[Manfred]

Hi,

ich denke einmal, dass das auch hierher gehört:

ich hoffe ich gebe es jetzt im Groben so wieder, weil es umfangreicher ist im Original, aber ich denke mal der Sinn sollte so sein:

Code: Alles auswählen

oTest := test():new():initvaria()
***********************
CLASS datenbank
      EXPORTED:
      VAR aIndex,;
          id
      METHOD init
ENDCLASS
********************
METHOD datenbank:init()
       ::id := 0
RETURN self
***********************
CLASS test FROM datenbank, _test
      METHOD initvaria
ENDCLASS
**********************
METHOD test:initvaria()
       ::initstruktur(self)     <-------- warum muß hier ein self rein?
RETURN self
***********************
CLASS _test
      METHOD initstruktur
ENDCLASS
***********************
METHOD _test:initstruktur(objekt)
       objekt:aIndex := {;
                         {"ID","STR(id,8,0)"};
                        }
RETURN self

Warum muß ich bei Aufruf von inistruktur() ein self mit übergeben? Wenn ich mir das in der Methode über den Debugger anschaue, dann ist die Var bekannt, aber NIL (ich habe sie auch schon gesetzt, hilft nichts)

Wenn ich es so mache:

Code: Alles auswählen

oTest := test():new():initvaira()
***********************
CLASS datenbank
      EXPORTED:
      VAR aIndex,;
          id
      METHOD init
ENDCLASS
********************
METHOD datenbank:init()
       ::id := 0
RETURN self
***********************
CLASS test FROM datenbank, _test
      METHOD initvaria
ENDCLASS
**********************
METHOD test:initvaria()
       ::initstruktur()  <--- jetzt ohne self
RETURN self
***********************
CLASS _test
      METHOD initstruktur
ENDCLASS
***********************
METHOD _test:initstruktur()
       ::aIndex := {;
                         {"ID","STR(id,8,0)"};
                        }
RETURN self

dann kommt diese Fehlermeldung:

Member-Variable ist für dieses Objekt unbekannt
aIndex
ThreadID :1

[Martin Altmann]

Hallo Manfred,
ganz einfach - in Deiner Klassse _test gibt es keine Membervariable aIndex!

Viele Grüße,
Martin

[Manfred]

Hi Martin,

dass stimmt, aber es swird doch von Datenbank geeerbt und die hat die Var aIndex.

Ah Stop, aber die erbt ja gar nicht von Datenbank und da die Methode von _test ist, kennt sie die aIndex Var ja gar nicht. Verflixt, Reihenfolge durcheinandergebracht. So einfach geht das..
Dann wäre es besser, _test von Datenbank erben zu lassen und dann erst test von _test, aber ohne DAtenbank.
AHhh, wieder was dazugelernt.

[Martin Altmann]

Hallo Manfred,
yup!

Viele Grüße,
Martin

[Manfred]

au verflixt, Du bist ja online. Habe noch was dazugeschrieben.

[Martin Altmann]

Hatte ich schon gesehen - keine Sorge!

Viele Grüße,
Martin

[Manfred]

Schade, geht doch nicht.

Die _test ist eine ausgegliederte DLL und kennt somit die datenbank Klasse nicht. Wenn ich die datenbank Klasse zur _test linke, dann gibt es wieder Funktionen, die der datenbank Klasse fehlen.

Naja, egal, wichtig war jetzt nur, dass ich den recht simplen Grund verstanden habe.

[Manfred]

HC,

und wieder etwas, was ich nicht verstehe:

Das hier klappt,

Code: Alles auswählen

oSatzNr := SlePic():new(oRahmen,,{120,oRahmen:currentSIze()[2]-50},{50,20})
oSatzNr:bufferLength := 10
oSatzNr:create():disable()
oSatzNr:picture      := "99999999"

aber das hier nicht:

Code: Alles auswählen

oSatzNr := satznr():new(oRahmen,,{120,oRahmen:currentSIze()[2]-50},{50,20})
oSatzNr:bufferLength := 10
oSatzNr:create():disable()
oSatzNr:picture      := "99999999"

********************************************************************************
CLASS satzNr
      EXPORTED:

      METHOD init
ENDCLASS
********************************************************************************
METHOD satzNr:init(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
       SLEPic():new(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
RETURN self

bufferLength ist nicht bekannt und im Debugger ist alles leer. Wo denke ich mal wieder falsch?

[AUGE_OHR]

hi,

aber das hier nicht:

Code: Alles auswählen

oSatzNr := satznr():new(oRahmen,,{120,oRahmen:currentSIze()[2]-50},{50,20})
oSatzNr:bufferLength := 10
oSatzNr:create():disable()
oSatzNr:picture      := "99999999"

*************************************************************

CLASS satzNr
      EXPORTED:

      METHOD init
ENDCLASS
*************************************************************

METHOD satzNr:init(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
       SLEPic():new(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
RETURN self

bufferLength ist nicht bekannt und im Debugger ist alles leer. Wo denke ich mal wieder falsch?

bei CLASS satzNr fehlt erstmal das FROM SLEpic den ohne
"Vater" weiss man ja nicht um dessen Eigenschaften.

in der Methode :init wird zwar ein SLEPic Object angelegt aber es hat ja
keine "Beziehung" zu "irgend jemand" ...

versuche es mal so :

Code: Alles auswählen

#include "Xbp.ch"
#include "Appevent.ch"

PROCEDURE MAIN
LOCAL nEvent, mp1, mp2, oXbp
LOCAL oSatzNr, nNr := 0

   oSatzNr := Satznr():new(,,{120,50},{50,20})
   oSatzNr:bufferLength := 10
   oSatzNr:picture      := "99999999"
   oSatzNr:create()
   oSatzNr:setdata(nNr)
   oSatzNr:disable()

   nEvent := 0
   DO WHILE nEvent <> xbeP_Close
      nEvent := AppEvent( @mp1, @mp2, @oXbp )
      oXbp:handleEvent( nEvent, mp1, mp2 )
   ENDDO

return

***********************************************************
CLASS SatzNr FROM SLEPIC
      EXPORTED:

      METHOD init
      METHOD create
ENDCLASS

METHOD satzNr:init(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
   ::SLEPic:init(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
RETURN self

METHOD satzNr:create(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
   ::SLEPic:create(oParent, oOwner, aPos, aSize, aPresParam, lVisible)
RETURN self

frohe Weihnachten
gruss by OHR
Jimmy

[Manfred]

Hi Jimmy,

an sowas hatte ich auch gedacht, war aber irgendwie für mich nicht nachvollziehbar. Ich werde es mal testen.

[Manfred]

Moin,

nö, das war es nicht. Außerdem weiß ich jetzt auch, warum ich es nicht probiert hatte. Slepic holt ja nachher seine Daten von XbpSle und darin sollte ja dann bufferlength auch sein, weil es ja weitervererbt wird. (So mein Verständnis).
Also der Vorschlag hat nicht geklappt, er hat dazu geführt, dass sich das Programm bei ::Slepic:new() total verabschiedet hat, ohne wenn und aber und irgendwelche Meldungen.

[Martin Altmann]

Hallo Manfred,
ich verstehe Deine Intention nicht!
Wozu willt Du das überhaupt so machen?
Du schreibst oben, dass es funktioniert, wenn Du direkt von SlePic ableitest, aber nicht, wenn Du über einen Zwischenschritt gehst...
Aber wozu?
Abgesehen davon, dass es gehen muß, wenn Du Deine Klasse wie folgt definierst:

Code: Alles auswählen

CLASS SatzNr FROM SLEPIC 

ENDCLASS

bringt es keinen Sinn, da Du in der SatzNr ja keinerlei Änderungen einprogrammiert hast!
Deine beiden Implementationen von INIT und CREATE kannst Du Dir auch sparen, da Du dort ja nur unverändert die beiden Methoden aus der Superklasse SLEPIC aufrufst - das passiert sowieso, wenn Du sie in Deiner eigenen Klasse nicht implementierst!

Viele Grüße,
Martin

[Manfred]

Hi Martin,

der 1.Schein trügt: Es war nur ein Test. Ich möchte nachher schon wesentlich mehr damit machen.
Aber wie gesagt, es ist nur ein Ausschnitt dessen, was ich später alles in die Methoden packen möchte. Sage ich jetzt mal so salopp, aber vielleicht klappt es ja auch gar nicht so, wie ich es vorhabe.
Dies ist meine 1. echte Gui Anwendung und die 1.Funktion für weitere Eingabefunktionen. In dieser schreibe ich jetzt genau alles so auf, wie es später immer wieder in den anderen Eingabemasken vorkommen soll. Wenn diese Funktion so klappt, wie ich es mir denke, dann wird alles zusammengestrichen , was überflüssig ist, bzw. alles ausgelagert, was später auch für andere Funktionen zu gebrauchen ist um einen schlanken Code zu erzeugen. Also probiere ich halt verschiedene Techniken aus um zu sehen, was denn nun am Ende übrigbleibt. Naja und dabei hat es eben geknallt.

[Martin Altmann]

Hallo Manfred,
was vielleicht daran liegt, dass es im Prinzip nicht anders war, sondern nur eine weitere, leere "Hülle".
Hätte aber trotzdem gehen müssen - eigentlich!

Viele Grüße,
Martin

[Manfred]

Hi Martin,

dachte ich mir auch so, deshalb war ich so verwirrt. Also werde ich es jetzt nochmals zurückstellen und später nochmal testen, wie ich meinem Wunsch näher komme.

[AUGE_OHR]

hi,

nö, das war es nicht.

hm ... aber das Beispiel von mir funktioniert doch, oder ?

Außerdem weiß ich jetzt auch, warum ich es nicht probiert hatte. Slepic holt ja nachher seine Daten von XbpSle und darin sollte ja dann bufferlength auch sein, weil es ja weitervererbt wird. (So mein Verständnis).

Ja ... aber ...

Also der Vorschlag hat nicht geklappt, er hat dazu geführt, dass sich das Programm bei ::Slepic:new() total verabschiedet hat, ohne wenn und aber und irgendwelche Meldungen.

Du meinst also dein "satzNr:init()" das du es dort mit ::SLEPic:New()
versuchst hast ?
wenn ja dann suche doch mal nach der XppFatal.log ... in der steht
"@SATZNR@INIT(xx)" ...

Deshalb die "Aufteilung" in ":init" und ":create".

Wie du vorher richtig sagtest "holt" sich SLEPic von XbpSLE die Propertys.
Wenn du dir nun den SLEPic Source ansiehst findest du sowas wie

Code: Alles auswählen

CLASS SLEPic from XbpSLE

Methode SLEPic:init()
 ::XbpSLE:init(...)
 ::setze_meine_geerbten_Eigenschaften
 ::setze_neue_Eigenschaften
 
Methode SLEPic:create()
 ::XbpSLE:create(...)

Dein "satzNr:init()" ruft mit ::SLEPic:New() also nur die SLEPic:Init() auf
und das "recursiv" was dann zum XppFatal.log führt.

gruss by OHR
Jimmy

[Manfred]

Hi Jimmy,

richtig, Stack overflow....

da merke ich schon wieder..... das fehlende Wissen. Da hätte ich auch von selbst drauf kommen müssen, das es eine Endlosschelife wird....