Type-Problem

[Igotcha]

Hallo zusammen,

ich passe gerade ein von Hagen hier beschriebenes modulares Programmsystem auf meine Bedürfnisse an.

Allerdings habe ich mit folgender Funktionalität Probleme:

Delphi-Quellcode:

type 
  TModularForm = class(TForm) 
  protected 
    function GetParam(const Name: String): Variant; virtual; 
    procedure SetParam(const Name: String; Data: Variant); virtual; 
  public 
    class procedure Register; 
 // wir erweitern nun unser gemeinsammes Basis Interface 
    //class function FormularName: String; virtual; abstract; 
    //class function MenuPath: String; virtual; abstract; 
 
    property Param[Name: String]: Variant read GetParam write SetParam; // <--- hier
  end; 

...

function TModularForm.GetParam(const Name: String): Variant;
begin
  Result := TypInfo.GetVariantProp(Self, Name);
end;

procedure TModularForm.SetParam(const Name: String; Data: Variant);
begin
  TypInfo.SetVariantProp(Self, Name, Data);
end;

Ich habe entgegen dem Beispiel noch die Unit "TypInfo" in die uses-Klausel mit aufgenommen, da das Beispiel ohne diese nicht funktioniert.

Allerdings erhalte ich dann für die angegebene Zeile nun ein:

[Error] FormMain.pas(26): Incompatible types Gruß Igotcha

[sniper_w]

 procedure SetParam(const Name: String; Data: Variant); virtual; Das ist ein Fehler, IMHO.
Du solltest es so machen:
 procedure SetParam( Data: Variant); virtual;

[Igotcha]

Hmmm, ich habe das gerade als "Clou" interpretiert, dass ich mit
procedure SetParam(const Name: String; Data: Variant); virtual; quasi eine "Allround-Möglichkeit" habe, um Properties innerhalb des gesamten Modulgeflechts setzen zu können...

Gruß Igotcha

[jim_raynor]

Muss Data nicht auch const sein?

[Igotcha]

Zitat von jim_raynor:

Muss Data nicht auch const sein?

Ändert leider nichts

Der Cursor landet genau hinter dem "write" in der o.g. Zeile.

[negaH]

Tja, ich wusste das auch nicht was Borland da wiedermal geändert hat, so müsste es gehen:

Delphi-Quellcode:

    function GetParam(const Name: String): Variant; virtual;
    procedure SetParam(const Name: String; const Data: Variant); virtual;
  public
    class procedure Register;

    property Param[const Name: String]: Variant read GetParam write SetParam;
  end;

Der Index einer Property, wenn er vom Typ LongString ist, muß anscheinend jetzt immer als const deklariert werden. Ansich ist das logisch, unlogisch ist nur das man zb. in D3 auch ohne const arbeiten konnnte (wenn ich mich recht erinnere).

Zitat:

quasi eine "Allround-Möglichkeit" habe, um Properties innerhalb des gesamten Modulgeflechts setzen zu können...

Ja, so war es auch gedacht

Gruß Hagen

[Igotcha]

Funktioniert jetzt, danke!

[Timelesk]

Hallo,

ich habe meinen Code auch von Hagen und hatte das selbe Problem.
Nun funktioniert das soweit unter Delphi2006.

Aber wie kann ich jetzt Werte übergeben?
Über einen Button im MainForm rufe ich das nach dem Laden des Formulars auf:
modul1.SetParam('test', Button1.Caption); Und danach teste ich anhand eines weiteren Buttons im Modul, ob der Wert übergeben wurde:
label1.caption := string(ModularForm1.GetParam('test')); Leider gibt er mir aber bereits bei SetParam diese Fehlermeldung aus: Eigenschaft test existiert nicht

Wo muss man denn das noch definieren?


Vielen Dank

[Muetze1]

Zitat von negaH:

Delphi-Quellcode:

    function GetParam(const Name: String): Variant; virtual;
    procedure SetParam(const Name: String; const Data: Variant); virtual;
  public
    class procedure Register;

    property Param[const Name: String]: Variant read GetParam write SetParam;
  end;

Ich habe eine Frage dazu: In der OH steht aber vermerkt, dass Property Getter/Setter nicht virtuell sein dürfen. Ich habe aufgrund dessen extra mein Design ändern müssen. Ist dies hinfällig?

[negaH]

Hm, das wäre mir absolut neu. Mich interessiert als Refernez nur das was die RTTI und somit der Compiler kann. In TypInfo.pas kann man sehr wohl lesen, als verwendeter realer Source!!, das eine Property auch virtuelle Getter/Setter haben kann.

Das spielt aber auch keine Rolle wenn es nicht so wäre. Dann ändern wir es so um das die Getter/Stetter statisch sind und intern als Dispatcher an 2 virtuelle Methoden weiterreichen.

Mich würde aber mal interessieren WO du das in der OH gelesen haben willst. Weil es dort nicht explizit steht und nur Beispiele mit statischen Methoden drinenstehen, heist dies noch lange nicht das es nicht geht. Ich programmiere seit es Delphi gibt (genauer seit BP4.0) und eine Setter/Getter Methode konnte schon immer statisch oder virtuell aber nicht dynamisch und somit ergo auch keine Nachrichtenmethode eg. als message deklariert sein. Sie darf sogar eine abstrakte Methode sein, und damit eben auch virtuell (abstrakte statische Methoden machen keinen Sinn).

Aus Sicht der Logik ist es auch sinnvoll, wenn man schon überschreibbare Methoden kennt, die Setter/Getter Methoden, die ja wiederum nur ein weiteres Qualitätsmerkmal der OOP umsetzen -> Properties, ebenfalls virtualisieren zu können. Warum sollten gerade auf die neueren Properties nicht die Regeln der OOP gelten ? (das wäre ein unlogischer Schritt von Borland gewesen den ich wohl am meisten kritisieren würde). Das man die Getter/Setter nicht dynamisch deklarieren kann ist eine Frage von Effizienz im Code. Sie wären unnötig langsam und brächten keinen Vorteil da man zu 99.99% der Zeit eine Property mit Getter/Setter Methoden sofort implementiert, statt mit dem Ziele sie über dynamische Methoden erst viel später durchimplementieren zu wollen. Hier zählt also der Kompromis von Aufwand und Nutzen der gegen dynamsiche Setter/Getter spricht. Der Sinn einer dynamsichen Methode besteht in der OOP darin das der Initial Entwickler einen Schnittstellenrumpf vorgeben kann ohne diese real implementieren zu müssen. Im Falle der Properties sind dynmische Methoden absolut sinnfrei, bzw. zu 99.9% sinnfrei
Das man dabei aber diese Methoden nicht als Messagemethoden deklarieren kann ist ebenfalls sinnvoll da sie mit einem Messaging nichts zu tuen haben. Davon abgesehen sind Messagemethoden eng verknüpft mit den dynamischen Methoden, infakt es sind dynamische Methoden mit explizierter Angabe der Slotnummer der DMT im Source (früher in BP konnte man die Slotnummer auch bei normalen dynamsichen Methoden vorgeben, heute geht dies nicht mehr, schade). Ergo: da dynamische Setter/Getter nicht gehen, können auch Messagemethoden nicht funktionieren.

Wie man sieht: die Regeln der OOP und wie die Borlanianer die VCL konstruiert haben unterwerfen sich zwingender Logik. Einer Logik die man selber nachvollziehen kann und mit der wir quasi schon erraten können was in der VCL geht oder nicht geht.

Ich schlage bei sowas immer vor: einfach selber mal ausprobieren statt sich einfach auf Meinungen Andere zu verlassen (davon gibts nämlich ne Menge Pseudowissen).

Gruß Hagen