Type-Problem

[negaH]

Zitat:

Leider gibt er mir aber bereits bei SetParam diese Fehlermeldung aus: Eigenschaft test existiert nicht

Wo muss man denn das noch definieren?

Und? existiert denn eine Property "Test" in deiner TForm Klasse ?

Die Setter/Getter Methode .SetParam() und .GetParam() sind deshalb virtuell weil der Entwickler die Möglichkeit hat ZWEI verschiedene Implementierungswege einzuschlagen.

1.) direkte Auswertung in den Getter/Setter Methoden der übergebenen Parameter. Das ist das was du in deiner .SetParam() Methode mit Label1.Caption := Data; gemacht hast. Du wertest den Parameter Index/Name garnicht selektiv aus.

2.) automatische Auswertung über Properties die über TypInfo und Variants erfolgt.


DU hast also in deine Methode .GetParam() die Methode 2. gewählt ohne jedoch eine Property "Test" zu deklarieren. Im Setter .SetParam() wählst du Methode 1. und damit mischt du zwei grunverschiedene Implementierungswege. Die übrigens nur ein Vorschlag meinerseits waren.

Gruß Hagen

[Muetze1]

Zitat:

Zitat von negaH

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 ziehe keine Rückschlüsse in der Form, dass wenn eins nicht geht, das Gegenteil dessen funktionieren muss. Ich programmiere seit Delphi 4 und hatte bisher auch virtuelle Property Getter/Setter verwendet (funktionierten auch), bis ich in der Hilfe folgendes gelesen hatte: (Thema: "Auf Eigenschaften zugreifen")

Zitat:

Zitat von OH

Handelt es sich bei FeldOderMethod um eine Methode, kann diese nicht überschrieben werden. Darüber hinaus müssen Zugriffsmethoden für eine als published deklarierte Eigenschaft die Standardaufrufkonventionen register verwenden.

Ich lese daraus, dass ich sie nicht überschreiben kann und somit soll.

[Hawkeye219]

Die Delphi5-Hilfe enthält an dieser Stelle offenbar einen (Übersetzungs?)Fehler.

Zitat:

Zitat von Delphi6-Hilfe

Wenn FeldOderMethode eine Methode ist, kann sie nicht überladen werden. Zugriffsmethoden für eine als published deklarierte Eigenschaft müssen die Standard-Aufrufkonvention register verwenden.

Zitat:

Zitat von Delphi2006-Hlife

Wenn FeldOderMethode eine Methode ist, kann diese nicht dynamisch sein. Falls es sich um eine virtuelle Methode handelt, kann diese nicht überladen werden. Zugriffsmethoden für eine als published deklarierte Eigenschaft müssen die Standard-Aufrufkonvention register verwenden.

Gruß Hawkeye

[Muetze1]

Ok, dann ist alles klar. Das mit dem überladen ist ja auch vollkommen nachvollziehbar. Ok, danke, dann wäre das geklärt. Nun ja, die Änderungen habe ich an dem Projekt nun schon gemacht, aber bei nächsten Projekten kann ich dann wieder virtuelle Getter/Setter nutzen (die ja, wie gesagt, einwandfrei funktioniert hatten - daher war ich damals recht erstaunt dies zu lesen).

[Timelesk]

Hallo Hagen,

danke für deine Antwort.

Zitat:

Zitat von negaH

1.) direkte Auswertung in den Getter/Setter Methoden der übergebenen Parameter. Das ist das was du in deiner .SetParam() Methode mit Label1.Caption := Data; gemacht hast. Du wertest den Parameter Index/Name garnicht selektiv aus.

Hier habe ich der property "test" die Caption von Button1 zugewiesen, also doch Weg 2 mit Properties gewählt.

Hier mal meine beiden Funktionen:

Delphi-Quellcode:

{Lade übergebene Variable}
function TModulForm.GetParam(const Name: String): Variant;
begin
  Result := TypInfo.GetVariantProp(Self, Name);
