Destroy von eigenen Objekten [ERLEDIGT]

[Manfred]

Hi,

XbaseParts sollte man mit :destroy() aus dem Speicher werfen, wenn man sie nicht mehr benötigt.

ich möchte hier nochmals eine für mich wichtige Frage stellen:

wie ist es jetzt genau mit eigenen Objekten, die man gebildet hat?

Wenn diese Local sind, wenn diese nicht Local sind?

[brandelh]

Hallo Manfred,

was genau ist ein 'eigenes Object' ?

Normalerweise kommt Xbase++ sehr gut damit zurecht, dass nicht mehr benötigter Speicher freigegeben wird.

LOCAL und PRIVATE Variablen (String, Num, Date etc. auch Objecte von Klassen) sofort nach dem Ende der Funktion / Methode.

STATIC und PUBLIC erst nach Programmschluss.

Allerdings belegen einige Objecte nicht nur Speicher den die Anwendung wieder freigeben kann, sondern auch sogenannte Systemresourcen:

XbpPrinter:Device oder Fonts oder ... diese Systemresourcen kann die Anwendung nicht mehr selbst freigeben. Dies geschieht in der Methode :destroy()

Da es nicht ganz einfach ist zu wissen was nun selbst geht und was nicht, sollte man alles destroyen was man angelegt hat.

[Rolf Ramacher]

Hi Manfred,

da ich innerhalb eines Programmteils mehrere Dialoge habe, so setze ich die xbpparts IMMER Local. Wird die Function dann beendet, so werden die Xbparts :destroy()

[Manfred]

Hi

@Hubert,

ich meinte natürlich eigene Klassen, von den dann Objekte abgeleitet werden. Im 1.Fall Klassen, die NICHT erben und im 2.Fall Klassen, die von irgendwelchen Xbaseparts erben.

Mich hat nämlich das Beispiel MDIDEMO etwas irritiert. Dort wird er Dialog vom XbpDialog abgeleitedt und dann mit einer eigenen destroy() Methode wieder entfernt.

@Rolf,

meinst Du das jetzt automatisch, oder von Hand nachprogrammiert? Ich mache sie auch local, damit man halt mehrmals aufrufen kann.

[brandelh]

Hi Manfred,
da ich innerhalb eines Programmteils mehrere Dialoge habe, so setze ich die xbpparts IMMER Local. Wird die Function dann beendet, so werden die Xbparts :destroy()

also wenn du nicht oXbp:destroy() aufrufst, wird das auch nicht automatisch destroyed. Nur der Speicher der auf die Externe Resource zeigt wird gelöscht.

[Manfred]

Hi Hubert,

sei mir nicht böse, aber ich habe die evtl. Konsequenzen daraus nicht verstanden.

[brandelh]

Hallo Manfred,

wenn man mit dem XbpFF z.B. Funktionscode erstellt, nutzt der eine Variable oXbp für die Erzeugung aller XbParts:

Code: Alles auswählen

///////////////////////////////////////////////////////////////////////////////
//
//  Vom Xbase++ FormDesigner erstellter Funktions Code
//    Erstellt am: 10.11.2007 Zeit: 13:17:05
//
///////////////////////////////////////////////////////////////////////////////

#include "Gra.ch"
#include "Xbp.ch"
#include "Appevent.ch"
#include "Font.ch"

#PRAGMA LIBRARY( "ASCOM10.LIB" )

