Announcement

**J�rgen Thomas** · 09.09.2000, 09:18

Delphi 5: Versuche es doch einmal mit Komponenten-Vorlagen: Eine ,Basis-Listbox' mit den aktuellen Eigenschaften versehen, dann anklicken und �ber Komponenten | Vorlagen als Muster speichern - dann kann diese Vorlage jederzeit �bernommen werden, ebenso wie eine ,selbst�ndige' Komponente.

(Dies funktioniert auf jeden Fall. Ich habe es allerdings noch nicht ausprobiert, bei einer Vorlage nachtr�glich Eigenschaften zu �ndern, und wei� deshalb nicht, ob auch nachtr�gliche �nderungen an alle Ableitungen vererbt werden.

**Helmut F.Zmaritsch** · 11.09.2000, 19:16

Es geht darum, da� der Inhalt einer der vorhandenen Listboxen sich zur "Laufzeit" �ndern kann. Die anderen Listboxen sollen auch von dieser �nderung erfahren.

Wie gesagt, sie arbeiten alle mit der gleichen Datenbasis (Liste)

**Wolfgang Roller** · 14.09.2000, 00:41

Hallo Helmut,
ich m�chte deine Frage etwas globaler beantworten. Irgendwo in diesem Forum tauchte mal im Zusammenhang mit neuen Delphi-Versionen die Frage oder Bemerkung auf, was den Borland noch alles einbauen will bzw. soll. Nun eine M�glichkeit w�re zum Beispiel eine Model-View-Controller Architektur, kurz MVC genannt. Bei dieser Architektur geht man davon aus, da� bestimmte Daten an einer Stelle im Hauptspeicher gehalten werden (Model) und da� es f�r den Benutzer eine oder mehrere Sichten auf diese Daten gibt (View bzw. Views). Jede View ist maximal mit einem Controller gepaart, wobei ein Controller z.B. ein Menu sein k�nnte �ber das die Daten ge�ndert werden k�nnen. Das Model kennt alle von ihm abh�ngigen Views und benachrichtigt diese bei �nderungen am Datenbestand. 
VisualWorks, eine Smalltalk-Entwicklungsumgebung von ParcPlace, arbeitet nach diesem Modell. Ein Smalltalk-Programmierer braucht sich also um solche Dinge keine gro�en Gedanken machen. Da aber Borland es vorgezogen die Linux-Jungs endlich mit einem anst�ndigen Entwicklungswerkzeug zu begl�cken anstatt die VCL mit der MVC-Architektur auszustatten m�ssen wir Windows-Delphi-Programmierer uns selber helfen. 
Ich habe hierf�r 2 L�sungen: 
1. Die Quick and dirty-Methode: Das Model sei z.B. eine von TList abgeleitete Klasse. Diese Klasse enth�lt die Daten, die in einem Formular in einem StringGrid (Name: StringGrid1 in Form1) und in einem anderen Formular in einer ListBox (Name: ListBox1 in Form2) angezeigt werden. Die von TList abgeleitete Klasse erh�lt dann 2 �ffentliche Variablen vom Typ Boolean die dann meinetwegen hei�en:

TModel = class(TList) 
public 
StringGrid1InForm1NeedsUpdate: Boolean; 
ListBox1InForm2NeedsUpdate: Boolean;

Im Konstruktor von TModel werden beide Variablen auf True gesetzt. Die beiden Formulare Form1 und Form2 erhalten eine
OnActivate-Procedure und sie m�ssen beide das TModel-Objekt kennen. 

TForm1 = class(TForm) 
procedure FormActivate(Sender: TObject); 
private 
Model: TModel; 
public 
constructor Create(AModel: TModel); // Im Konstruktor mu� Anweisung: Model := AModel; stehen 
procedure SetModel(AModel: TModel); // Alternative. 
... 
end; 

procedure TForm1.FormActivate(Sender: TObject); 
... 
if Model.StringGrid1InForm1NeedsUpdate then begin 
FuelleStringGrid1MitDatenAusDemModel; // nur Beispiel 
Model.StringGrid1InForm1NeedsUpdate := False; 
end; 
... 
end; 

Werden die Formulare zu erstenmal angezeigt, so holen sie die Daten vom Model und zeigen sie in ihrem jeweiligen
Steuerelement an. Beide ...NeedsUpdate-Variablen sind nun wieder im Zustand False. Angenommen Form2 ist im Vordergrund
und hat den Fokus und verdeckt Form1. �ber Form2 werden die Daten des Models ge�ndert. Nun m�ssen im Model die beiden
...NeedsUpdate-Variablen auf True gesetzt werden. Bei mir erledige ich das immer in der Methode des Models, die die
Daten des Models auf die Festplatte speichert. Da Formular Form1 den Fokus bereits besitzt mu� f�r dieses das
OnActivate-Ereignis manuell ausgel�st werden damit die ListBox1 die aktuellen Daten anzeigt. Bei Form2 funktioniert
dies automatisch sobald es den Fokus erh�lt. 

Vorteil: Es gibt keinen Aktualisierungs-Overhead. Wenn Formular Form2 den Fokus beh�lt und die Daten 5 mal �ndert,
so zieht Form1 alle �nderungen nur einmal in einem Rutsch durch. Falls die Forderung besteht, da� ein halbverdecktes
Steuerelement auf einem Formular, das nicht den Fokus hat, immer die aktuellen Daten anzeigen soll, so funktioniert diese
Methode nat�rlich nicht.

Nachteil: F�r jede weitere View mu� in der TModel-Klasse eine weitere Variable ...NeedsUpdate generiert werden und
man mu� daf�r sorgen, da� sie korrekt gehandhabt wird.

Soweit so gut f�r heute. Die saubere Methode folgt sp�ter.

Gru�

Wolfgang Rolle

**Helmut F.Zmaritsch** · 15.09.2000, 20:51

Vielen Dank Wolfgang!

Ich bin auch sehr interessiert an der sauberen L�sung. Aber ich habe jetzt mal einen L�sungsansatz.

Gru�
Helmu

**Wolfgang Roller** · 21.09.2000, 16:23

Hallo Helmut,

hier folgt die versprochene saubere Methode. Hat leider etwas l�nger gedauert, aber ich wollte dir keine L�sung
anbieten, die ich nicht selber ausprobiert habe. In meinem eigenen Projekt hat bisher auch nur die Quick-and-Dirty-
Methode exisiert und die saubere nur in meinem Kopf. Ich habe dies hier zum Anla� genommen und bei mir die
saubere L�sung implementiert.

Zur Erl�uterung mu� ich hier kurz nochmals auf Smalltalk zur�ckkommen. Dort ist so, da� eine View mit einem Controller
zu einer Einheit zusammengebunden wird. Wenn z.B. ein Anwender je nach Zugeh�rigkeit zu einer Benutzergruppe
unterschiedliche Zugriffsrechte auf einen Datenbestand haben soll, so kann dies in Smalltalk so realisiert werden,
da� es zwei unterschiedliche Controller gibt, einen mit mehr Steuerungsm�glichkeiten (z.B. mit der M�glichkeit zum
L�schen.) und einen mit weniger. Je nach Benutzergruppe wird jetzt ein und dieselbe View mit dem entsprechenden
Controller verbunden und man erh�lt so ein anderes Programmverhalten. Was ich damit sagen will ist, da� bei der Smalltalk-
Klassenbilbliothek streng zwischen Anzeigen und �ndern von Daten unterschieden wird. Bei der VCL enhalten die
Anzeigeklassen wie Fenster und Listboxen normalerweise auch den Code zur Steuerung. Deshalb ist meine L�sung
eigentlich nur eine Model-View-Architektur, kurz MV-Architektur. Als Bewohner Baden-W�rttembergs denke ich beim
K�rzel MV unwillk�rlich an Mayer-Vorfelder weshalb ich im Nachfolgenden bei MVC bleiben m�chte.

Ich habe eine Unit namens MVC.pas geschrieben. Diese Unit enth�lt die Klasse:

TMVCDependencies = class(TList)
private
protected
public
destructor Destroy; override;
procedure ModelHasChanged(AAdrOfModel: Pointer);
procedure RegisterView(AAdrOfModel: Pointer; AViewForm: TForm; AUpdateProc: TUpdateProcedure);
procedure RemoveView(AAdrOfModel: Pointer; AViewForm: TForm; AUpdateProc: TUpdateProcedure);
procedure ViewFormGetsFocus(AViewForm: TForm);
end;

und eine globale Variable namens

Dependencies: TMVCDependencies;

Dieses TMVCDependencies-Objekt mu� beim Programmstart instanziert und am Programmende wieder freigegeben werden.
Dependencies �bernimmt die Verwaltung der Model-Viewer-Beziehungen und sorgt daf�r, da� die View-Objekte ihre Anzeige
updaten sobald das Formular, das sie enth�lt, den Fokus erh�lt. Ein Formular das mindestens ein View-Objekt (z.B.
eine ListBox) enth�lt nenne ich ein 'ViewForm'. 
F�r jedes View-Objekt mu� eine Procedure oder Function programmiert werden, die die Daten vom Model holt und daf�r
sorgt, da� die Daten im View-Objekt wie gew�nscht angezeigt werden. In meinem Beispiel mit der Quick and Dirty-Methode
war das z.B. die Procedure 'FuelleStringGrid1MitDatenAusDemModel'. Solche Prozeduren brauchen wir auch weiterhin.

Das Dependencies-Objekt besitzt 4 �ffentliche Methoden, die wie folgt eingesetzt werden: 
1. Jedes ViewForm mu� seine View-Objekte beim Dependencies-Objekt anmelden, und zwar jedes View-Objekt einzeln.
Sinnvollerweise wird dies im FormCreate-Ereignis mit Hilfe der Procedure 'RegisterView()' erledigt. Die Argumente,
die beim Aufruf �bergeben werden sind: Die Adresse des Models, eine Referenz auf das ViewForm und ein Methoden-Zeiger
auf diejenige Methode mit der die Daten vom Model in die View gelangen.

z.B. Dependencies.RegisterView(@Namensliste, self, FuelleStringGrid1MitDatenAusDemModel);

2. Wenn ein ViewForm zerst�rt wird, so meldet es seine Views beim Dependencies-Objekt ab. Das geschieht im
FormDestroy-Ereignis mit Hilfe der RemoveView()-Methode. Die Argumente sind gleich wie beim Anmelden.

3. Wenn das ViewForm den Fokus erh�lt schickt es die ViewFormGetsFocus-Nachricht an das Dependencies-Objekt.
Argument ist lediglich eine Referenz auf sich selber.

4. Immer wenn sich die Daten im Model ge�ndert haben und man will, da� die Views die neuesten Daten anzeigen &#13

**Wolfgang Roller** · 21.09.2000, 16:27

Teil 2:
schickt man die Nachricht 'ModelHasChanged()' an das Dependencies-Objekt. Argument f�r diese Methode ist wieder
die Adresse des Models. z.B. Dependencies.ModelHasChanged(@Namensliste). Das Dependencies-Objekt sorgt dann daf�r,
da� die Views des Formulars, das augenblicklich den Fokus hat, sofort upgedatet werden und merkt sich f�r die
�brigen Views, da� ein Update notwendig ist. Sobald ein anderes Formular den Fokus erh�lt sendet es die
ViewFormGetsFocus-Nachricht und das Dependencies-Objekt sorgt daf�r, da� die Views dieses Formulars aktualisiert
werden. Sofern eine Aktualisierung notwendig ist.

Hier nochmals das Beispiel jetzt mit der neuen Methode. Man sollte es um ein Hauptformular erg�nzen, das w�hrend
der ganzen Programmlaufzeit ge�ffnet ist. Dieses Hauptformular soll 'MainForm' hei�en. 

uses ..., MVC, ...;

procedure MainForm.FormCreate(Sender: TObject); 
begin 
... 
Dependencies := TMVCDependencies.Create; 
... 
end

procedure MainForm.FormDestroy(Sender: TObject); 
begin 
... 
Dependencies.Free; 
... 
end

Das Model, das in der Quick and Dirty-Methode f�r jede View eine entsprechende Boolean-Variable bereit halten
mu�te, mu� hier �berhaupt nicht modifiziert werden. Es mu� �berhaupt nicht �ber das Dependencies-Objekt, die
ViewForms und die Views Bescheid wissen. Da das Dependencies-Objekt lediglich die Adresse des Models kennen
mu�, ist es auch v�llig unerheblich von welcher Klasse das Model ist. Es mu� lediglich schon vor seinen
Views existieren. Das Model hier soll sein: 

Namensliste: TList;

// Initalisierung 
Namensliste := TList.Create;

Die beiden Formular-Klassen TForm1 und TForm2 m�ssen auch hier das Model kennen. Dies ist dann der Fall, wenn
das Model global ist oder wenn den Formularen im Konstruktor eine Referenz auf das Model �bergeben wird. Das
Anmelden der Views kann nat�rlich auch im Konstruktor erfolgen.

constructor TForm1.Create(AModel: TObject); 
begin 
inherited Create; 
Model := AModel; 
Dependencies.RegisterView(@Model, self, FuelleStringGrid1MitDatenAusDemModel); 
... 
end;

Beim Registrieren wird vermerkt, da� das View-Objekt ein Update ben�tigt. Dies bewirkt, da� das View-Objekt
bereits beim ersten Anzeigen die Daten des Models anzeigt, sofern bereits Daten vorhanden sind. Wenn die Daten
des Models �ber das TForm1-Objekt ge�ndert werden, so k�nnte das so aussehen:

procedure TForm1.blabla; 
var 
String1: String; 
begin 
String1 := 'Hugo'; 
Model.Add(String); 
Dependencies.ModelHasChanged(@Model); 
end;

Wenn du willst so stelle ich dir und jedem anderen, der sich daf�r interessiert, meine Unit MVC.pas im Quellcode
zur Verf�gung. Da ich noch keine eigene Homepage habe, schicke einfach eine eMail an: [email protected].
Ich maile dann zur�ck.

Wolfgang Roller<br&gt

Announcement

Mehrfache Listbox-Komponenten mit selber Quelle

Mehrfache Listbox-Komponenten mit selber Quelle

Comment

Comment

Comment

Comment

Comment

Comment