AGB  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language Delphi OOP, Objekte neu laden, Komponenten aktualisieren

OOP, Objekte neu laden, Komponenten aktualisieren

Ein Thema von TheMiller · begonnen am 12. Apr 2012 · letzter Beitrag vom 13. Apr 2012
Antwort Antwort
Seite 2 von 2     12
Benutzerbild von stahli
stahli
Online

Registriert seit: 26. Nov 2003
Ort: Halle/Saale
3.237 Beiträge
 
Delphi XE3 Ultimate
 
#11

AW: OOP, Objekte neu laden, Komponenten aktualisieren

  Alt 13. Apr 2012, 12:50
Kann aber auch vielleicht nur Einbildung sein, weil ich gerade nur die Hälfte verstanden habe
Ok, ich versuche es nochmal, wobei ich Dich auch nur halb verstehe.

Du musst unterscheiden, ob Dein Auto aufgelöst, durch ein neues ersetzt oder nur seine Farbe geändert wird.

Wenn ein Control (z.B. ein TPanelAuto) das Kennzeichen Deines Autos und dessen Farbe darstellen soll, würdest Du ihm dafür eine Autoinstanz (Autoobjekt "DataAuto" mit Kennzeichen und Farbwert) zuweisen. Wenn sich das TPanelAuto zeichnet (wann immer das auch ist), liest es aus dem Autoobjekt die benötigten Daten.

Das PanelAuto benutzt dafür die zugewiesene Speicheradresse. Wenn das Autoobjekt inzwischen aufgelöst wurde, bekommt PanelAuto das erst mal nicht mit. Es kann nicht einmal erkennen, ob das "DataAuto" überhaupt noch gültig ist.

Um das zu verwalten könnte man jedes erzeugte DataAuto-Objekt in eine Liste schreiben und beim Zerstören daraus entfernen. PanelAuto könnte nun nachschauen, od sein DataAuto noch in der Gültigkeitsliste enthalten ist.
Wenn nicht, wird der Pointer gleich genilt und ein leeres Panel gezeichnet.

Alternativ kann man Observer-Patterns nutzen. Das PanelAuto meldet sich beim DataAuto an (wird in einer internen Liste von DataAuto eingetragen). Wenn DataAuto aufgelöst wird, informiert es alle registrierten Objekte aus seiner internen Liste über sein Ende. PanelAuto würde dann erfahren, dass sein DataAuto nicht mehr existiert und den Pointer nilen (worauf hin es sich auch neu zeichnet und zwar "leer"). (PanelAuto muss sich natürlich auch wieder bei DataAuto abmelden, falls es früher aufgelöst oder ihm ein anderes DataAuto zugewiesen wird.)

Wird DataAuto nicht aufgelöst, sondern erhält nur eine andere Farbe, müsste eine entsprechende Nachricht verschickt werden, damit sich PanelAuto neu zeichnet.
Das kann ebenfalls über Observer realsiert werden oder einfacher (so habe ich das bisher gelöst) durch ein Invalidate aller erzeugten PanelAuto´s. Die zeichnen sich entsorechend dann neu, sofern sie sich in einem sichtbaren Bereich befinden. Hunderte PanelAuto´s auf geschlossenen Formularen werden natürlich nicht gezeichnet und bremsen das System somit auch nicht aus.

Wird dem PanelAuto ein anderes DataAuto zugewiesen, wird intern ebenfalls Invalidate aufgerufen und das PanelAuto zeichnet sich neu.


So funktioniert das im Grunde sehr gut (siehe mein Turnierprojekt).


Allerdings ist es so nicht möglich, die Daten in einem C/S-Projekt zu nutzen. Der Client kommt ja nicht ohne Weiteres an die Objekte.

Daher würde ich künftig lieber den TPanelAuto nicht ein TDataAuto zuweisen sondern eher eine AutoId. Dann kann es sich von einer zentralen Stelle über GetDataAuto(AutoId) ein DataAuto-Objekt (oder eine Schnittstelle) abrufen, damit arbeiten und dieses wieder verwerfen.
Wird eine ungültige AutoId übergeben, kommt einfach nil zurück und Zugriffe auf ungültige Objekte sind ausgeschlossen. Auch den Observerkram kann man sich (für diesen Bereich) sparen.

Wenn die zentrale Stelle in einem Server liegt, können sich mehrere Clients daraus bedienen (also die gleichen Autos anzeigen).
Die Clients vom Server aus über Änderungen zu informieren sollte nicht weiter schwierig sein. Schwieriger wird es wohl, vom Client Änderungen zum Server zu schicken (z.B. wenn ein Auto gelöscht, hinzugefügt oder verschoben wird) und Zugriffskonflikte zu verhindern.

Auf jeden Fall wird sich eine gute Modularisierung sehr bezahlt machen, da das Projekt dadurch besser wartbar sein wird. Mehr Tipparbeit (z.B. wegen der Objekte-Zentrale oder zu definierenden Schnittstellen) würde ich heute dafür hinnehmen.
Stahli
http://www.StahliSoft.de
---
"Jetzt muss ich seh´n, dass ich kein Denkfehler mach...!?" Dittsche (2004)

Geändert von stahli (13. Apr 2012 um 13:18 Uhr)
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:57 Uhr.
Powered by vBulletin® Copyright ©2000 - 2016, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2016 by Daniel R. Wolf