PROCEDURE Main
   LOCAL nEvent, mp1, mp2
   LOCAL oDlg, oXbp, drawingArea, aEditControls := {}

   oDlg := XbpDialog():new( AppDesktop(), , {676,456}, {248,400}, , .F.)
   oDlg:taskList := .T.
   oDlg:title := "Neues Formular"
   oDlg:create()

   drawingArea := oDlg:drawingArea
   drawingArea:setFontCompoundName( "8.Arial" )

   oXbp := XbpStatic():new( drawingArea, , {12,324}, {84,24} )
   oXbp:caption := "Text"
   oXbp:clipSiblings := .T.
   oXbp:options := XBPSTATIC_TEXT_VCENTER+XBPSTATIC_TEXT_RIGHT
   oXbp:create()

   oXbp := XbpStatic():new( drawingArea, , {12,288}, {84,24} )
   oXbp:caption := "Text"
   oXbp:clipSiblings := .T.
   oXbp:options := XBPSTATIC_TEXT_VCENTER+XBPSTATIC_TEXT_RIGHT
   oXbp:create()

   oXbp := XbpStatic():new( drawingArea, , {12,252}, {84,24} )
   oXbp:caption := "Text"
   oXbp:clipSiblings := .T.
   oXbp:options := XBPSTATIC_TEXT_VCENTER+XBPSTATIC_TEXT_RIGHT
   oXbp:create()

   oXbp := XbpSLE():new( drawingArea, , {108,324}, {84,24}, { { XBP_PP_BGCLR, XBPSYSCLR_ENTRYFIELD } } )
   oXbp:tabStop := .T.
   oXbp:create()

   oXbp := XbpSLE():new( drawingArea, , {108,288}, {84,24}, { { XBP_PP_BGCLR, XBPSYSCLR_ENTRYFIELD } } )
   oXbp:tabStop := .T.
   oXbp:create()

   oXbp := XbpSLE():new( drawingArea, , {108,252}, {84,24}, { { XBP_PP_BGCLR, XBPSYSCLR_ENTRYFIELD } } )
   oXbp:tabStop := .T.
   oXbp:create()

   oXbp := XbpPushButton():new( drawingArea, , {84,204}, {96,24}, { { XBP_PP_BGCLR, XBPSYSCLR_BUTTONMIDDLE }, { XBP_PP_FGCLR, -58 } } )
   oXbp:caption := "Pushbutton"
   oXbp:tabStop := .T.
   oXbp:create()
   oXbp:activate := {|| NIL }

   oDlg:show()

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

Erst mit dem Ende des Programmes werden die hier erzeugten Controls wieder freigegeben. Die zur Erzeugung verwendete Variable oXbp wird immer neu überschrieben und der Verweis (eigentlich ein Zeiger oder Handle) auf das gerade erzeugt Control geht verloren. Das Control selbst ist aber natürlich weiter vorhanden, sonst würde man ja nichts eingeben können.

Genauso ist es mit localen Variablen solange der Dialog noch steht.
Nach dem Ende der Funktion, Prozedur oder Methode werden die lokalen Variablen gelöscht (also die Zeiger wie hier oXbp), das Control (oder der Font, Drucker etc.) selbst bleibt aber bestehen bis ein destroy() explizit aufgerufen oder das Programm beendet wird. Dass beim Programmende aufgeräumt wird hängt irgendwie mit der Xbase++ Laufzeitumgebung zusammen (automatisches Destroy vom Hauptdialog aus - andere Sprachen machen noch nicht einmal dieses Aufräumen).

Aus diesem Grunde wird im Classcode auch keine LOCAL Variable für die Erzeugung der Controls benutz, sondern eine INSTANZ Variable.

[Manfred]

Hi Hubert,

Aus diesem Grunde wird im Classcode auch keine LOCAL Variable für die Erzeugung der Controls benutz, sondern eine INSTANZ Variable.

ich glaube ich verstehe langsam, aber könntest Du mir das nochmals etwas näher erklären? Ich vermute einmal, das wäre der letzte Tropfen, der evtl. noch fehlen könnte.

[brandelh]

Hi Manfred,

ich hatte den 2. Teil vergessen ...

eigene Klassen ohne Bezug auf Betriebssystem und XbParts brauchen eigentlich weder ein Create (zuordnen der System Resourcen) noch ein destroy().

Alles was XbaseParts oder Betriebssystemresourcen nutzt braucht auch ein Create() und alles was ein Create() aufgerufen hat braucht auch ein destroy() !

Mag sein, dass man im einen oder anderen Sonderfall darauf verzichten könnte, aber man spart sich Ärger wenn man sich an die einfache Regel hält.

[Manfred]

Hi Hubert,

ich glaube, dass war es was mir die ganze Zeit unter den Nägeln juckte. Danke für den Hinweis.

PS: Steht das auch so im Handbuch? Muß ich wohl überlesen haben.

[Bertram Hansen]

Hallo Hubert,

ich bin gerade dabei einige Dinge der Devcon aufzuarbeiten und beziehe mich mal auf ein konkretes Beispiel aus dem Vortag vom Jose Luis Otermin vom Donnerstag 9:45 "OOP Basic" (Devcon Ordner Kapitel HowTo Day OOP Basic Seite 13).
Das dort erzeugte Object Object() wird nicht durch ein destroy() zerstört. Wenn das Object local in einer Funktion mit new() erzeugt wird und man die Funktion verlässt, bleiben dann noch "Reststücke" vom Objekt? Oder muss das Objekt noch "zerstört" werden?