end;

{Setze zu übergebende Variable}
procedure TModulForm.SetParam(const Name: String;const Data: Variant);
begin
  TypInfo.SetVariantProp(Self, Name, Data);
end;

Zitat:

Zitat von negaH

DU hast also in deine Methode .GetParam() die Methode 2. gewählt ohne jedoch eine Property "Test" zu deklarieren. Im Setter .SetParam() wählst du Methode 1. und damit mischt du zwei grunverschiedene Implementierungswege. Die übrigens nur ein Vorschlag meinerseits waren.

Ich habe gemerkt, dass ich die Property "test" wirklich nicht gesetzt hatte.
Nun funktioniert das soweit mit Zahlen und Boolschen Properties.
Aber bei Strings gibt mir Delphi beim Beenden des Programmes eine Zugriffsverletzung aus.

1. In der MainForm (Anker-Unit) rufe ich nach dem erstellen des Formulars des Moduls diesen Code auf: modul1.SetParam('VarString', 'Stringübergabe');
2. Im Modul ist das ganze so deklariert:

Delphi-Quellcode:

  TModulForm1 = class(TModulForm)
  protected
    function GetParam(const Name: String): Variant; override;
    procedure SetParam(const Name: String;const Data: Variant); override;
  private
    //Deklarierung der Parameter für GetParam und SetParam
    FVarString  : String;
  published
    //Deklarierung der Parameter für GetParam und SetParam

    property VarString  : String  read FVarString  write FVarString;
  end;

{...}

function TModulForm1.GetParam(const Name: String): Variant;
begin
  Result := inherited GetParam(Name);
end;

procedure TModulForm1.SetParam(const Name: String;const Data: Variant);
begin
  // da wir das schon in der Basisklasse getan haben also einfach
  inherited SetParam(Name, Data);
end;

{...}

//Aufruf erfolgt per Button in ein Label
bfAusgabe.Caption := GetParam('VarString');

Ich sehe dort keinen Fehler und trotzdem kommt eine EAccessViolation in module rtl100.bpl
Kommt aber nur, sofern ich SetParam ausgeführt habe! Wenn ich nur GetParam ausführe und das Programm beende, kommt keine Fehlermeldung.


Desweiteren bin ich noch am tüfteln, wie ich z.B. per Button im Modul die Caption des Moduls ändere.
Man könnte Caption := 'Neuer Modultitel'; schreiben, aber wie kann ich das über den Modulnamen + Caption machen (in Form von Modulname.Caption) ?


Vielen Dank für die Hilfe

gruß
Timelesk

[negaH]

;) das meinte ich mit "traue niemals Leuten die nicht vom Fach sind". EIn Übersetzer versteht garnicht was er da übersetzt und der verantwortliche "Programmierer" hat garnicht die Zeit alles ins kleinste Detail zu überprüfen.

Deshalb zählen im Grunde die Dokumentationen in Form eines Sourcecodes, und es ist meine erste "Amtshandlung", wenn ich eine neue Delphi version bekomme, deren RTL Source zu lesen. Deshalb weis ich definitiv das Unit TypInfo.pas von allen Delphiversionen der Zugriff auf Property per RTTI virtuelle Methoden unterstützen.

Überladene Methoden (overload) können bei Property nicht gehen, warum auch. Das würde bedeuten das das nur Sinn macht wenn man auch überladene Properties deklararien könnte. Das macht höchstens Sinn bei indizierten Array[] Properties. da nur bei deren Getter/Setter ein Parameter zur eindeutigen Indentifizierung des overloads vorhanden ist. Bekannntlich kann Delphi ja keine Overloads auf Funktionen in deren Parametersignatur nur der Resulttype unterschiedlich ist. Das würde auf normale Getter/Setter Methoden dann zutreffen.

Wenn ichs mir aber recht überlege, dann wären überladene indizierbare Properties garnichtmal so schlecht. Sowas ginge dann

