GetPropList weigert sich

[Medium]

Die 3. Überladung von GetPropList hat explizit "TObject" als Parameter, kein TComponent, kein TPersistent, kein nix. Die Hilfe erwähnt auch nirgends, dass da doch kein TObject übergeben werden darf, und somit würde ich eigentlich annehmen, dass das so okay ist. Ist das am Ende wieder nur eine Verwirrung dank genialer Dokumentation (und irreführender Parameterliste) seitens Emba?
Was wäre denn die "kleinste" Basisklasse, für die ich GetPropInfo() benutzen kann?

[guinnes]

Gehen bei den "Alten" Delphi's nicht nur Published-Properties ?

[Medium]

Das habe ich mittlerweile auch probiert, weil mir so etwas im Hinterkopf war. Zwar hätte dann der Rückgabewert von GetPropList() einfach nur 0 sein dürfen, und keine AV auslösen, aber einen Versuch war es dennoch wert. Leider mit dem selben Ergebnis: AV

Mag keiner fix mein kleines Testprojekt von weiter oben mal anfahren? Ich würde gerne klären, ob es eventuell an meinem Delphi bzw. sonstigem Setup liegt, oder ich wirklich ein tiefgreifendes Verständnisproblem hier habe

[guinnes]

Zitat von Medium:

Das habe ich mittlerweile auch probiert, weil mir so etwas im Hinterkopf war. Zwar hätte dann der Rückgabewert von GetPropList() einfach nur 0 sein dürfen, und keine AV auslösen, aber einen Versuch war es dennoch wert. Leider mit dem selben Ergebnis: AV

Hast du dabei auch von TPersistent abgeleitet ? Published macht darunter keinen Sinn

[implementation]

Habe das fertige Kompilat von dem Testprogramm mal hier bei mir über Wine ausgeführt. Auch hier eine AV auf $00000001.
Delphi habe ich nicht, aber ich habe es mal mit dem FPC gegen die LCL kompiliert, das läuft problemlos.

[einbeliebigername]

Hallo,

Zitat von Medium:

Ist das am Ende wieder nur eine Verwirrung dank genialer Dokumentation (und irreführender Parameterliste) seitens Emba?
Was wäre denn die "kleinste" Basisklasse, für die ich GetPropInfo() benutzen kann?

Na ja der Parametertyp ist schon von Emba richtig gewählt. Also entweder du Erbst von TPersistent oder aber du setzt um deine Klasse ein

Delphi-Quellcode:

{$M+}

{$M-}

herum. Wenn du ohne diesen Schalter anzumachen von einer Klasse erbst, bei deren Definition dieser nicht an war und einen Published-Teil hast, wirft Delphi eine Warnung. In der Hilfe zu der Warnung ist glaube ich das Thema auch erklärt.

Einbeliebigername.

Edit: Was vergessen.

[Medium]

Diese Warnung hatte ich nicht (Weiss ich recht genau, da ich mit einem Kompilat idR erst zufrieden bin, wenn 0 Fehler, 0 Warnungen und 0 Hinweise nach Erstellen da stehen.)
Ich werd das morgen nochmals testen, da ich wegen RegisterClass() (wegen FindClass()) nun ohnehin auf TPersistent aufsetze. Ein dumpfes Gefühl sagt mir, dass das dennoch in diesem seltsamen "Hüpfer" enden wird, aber man soll ja optimistisch sein! Danke euch schon mal!

[einbeliebigername]

Hallo,

Zitat von Medium:

Diese Warnung hatte ich nicht (Weiss ich recht genau, da ich mit einem Kompilat idR erst zufrieden bin, wenn 0 Fehler, 0 Warnungen und 0 Hinweise nach Erstellen da stehen.)

Aber als du es mit published probiert hast, muss es eine Warnung gegeben haben. Ansonsten sehr löblich.

Ich habe noch mal mein Rad2007 angeworfen und ein Test-Programm geschrieben. Beim Schreiben ist mir dann auch noch ein Fehler in deinem Code aufgefallen. In der Zeile for i := 0 to propCount do fehlt das -1 .

Folgender Sourcecode steht zur Diskussion.

Delphi-Quellcode:

program RttiProject1;

{$APPTYPE CONSOLE}

uses
  Classes,
  TypInfo;

type
  //{$M+} // Variante 1
  TTest= class//(TPersistent) // Variante 2
  strict private
    fTest: Integer;
  published
    property Test: Integer read fTest write fTest;
  end;
  //{$M-} 

var
  Obj: TTest;
  List: PPropList;
  Count, I: Integer;

begin
  Obj:= TTest.Create;
  try
    Count := GetPropList(Obj, List);
    for I := 0 to Count- 1 do
      Writeln(List[I].Name);
  finally
    Obj.Free;
  end;
  Writeln('Press Enter');
  Readln;
end.

Wenn man den so kompiliert, mit dem Auskommentierten, gibt es folgende Warnung:

Code:

[DCC Warnung] RttiProject1.dpr(14): W1055 PUBLISHED verursachte, dass RTTI ($M+) zu Typ 'TTest' hinzugefügt wurde

Man sollte sich den Text auch mal durch lesen. Denn eigentlich ist das genau das was du willst. Trotzdem funktioniert das Programm nicht wie gewollt. Es bleibt bei GetPropList hängen (Nach 10 Sekunden hatte ich keine Lust mehr zu warten). Erst wenn man Variante 1 oder 2 ein kommentiert geht es wie gewollt. Wenn man ohne Variante 1 und 2 auf das published verzichtet hängt es auch. Wer lügt da nun. Die Warnung oder die Funktion. Ich Tippe auf den Compiler, der hat immer Schuld.

Einbeliebigername.

[Medium]

Da brat mir einen einen Storch. Du hast von vorne bis hinten Recht, auch mit der Warnung. Manchmal ist man ja schon etwas Blindfischig. Mit TPersistent als Vorfahr geht alles wie am Schnürchen, und da ich es ohnehin brauche, ist meine Welt nun wieder völlig genesen Besten Dank an alle! (FPC scheint da dann wohl etwas weniger stringent zu sein.)

[implementation]

Zitat von Medium:

(FPC scheint da dann wohl etwas weniger stringent zu sein.)

Der macht da keine Probleme. Man kann TObject-Nachfahren Published-Properties geben und sie auch wieder abfragen. Es hat mich jetzt gewundert, dass das in Delphi nur ab TPersistent geht. Was ist denn der Grund dazu?