[Martin Altmann]

Hallo Bertram,
schaust Du in dem alten Exemplar (das weniger als 18 Seiten hatte) oder in dem neuen?
Bei mir sind auf Seite 13 zwei Beispiele - eines ist überschrieben mit Dynamic Class Creation und das andere mit Object Factory.

Viele Grüße,
Martin

[Bertram Hansen]

Hallo Martin,

ja in dem "alten" Exemplar das untere Beispiel.

[Martin Altmann]

Gut,
das habe ich nicht mehr...

Viele Grüße,
Martin

[Bertram Hansen]

Hallo Martin,

ok hier kommt das Beispiel:

Code: Alles auswählen

PROCEDURE Main()
   local oObject := Object():new()
   CreateFoo()
   ? oObject:Foo
   WAIT
RETURN

PROCEDURE CreateFoo()
   LOCAL aStructure := {{ "FOO", "C", 10,0 }}
   DBCreate( "FOO.DBF", aStructure, "DBFNTX")
   USE FOO
   DBAppend()
   REPLACE FOO WITH "Foo Data"
RETURN

CLASS Object
   EXPORTED:
      VAR Foo
      METHOD Init
ENDCLASS

METHOD Object:Init
   ::Foo := "Foo Fighters"
RETURN Self

Wenn das Objekt nicht in der Main() sondern in einer anderen Funktion mit new() erzeugt wird, muss dann auch ein destroy() durchgeführt werden?

[AUGE_OHR]

hi,

Code: Alles auswählen

   ? oObject:Foo

ich war leider nicht in der Veranstaltung am Do., aber ich habe mit Jose
noch nach meinem Vortrag geredet. Das Beispiel was du da nennst sollte
IMHO etwas anderes zeigen nämlich was beim "?" rauskommt ...

"Foo Fighters" oder "Foo Data" ??? ... tja und dann die Frage wieso ...

gruss by OHR
Jimmy

[Martin Altmann]

Hallo Jimmy,
genau - es galt dem aufzeigen der Probleme von Überlagerung von Objekten und Gültigkeiten bei Namensgleichheit.

Betram,
ich würde eine Klasse immer destroyen, wenn ich sie nicht mehr brauche.
Auch um eventuelle Probleme mit den sogenannten "detached locals" (einfach mal hier im Forum danach suchen) zu umgehen!

Viele Grüße,
Martin

[brandelh]

Hi,

wenn man eine eigene Klasse macht, die keinen Zugriff auf Systemresourcen (fonts, druckerdevices etc. ) hat, also z.B. nur Speichervariablen bedient, braucht diese weder ein Create() noch ein destroy().
Die DBE würde in dem Beispiel durch das Programmende bereinigt, aber da man nicht weiß was in dem Beispiel Object() intern macht, würde ich create() und destroy() aufrufen, auch wenn es in dem Beispiel eventuell eingespart wurde.

Viele fehlende Destroy() werden ja auch durch das destroy() des Main-Windows (-> Child:destroy()) ausgeglichen. Dumm nur wenn man dann von einem anderen Fenster vererbt hat. Ein destroy() kostet doch nichts und bringt Sicherheit über den Zustand.

[Bertram Hansen]

1. Frage:

da das in dem Beispiel verwendete Objekt keine Methode destroy() hat, muss ich doch selbst eine Methode destroy() definieren oder? Was aber soll die Methode destroy() machen? Soll nur die Klassenvariable Foo mit NIL belegt werden?
Siehe Beispiel:

Code: Alles auswählen

METHOD Object:Destroy
   ::Foo := NIL
RETURN Self 

oder...


2.Frage:

ich habe leider den Vortrag von Jose verpasst, da ich bei Hubert im Vortrag war. Was kam den bei dem Beispiel von Jose als Ergebnis von

Code: Alles auswählen

?Foo

raus? "Foo Fighters" oder "Foo Data"


Ich möchte diese ganze Klassengeschichte von Grund auf verstehen.

[brandelh]

Hallo Martin,

ok hier kommt das Beispiel:

Code: Alles auswählen

PROCEDURE Main()
   local oObject := Object():new()
   CreateFoo()
   ? oObject:Foo
   WAIT
