![]() |
Interface "überladen" vorhandener Methoden?
Hallo Zusammen!
Beispiel:
Delphi-Quellcode:
Funktioniert das?
IFMXView = interface
['{5D84B045-CCB2-4263-8610-F5789B0E4371}'] Procedure Show; end; TMyForm = class(TForm,IFMXView) // jetzt mit i // In Basisklasse enthalten Procedure Show; end; begin .... // Das Interface wird aus einer Liste zurückgegeben. IMyFMXView.Show; .... end; |
AW: Interface "überladen" vorhandener Methoden?
Ausprobieren?
Aber warum sollte es das nicht? (abgesehn von dem vergessenen I) |
AW: Interface "überladen" vorhandener Methoden?
Die Methoden im Interface müssen in der Klasse nur vorhanden sein.
Wer die deklariert hat oder an welcher Stelle eines Vorfahren die deklariert sind spielt keine Geige.
Delphi-Quellcode:
IView = interface
procedure Show; end; TVclView = class( Vcl.Forms.TForm, IView ) end; TFmxView = class( Fmx.Forms.TForm, IView ) end; |
AW: Interface "überladen" vorhandener Methoden?
Oder möchtest du, dass bei Interface-Referenzierung deines Objekts und darüber der Aufruf Show() eine andere Methode aufruft als die, welche bereits geerbt wird? Dann brauchst du eine "Method Resolution Clause".
|
AW: Interface "überladen" vorhandener Methoden?
Zitat:
Mavarik |
AW: Interface "überladen" vorhandener Methoden?
Formulare und andere visuelle Komponenten haben per Definition ohne ARC keine Referenzzählung. Die ist intern bereits deaktiviert.
|
AW: Interface "überladen" vorhandener Methoden?
Zitat:
|
AW: Interface "überladen" vorhandener Methoden?
Wenn du einem TComponent Nachfahren ein zusätzliches Interface verpasst, wird deswegen keine Referenzzählung angeschalten, die ist nämlich für TComponent abgeschalten. Und die werden ob ARC oder nicht, oder VCL oder FMX nach wie vor über die TComponent Owner Strategie verwaltet und nicht anders.
|
AW: Interface "überladen" vorhandener Methoden?
Zitat:
|
AW: Interface "überladen" vorhandener Methoden?
Nur weil man einer Klasse ein Interface verpasst, bekommt die nicht automatisch eine Referenzzählung.
Die Referenzzählung muß nämlich "selber" implementiert werden, oder eben das, was man da haben möchte. Das merkst du schnell wenn du einfach mal versuchst einem TObject das IInterface oder ein anderes Interface zuzuweisen, denn dann meckert der Compiler, du mögest doch bitte die fehlenden Methoden implementieren, welche vom Interface verlangt werden. Also mindestens AddRef und Freunde ... siehe TCopmponent: Zitat:
Nein, TInterfacedObject ist EIN Vorfahre für Interface-Objekte, welches die nötigen Funktionen implementiert, die alle Interfaces verlangen. Diese Funktionen können aber auch wo anders definiert werden und jenachdem, was man darin macht, wurde entweder eine referenzzählung implementiert, oder sonstewas. TComponent zählt "standardmäßig" keine Referenzen und wird quasi nur über Free freigegeben. (bzw. über den Owner, welcher das Free/Destroy aufruft) TXMLDokument reagiert z.B. standardmäßig wie ein Objekt und wird mit Free freigegeben, aber sobald man eine einzige Interface-Referenz erzeugt, wird ab da vorrangig auf die Referenzzählung geachtet. (aber wenn man bei dem Interface nun doch vorzeitg Free aufruft, dann rauchen die übrigen Interface-Referenzen ab, weil sie auf ein nicht mehr vorhandenes Objekt zeigen) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:50 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz