[gelöst] Interface als published property geht nicht

Ich möchte in einer Komponente ein Interface als Published Property verwenden. Es gibt soweit beim kompilieren und einbinden in Lazarus keine Probleme. Wenn ich ich die Komponente allerdings auf eine Form setze, so stürzt mir Lazarus ab.

Ist das nicht erlaubt ? Siehe Codeauszug

Code: Alles auswählen

 
  IPSECBasicUserManagment =  interface
    ['{80E18713-7638-4C58-B5EC-36F84D193423}']
    function OnlyDummy: integer;
  end;
 
........
 
 TPSECCustomLevelSecureManager = class(TComponent)
 protected
   FUserManagement:IPSECBasicUserManagment;
 protected
   function GetUserManagement: IPSECBasicUserManagment;
   procedure SetUserManagement(aUserManagment:IPSECBasicUserManagment);
 public
   constructor Create(AOwner: TComponent); override;
   destructor Destroy; override;
 published
   property UserManagement:IPSECBasicUserManagment read GetUserManagement write SetUserManagement;
 end;

Andreas

Das geht nicht, ich glaube Interface-PropertyEditor https://bugs.freepascal.org/view.php?id=31324 hat das ganze zerstört. Mann kan bei Lazarus 1.8+ auch keine ActiveX-Controls mit Formulareditor verwenden.
Ich habe aber Workaround für diesen Bug gefunden siehe here ganz unten. https://bugs.freepascal.org/view.php?id=32375 . Aber es wurde nicht in Lazarus 1.8 übernommen.
Danach kannst du es mit Formulareditor verwenden.

Sollte in Lazarus Trunk ab Revision 56886 wieder funktionieren (hoffe ich).

Danke für die Infos,

jetzt weis ich wo ich weitersuchen darf/kann. Momentan habe ich mich nicht ausgekannt, da mir der Bug Lazarus hart abgeschossen hat. Nachdem ich fpcstable/Laz fixes1.8 verwende muss ich mir mal ansehen was der Auslöser/Bugfix war, danke an Michl für den Hinweis. Eventuell kann man das über die Patchfunktion von fpcupdeluxe für die 1.8.1 temporär auch fixen. Die habe ich zwar gefunden, aber noch keinen blassen Dunst wie man die verwendet :-)

Andreas

Edit: Das Problem ist bei mir noch immer vorhanden. Ich habe versucht auf ein Beispiel zu reduzieren, das hat die Sache noch problematischer gemacht :-)

Jetzt startet Lazarus (aktueller Trunk) überhaupt nicht.
Die Testdaten und in BufInfo.txt ist die Ausgabe der Kommandozeile (mit --debug-log=BugInfo.txt) erstellt.

Bugreport hierzu: https://bugs.freepascal.org/view.php?id=32919

Es betrifft sowohl die 1.8.1 als auch die aktuelle trunk Version.

@Michl, nein DAS Problem ist damit nicht behoben. BTW: Wie debuggst du Lazarus mit Lazarus :-)

Andreas

Ich habe es mir eben angesehen. Die IDE steigt in der Funktion GetPointerProp bei Result:=TGetPointerProc(AMethod)(); aus. Ich habe auch mal dem Interface einen Dummy zugewiesen, er steigt dort trotzdem aus. Weiß z.Zt. nicht, ob der Fehler nicht eher bei FPC zu suchen ist. Mal sehen.

af0815 hat geschrieben:BTW: Wie debuggst du Lazarus mit Lazarus

Das ist fast identisch, wie ein eigenes Projekt zu debuggen. Einzig man muss über Menu -> Werkzeuge -> "Lazarus kompilieren" einrichten -> "IDE mit Debugger-Informationen" auswählen und die IDE neu bauen. Nachdem Lazarus neu gestartet ist kann man im Lazarus-Verzeichnis/ide/lazarus.lpi öffnen und normal starten (eine zweite Instanz von Lazarus wird geöffnet, die man mit der ersten Instanz debuggen kann).
Aufpassen muss man, wenn man mehrere Installationen von Lazarus auf der Platte hat, daß man das richtige Konfigurationsverzeichnis erwischt (per Menu -> Start -> Startparameter -> Kommandozeilenparemter dieses setzen), sonst zerhaut man sich seine default Lazarusversionkonfiguration.
Wenn man will, kann man auch FPC debuggen (was ich hier gemacht habe, sonst wäre nicht klar, daß obige Funktion den Fehler wirft), dazu muss man FPC mit Debugsymbolen bauen. Für Packages gilt das gleiche.
Mit der GDB-Version, die mit dem Standard-Lazarus mitkommt, nutze ich -glw2 -gh -Criot -Sa. Wenn ich in Windows Ausgaben in der Konsole haben will, kommt noch -WC dazu.
Nicht erschrecken, wenn man Lazarus von Lazarus aus startet, wird eine Exception geworfen. Einfach auf <Continue> klicken und weiter gehts.

Mehr ist da eigentlich nicht.

Danke für die Info Michl, ich bin gerade dabei eine Debugging FPC/Lazarus Version zu erstellen.

Bei der Stelle was du auch gefunden hast, bin ich auch gekommen. Zusätzlich habe ich mir die Variablen angesehen und festgestellt, das es die Exception nicht ganz logisch ist, vor allen nicht die Exception die ich eigentlich erwartet habe.