Delphi-Quellcode:

type
  THashTable = class
  private
    function GetItem(const Index: String): THashItem; virtual; overload;
    function GetItem(const Index: Int64): THashItem; virtual; overload;
...   
  public
    property Item[const Index: String]: THashItem read GetItem write SetItem; overload;
    property Item[const Index: Int64]: THashItem read GetItem write SetItem; overload; 
  end;

Hm, andererseits nimmt man dann halt einen Variant als Index.

Gruß Hagen

[negaH]

Gut, denn

Zitat:

ch sehe dort keinen Fehler und trotzdem kommt eine EAccessViolation in module rtl100.bpl
Kommt aber nur, sofern ich SetParam ausgeführt habe! Wenn ich nur GetParam ausführe und das Programm beende, kommt keine Fehlermeldung.

ich sehe in deinem Source ebenfalls keinen Fehler (du bist also nicht verrückt :) )

Vermutung meinerseits wäre es:

a.) .SetParam('VarString', xyz); achte mal darauf das der Name der Property exakt ist. Das sollte eigentlich egal sein ob man Groß/Klein schreibt aber man weis ja nie was Borland so alles in den Units verändert mit den Versionen.

b.) FormVariable.SetParam(); achte darauf das FormVariable auch ein gültiges TForm enthält

c.) Unit Variants eventuell "schei.e" ?

So oft arbeite ich nicht mit Varianten, aber ichw eis das je nach Delphiversionen es so einige Probleme geben sollte. Ich vermeide sie deshalb. Aber in Bezug auf mein Beispeil wäre sie die flexibelste Alternative. Ehrlicherweise muß ich zugeben das mein Beispiel aus den Erfahrungen eines parellelen Entwicktungsprozesses meines eigenen Modulsystemes entstand.

Gruß Hagen

[Timelesk]

Hallo Hagen,

vielen Dank für die schneller Antwort.

Ich habe nun einfach mal in der TypInfo nach Variant gesucht und herausgefunden, dass die Funktionen GetPropValue und SetPropValue ebenfalls mit Varianten arbeiten und siehe da: Es funktioniert mit Strings!

Zitat:

b.) FormVariable.SetParam(); achte darauf das FormVariable auch ein gültiges TForm enthält

Du meinst sicherlich TModulForm, also die Ableitung von TForm, oder?
Und genau das ist ja mein Problem:
im Hauptformular (in der auch die abgeleitete Klasse steht) wird ja das Package geladen und die Form über CreateModuleForm erstellt:

Delphi-Quellcode:

var modul1: TModulForm;
begin
  {...}
  modul1 := CreateModuleForm('TModulForm1');
end;

Jetzt kann ich von der Hauptform aus modul1.WindowState := wsMaximized schreiben und das klappt auch ganz schön :)
Aber im Modul selbst, wie kann ich dort das Formular ansprechen?
modul1 ist dort ja nicht registriert und wenn ich einfach ne Variable registrier ModulForm1 : TModulForm1, dann ist das ja nicht die Variable, welche auf mein Modul-Formular zeigt und ändert dementsprechend auch nichts ab.
Aber genau das möchte ich erreichen, dass ich im Modul selbst das Formular des Moduls ansprechen kann.

Ich hoffe, das war jetzt verständlich ;)


Vielen Dank

gruß
Timelesk

[negaH]

Im Modul selber greifst du OOP konform zu, dh. immer über Self. Niemals über die globale Variable ModulForm1: TModulForm1, da diese ja garnicht mehr benutzt wird und zudem ist der Zugriff, egal ob Modulbasiert oder in normalen Delphi Anwendung, über diese Variable generell kontraproduktiv. Wenn man sowas denoch benötigt muß man sich eben bessere Wege einfallen lassen als Programierer. Denn benutzt man diese Variable dann verhindert man damit das multiple Erzeugen von mehreren Formularen der gleichen Instanz.

Gruß Hagen