RETURN

PROCEDURE CreateFoo()
   LOCAL aStructure := {{ "FOO", "C", 10,0 }}
   DBCreate( "FOO.DBF", aStructure, "DBFNTX")
   USE FOO
   DBAppend()
   REPLACE FOO WITH "Foo Data"
RETURN

CLASS Object
   EXPORTED:
      VAR Foo
      METHOD Init
ENDCLASS

METHOD Object:Init
   ::Foo := "Foo Fighters"
RETURN Self

Wenn das Objekt nicht in der Main() sondern in einer anderen Funktion mit new() erzeugt wird, muss dann auch ein destroy() durchgeführt werden?

Dieses Beispiel irritiert mich etwas, denn es enthält eine PROZEDUR CreateFoo und eine CLASS OBJECT die in diesem Beispiel nichts miteinander zu tun haben !

Was passiert :

Code: Alles auswählen

PROCEDURE Main()
   local oObject := Object():new() [color=red]// hier wird oObject erzeugt

intern also  INIT() ausgeführt und  ::Foo := "Foo Fighters" gesetzt

[/color]

   CreateFoo() [color=red] // hier wird unabhängig davon eine DBF erzeugt. ACHSO ! Und geöffnet. [/color]

   ? oObject:Foo [color=red]// was wird hier nun angezeigt ?

sicher NICHT das Feld FOO, sondern die Instanzvariable des Objectes, also ->  Foo Fighters [/color]

   WAIT
RETURN

PROCEDURE CreateFoo()
   LOCAL aStructure := {{ "FOO", "C", 10,0 }}
   DBCreate( "FOO.DBF", aStructure, "DBFNTX")
   USE FOO
   DBAppend()
   REPLACE FOO WITH "Foo Data"
RETURN

CLASS Object
   EXPORTED:
      VAR Foo
      METHOD Init
ENDCLASS

METHOD Object:Init
   ::Foo := "Foo Fighters"
RETURN Self

[Martin Altmann]

Hallo Hubert,
Du hast es richtig erkannt - gratuliere
Entscheidender ist das Beispiel davor (in den Unterlagen) - da ist dann nicht mehr so einfach sichtbar, was angezeigt wird.

Viele Grüße,
Martin

[Bertram Hansen]

An Hubert,

vielen Dank für die Antwort auf meine 2.Frage.
Dann war da noch meine 1.Frage.

da das in dem Beispiel verwendete Objekt keine Methode destroy() hat, muss ich doch selbst eine Methode destroy() definieren oder? Was aber soll die Methode destroy() machen? Soll nur die Klassenvariable Foo mit NIL belegt werden?
Siehe Beispiel:
Code:

METHOD Object:Destroy
::Foo := NIL
RETURN Self

oder...

[brandelh]

Hi,

in diesem Beispiel braucht man keine Methode destroy(),
da bei Programmende alle Variablen gelöscht und freigegeben werden.

In großen Programmen macht es Sinn den Inhalt von große Stringvariablen mit "" oder NIL selbst zurückzusetzen um es dem Garbage Collector leichter zu machen. Nötig wäre es nicht.

[Bertram Hansen]

Danke Hubert!

[AUGE_OHR]

Dann war da noch meine 1.Frage.

da das in dem Beispiel verwendete Objekt keine Methode destroy() hat, muss ich doch selbst eine Methode destroy() definieren oder? Was aber soll die Methode destroy() machen? Soll nur die Klassenvariable Foo mit NIL belegt werden?
Siehe Beispiel:
Code:

METHOD Object:Destroy
::Foo := NIL
RETURN Self

oder...

Nope damit setzt du ja nur die Instanzvariable auf NIL. Du willst aber das
Object "oObject" aus dem Speicher haben also muss du das NIL setzten.

Jede Variable ist im Grunde nur ein Referenz auf den Speicher. Wird nun
diese auf NIL gesetzt so wird diese Referenz "gelöst". Der CG schaut nun
von Zeit zu Zeit nach ob es Variablen ohne Referenz gibt und schmeisst
die dann raus.
Sollte nun aus irgendeinem Grund die Referenz nicht gelöste werden
können weil noch "aktive" (z.b. Thread mit Starttime() der vorher
abgebrochen wird) dann hat man das Problem mit dem RAM Verbrauch.

gruss by OHR
Jimmy