Code: Alles auswählen

function TPropertyEditor.GetObjectValueAt(Index: Integer): TObject;
begin
  with FPropList^[Index] do
    Result:=GetObjectProp(Instance,PropInfo,nil); // nil for fpc 1.0.x
end;

Watch:
<TPERSISTENT> = { <TOBJECT> = { _vptr$TOBJECT = $16f50f0}, FOBSERVERS = $0}
<TPROPINFO> = { PROPTYPEREF = $16f522c, GETPROC = $e22b00, SETPROC = $e22b20, STOREDPROC = $1, INDEX = 0, DEFAULT = -2147483648, NAMEINDEX = 2, PROPPROCS = 53, NAME = 'ObjectHasInterface'}

PropProcs = 53 = 0011 0101 = ptStatic.

Edit:
Ich habe einmal ein Testprojekt erstellt um die FPC funktionen zu testen ( Quelltext teilweise aus den Testroutinen des FPC)

Damit sucht man leichter und man kann auch die FPC Routinen mal testet. Ich habe den FPC entsprechend übersetzt.

Edit 2:
Sollte da von OI nicht auf GetInterfaceProp statt auf GetObjectProp verwiesen werden ? Das sieht so aus, als würde da die richtige Zuordnung zwischen Objekt und Interface fehlen. Damit wäre es ein Lazarusproblem und kein FPC Problem.

Edit 3: Da fehlt wirklich die richtige Zuordnung, im Testprojekt (publishedprojekt) wird es gezeigt wie es IMHO funktionieren sollte.

Mit dem Hack geht es.

Code: Alles auswählen

function TPropertyEditor.GetObjectValueAt(Index: Integer): TObject;
begin
  with FPropList^[Index] do
  begin
    Case PropInfo^.PropType^.Kind of
    tkInterface :
        Result:= TObject(GetInterfaceProp(Instance,PropInfo));
    else
      Result:=GetObjectProp(Instance,PropInfo,nil); // nil for fpc 1.0.x
    end;
  end;
 
end;

Zeile 2840 in der propedits.pp. Was total unschön ist, das ein TInterface auf ein TObject ge-castet wird.

Andreas

Edit-> DEN HACK NICHT VERWENDEN

So, für mich gelöst - der Hack ist wirklich nur ein Hack und Kopfwehpulver. Das Problem war, das er aufgrund des fehlenden Eigenschaft nicht den richtigen Propertyeditor genommen hat und auf den PersistentEditor zurückgefallen ist, der natürlich nicht mit einem Interface anfangen kann.

Mit dem Patch läuft das ganze. Ist sowohl für 1.8.1 als auch für trunk (1.9)

Sehr fein! Habe es eben kurz getestet, der SIGSEGV ist erstmal weg. Komischerweise wird der Objectinspector nicht ordentlich gezeichnet (der Hintergrund nicht gereinigt). Da scheint noch mehr im argen zu sein. Morgen Abend habe ich voraussichtlich etwas mehr Zeit. Danke erstmal!

Das mit dem OI geht bei mir beim Trunk. Lazarus 1.9.0 r56931M FPC 3.1.1 i386-win32-win32/win64. Was ich immer mache ist ein clean des Lazarusverzeichnisses beim Rebuild. Auf meiner Entwicklungmaschine fällt das Kompilieren nicht so als Zeitfaktor auf.

Der OI funktioniert (aktuell) komplett ok, ich muss das Beispiel noch etwas erweitern um auch die Zuweisungen von Interfaces im OI zu testen. Für mich stellt sich die Frage, wie man die einzelnen Editoren als Testlauf mittesten kann. Denn so wie es aussieht ist die Erweiterung für Interfaces gemacht worden, aber keine Tests für die verschiedenen Editoren des OI angelgt worden. Zumindest habe ich nicht dergleichen gefunden (was nicht heißt, das es keine gibt :- )

Andreas

Edit:
Ein Patch mit dem auch die Zuweisung im OI geht. Allerdings gibt es noch Probleme beim Destroy von Lazarus.

Erweitertes TestComponenten, damit man auch die Zuwesisung der Kompüonente mit Interface testen kann.

Andreas

Leider geht der Upload nicht mehr in Forum: Das Kontingent für Dateianhänge ist bereits vollständig ausgenutzt.

Habe Lazarus refresht, den Patch neu eingespielt und getestet. Alles prima! Ist jetzt im Trunk (Revision 56942) und für 1.8.2 angemeldet. Danke für den Patch!

Da fehlt noch mehr. Siehe auch Bugreport. A>ktuell kämpfe ich mit dem 'Read Error' den ich bekomme und den Memoryleaks. Damit ist für mich das Problem von Lazarus noch lange nicht abgeschlossen.

Leider gibt es scheinbar für den ObjectInspektor keine Testroutinen, zumindest habe ich noch nicht gefunden. Das wäre für die Suche sehr hilfreich.

Andreas

Ich habe gerade wenig Zeit. Nur fürs Verständnis. Tritt das Speicherleck mit FPC Trunk oder 3.4.0 auf? Bei dem verlinkten Bugreport gibt es auch Probleme unter FPC 3.0.4, die aber in FPC Trunk behoben sind.

[gelöst] Interface als published property geht nicht

[gelöst] Interface als published property geht nicht

Wer ist online?