Variablenname mehrere Typen

[Antonov]

So, ich weiß nicht einmal wirklich, wie ich dieses Problem benennen soll (deswegen war meine Suche erfolglos)

Ich möchte folgendes:
ich möchte einem Variablennamen je nach Bedarf zwei verschiedene Veriablentypen zuweisen.
In meinem Fall würde ich je nach Bedarf dem Namen "MyPopupsource" - der Parent eines TPopupcomponents - entweder TLabel oder TPanel zuweisen.
Ich könnte natürlich zwei ähnliche Prozeduren schreiben, aber ich möchte das elegant lösen.

Leider finde ich im Internet und diesem Forum nichts vergleichbares, darum muss ich mich direkt and euch wenden. Jemand eine Idee?

[himitsu]

Wenn man das kleinsten gemeinsamen Teiler benutzt, dann geht alles.

Also einen Typen, von welchem beide Klassen erben. (ganz oben ist immer TObject und dazwischen liegt oft auch TComponent)
Meistens nimmt man den kleinsten Typen, welcher die nötigen Funktionen implementiert.

[Perlsau]

Zitat:

Zitat von Antonov (Beitrag 1304429)

Ich könnte natürlich zwei ähnliche Prozeduren schreiben, aber ich möchte das elegant lösen.

Was findest du an overload unelegant? Mit der Direktive overload ist es möglich, zwei oder mehr Varianten einer Methode oder einer Routine zu schreiben:

Delphi-Quellcode:

function Divide(x, y: real): real; overload;
begin
  result := x / y;
end;
 
function Divide(x, y: integer): integer; overload;
begin
  result := x div y;
end;

Beispiel entnommen aus dem entsprechenden Tutorial beim Delphi-Treff.

[BUG]

Zitat:

Zitat von himitsu (Beitrag 1304431)

Also einen Typen, von welchem beide Klassen erben. (ganz oben ist immer TObject und dazwischen liegt oft auch TComponent)

Je nachdem was du machen willst, kannst du eventuell auch in der Prozedur gleich mit einem gemeinsamen Vorfahren arbeiten.
Der am meisten spezialisierte gemeinsame Vorfahre von TLabel und TPanel ist TControl. Der hat schon ein paar öffentliche Eigenschaften.

Zitat:

Zitat von Perlsau (Beitrag 1304436)

Was findest du an overload unelegant?

Wenn man einen passenden gemeinsame Vorfahren hat (oder Templates; SCNR) hat, dann können sehr ähnliche (nicht-triviale) überladene Funktionen unelegant sein.

[Popov]

Quatsch gelöscht!

[Dejan Vu]

Die Fragestellung deutet auf ein verbesserungswürdiges Design hin. Beschreibe doch mal, weshalb Du deine Variable -je nach Anwendungsfall- unterschiedlich deklarieren willst.

[himitsu]

Genau das löst sich ja mit dem gemeinsamen Vorfahren auf ... nur noch ein Code für diesen einen Vorfahren.

[Jasocul]

TControl ist der erste gemeinsame Vorfahr.

Jetzt stellt sich die Frage, auf welche Methoden und Eigenschaften will der TE zugreifen? Schon "Caption" gibt es noch nicht in TControl. Und ein Zugriff auf TLabel ohne die Nutzung der Caption stelle ich mir relativ sinnlos vor.
Natürlich kann man ein Typecast machen. Aber dann muss man im Source ja doch wieder unterscheiden, was man gerade benutzen möchte. Der Vorteil ist futsch.

Man muss sich also auch die Frage stellen, wie sinnvoll die Nutzung des gemeinsamen Vorfahren ist. Es kann durchaus sein, dass es dadurch komplizierter wird, als 2 Variablen mit unterschiedlichem Typ zu haben. Man verliert in einem gewissen Rahmen auch die Typsicherheit.

Vielleicht lohnt es sich ja auch, eine eigene Komponente dafür zu programmieren. Diese kann ja von TLabel oder TPanel abgeleitet sein. Kommt halt drauf an, was besser zur Lösung der Aufgabe passt.

[Dejan Vu]

Zitat:

Zitat von himitsu (Beitrag 1304454)

Genau das löst sich ja mit dem gemeinsamen Vorfahren auf ... nur noch ein Code für diesen einen Vorfahren.

Es kaschiert eher das Problem.

[himitsu]

Wieso?

Wenn das Feature bereits in dem Vorfahren drin ist, dann ist das praktisch DIE Lösung.

[Antonov]

TComponent als gemeinsamer Vorfahre funktioniert, prima. Danke!
Dabei find ich es merkwürdig, dass TControl oder TWinControl beide nicht funktionieren. So aus Neugier, weiß einer warum?

Das mit dem Overload probiere ich gleich mal aus, klingt interessant.

Zitat:

Zitat von Perlsau (Beitrag 1304436)

Was findest du an overload unelegant? Mit der Direktive overload ist es möglich, zwei oder mehr Varianten einer Methode oder einer Routine zu schreiben:

Das setzt voraus, dass ich weiß was Overload ist. Ich bin Amateur, also entspannt euch :P
Ich Probier die Overload Direktive mal aus (nachdem ich herausfinde, wie sie funktioniert), vielleicht ist sie nützlich.

[Popov]

Zitat:

Zitat von Antonov (Beitrag 1304476)

Ich Probier die Overload Direktive mal aus (nachdem ich herausfinde, wie sie funktioniert), vielleicht ist sie nützlich.

Das ist einfach: die Prozedur oder Funktion muss gleichen Namen haben, muss sich aber bei den Parametern unterscheiden. Dann muss die Prozedur oder Funktion noch mit der Direktive Overlaod deklariert werden. Meiner Kenntnis nach, ich hab es aber nicht getestet, müssen sich die Parameter unterscheiden. Unterschiedliche Ergebnisse bei Funktionen reichen meiner Kenntnis nach nicht aus.

[Perlsau]

Zitat:

Zitat von Antonov (Beitrag 1304476)

Das mit dem Overload probiere ich gleich mal aus, klingt interessant.

Zitat:

Zitat von Perlsau (Beitrag 1304436)

Was findest du an overload unelegant? Mit der Direktive overload ist es möglich, zwei oder mehr Varianten einer Methode oder einer Routine zu schreiben:

Das setzt voraus, dass ich weiß was Overload ist. Ich bin Amateur, also entspannt euch :P
Ich Probier die Overload Direktive mal aus (nachdem ich herausfinde, wie sie funktioniert), vielleicht ist sie nützlich.

Overload ist der Fachausdrück für Überladen. Du kannst eine Routine oder eine Methode (also eine Procedure oder eine Function) überladen. Das bedeutet, daß Delphi je nach Zusammensetzung der Parameter die jeweils richtige Routine auswählt. In obigem Beispiel wird einmal ein Integer übergeben und ein Integer im Result zurück erwartet. Rufst du also die Funtion mit Integer-Variablen auf, wählt Delphi die Integer-Variante. Analog verhält sich das mit der Real-Variante. Probier's doch einfach mal aus – dein PC wird davon schon nicht kaputtgehen, vertrau mir :cyclops:

Wenn es sich dagegen darum handelt, aus einer Basis-Klasse weitere spezialisierte Klassen abzuleiten (was ich angesichts deines Outings als Amateur eher nicht annehme), muß man das anders lösen, wie oben bereits von anderen Usern aufgezeigt.

Nachtrag:

Wenn du deine Methoden im Interface-Teil deklarierst, genügt es, dort die Direktive overload anzugeben. In diesem Falle kannst du sie im Implementation-Abschnitt weglassen:

Delphi-Quellcode:

Interface
...
  Procedure SetMargin(Const RE: TjvDBRichEdit; Const L,R,T,B : Integer); overload;
  Procedure SetMargin(Const RE: TjvRichEdit; Const L,R,T,B : Integer);  overload;
...

Implementation

// ----- Ränder bei DB-RichEdits setzen (DBRichEdit)--------
Procedure SetMargin(Const RE: TjvDBRichEdit; Const L,R,T,B : Integer);
Var
  Rect  : TRect;
begin
  Rect := RE.ClientRect;
  Rect.Left   := Rect.Left   + L;
  Rect.Right  := Rect.Right  - R;
  Rect.Top    := Rect.Top    + T;
  Rect.Bottom := Rect.Bottom - B;
  SendMessage(RE.Handle,EM_SETRECT,0,LongInt(@Rect));
end;

// ----- Ränder bei RichEdits setzen (RichEdit)-------------
Procedure SetMargin(Const RE: TjvRichEdit; const L, R, T, B: Integer);
Var
  Rect  : TRect;
begin
  Rect := RE.ClientRect;
  Rect.Left   := Rect.Left   + L;
  Rect.Right  := Rect.Right  - R;
  Rect.Top    := Rect.Top    + T;
  Rect.Bottom := Rect.Bottom - B;
  SendMessage(RE.Handle,EM_SETRECT,0,LongInt(@Rect));
end;

Mit diesen beiden Proceduren kann ich entweder ein TjvRichEdit oder ein TjvDBRichEdit als Parameter angeben. Delphi wählt anhand der übereinstimmenden Parameter die richtige Procedure aus. Stimmen die übergebenen Parameter mit keiner der Overload-Versionen überein, gibt's eine Fehlermeldung beim Compilieren.

[himitsu]

Zitat:

Zitat von Antonov (Beitrag 1304476)

Dabei find ich es merkwürdig, dass TControl oder TWinControl beide nicht funktionieren. So aus Neugier, weiß einer warum?

Nee, da du es wohl für ein Staatsgeheimnis hältst und uns nicht verraten willst, was nicht funktioniert. :roll:

[BadenPower]

Zitat:

Zitat von Antonov (Beitrag 1304476)

Dabei find ich es merkwürdig, dass TControl oder TWinControl beide nicht funktionieren. So aus Neugier, weiß einer warum?

In Delphi müßte TControl gehen.

TWinControl kann nicht funktionieren, da es kein gemeinsamer Vorfahre von TLabel und TPanel ist.


Ob die Ableitung in Turbo Delphi anderst ist, dass kann ich leider nicht sagen.

[BUG]

Zitat:

Zitat von Perlsau (Beitrag 1304482)

Mit diesen beiden Proceduren kann ich entweder ein TjvRichEdit oder ein TjvDBRichEdit als Parameter angeben.

Obwohl ich mich fragen würde, ob die beiden Klassen nicht schon einen gemeinsamen Vorfahren mit der Handle-Proberty haben ... zum Beispiel TWinControl. Dann könntest du den doppelten Code komplett loswerden. Ansonsten könnte das Berechnen das Rects extrahieren.

Ich finde überladene Funktionen besonders für 2 verschiedene Sachen nützlich:

1. nicht verwandte Typen mit ähnlicher/gleicher Semantik (z.B. unterschiedliche Zahlentypen)
2. spätere Spezialisierung von Funktionen (z.B. im Visitor)

[himitsu]

TJvCustomRichEdit :stupid:

Ein Vorfahre für beide Typen, der bestimmt alles Nötige enthält.

Im Notfall kann man intern, für noch nicht sichtbare Property, welche in TJvRichEdit nur auf Published gesetzt werden, auch Beides hart nach TJvRichEdit casten, auch wenn es mal ein TJvDBRichEdit ist. (hier muß man halt nur bissl genauher drauf achten)