[OOP] Ableiten von TImage: Wann hat mein Objekt eine Größe?

[Jazzman_Marburg]

Ich verstehe nur noch Bahnhof!
Hier mal ein Zitat aus "BORLAND Delphi 7" von Doberenz und Gewinnus (S.528):

Ableiten von Komponenten
...
Soll es etwas Spezielleres sein, zum Beispiel ein neues Editierfeld, dann müssen Sie sich einen Komponententyp suchen (in diesem Fall TEdit), der sich weitesgehend Ihren Anforderungen annähert. Diesen erweitern Sie dann um die gewünschte neue Funktionalität oder Sie überschreiben die bisherigen Methoden.

D.h. die beiden Autoren schlagen doch genau das vor, was ich versuchte: TImage schien mir ganz passabel, nur dass es keine kleinen Rechtecke zeigt, wenn man es erzeugt. Nach Deiner Auffassung hätten sie (die Autoren) für ein neues Editierfeld also auch von TGraphicControl ableiten müssen?

Fragt sich
Jazzman

[stahli]

Ok, dann will ich es mal versuchen:

Du solltest Dir eine Basiskomponente auswählen, die möglichst viel von dem mitbringt, was Du erreichen willst. Sie sollte aber andererseits nicht unnötig viel Ballast mitschleppen (unnötig viele veröffentlichte Eigenschaften oder Methoden).

Du kannst NATÜRLICH von einer TImage ableiten, die bringt aber eben recht viel Ballast mit (Methoden zum Laden und Speichern von Bildern).
Diese Methoden brauchst Du ja nicht. Daher wäre vielleicht ein Vorfahre von TImage (oder etwas ganz anderes) sinnvoller.

Im Grunde hast Du aber die freie Auswahl.
Wenn es ohne Probleme läuft war es nicht ganz falsch :wink:

[SirThornberry]

Willst du denn wirklich das nutzen was TImage bietet? Also das man ein beliebiges Bild zuweist was auch kleiner oder größer sein kann als der Sichtbare Bereich von TImage?
Man muss sich immer vor Augen führen das man Properties hinzufügen kann, aber nicht verstecken. Wenn du also von TImage ableitest kannst du nichts von dem was einmal bekannt gegeben wurde wieder verstecken.
Man kann also weiterhin Bilder zuweisen etc. Und je fortgeschrittener die Komponente ist von der du ableitest destso mehr Eigenschaften musst du berücksichtigen.

Zur Ausgangsfrage. Ein Control hat seine Größe ab dem Zeitpunkt ab dem man sie setzt. Im Create (also BEIM erstellen) ist die Komponente noch in der Erstellung und hat da natürlich auch nur eine Größe wenn diese da bereits gesetzt wurde. Gemalt etc. wird dort noch nicht.

[Jazzman_Marburg]

Puh!
Das klingt jetzt aber auch schon ganz anders, als:

Das ist schon mal falsch!
TImage ist ein Control um ein TPicture (Bitmap, GIF, JPeg,...) darzustellen.
(Controls sind sichtbare Steuerelement)
Es ist nicht als Basisklasse für eigene Controls gedacht.

So, und nun wieder zum eigentlichen Problem: TImage ist für meine Zwecke also ganz hervorragend geeignet -- nur ziert es sich noch ein wenig.
Das Problem ist folgendes:

Code:

TYPE
  TGraphPaper = CLASS(TImage)
...
  CONSTRUCTOR Create(MyParent: TWinControl; Title: STRING); REINTRODUCE;
  PROCEDURE SetBounds(ALeft, ATop, AWidth, AHeight: INTEGER); OVERRIDE;

END;

Beim Erzeugen des GraphPapers wird der Konstruktor aufgerufen:

Code:

CONSTRUCTOR TGraphPaper.Create(MyParent: TWinControl; Title: STRING);

BEGIN

  INHERITED CREATE(MyParent);

Und als nächstes sofort:

Code:

PROCEDURE TGraphPaper.SetBounds(ALeft, ATop, AWidth, AHeight: INTEGER);
BEGIN
  INHERITED SetBounds(ALeft, ATop, AWidth, AHeight);

Und hier hätte ich zugern gewußt, woher die die Werte 0, 0, 0, 105 für ALeft, ATop, AWidth, AHeight kommen. Es wird ja nichts dazwischen Durchlaufen. Wenn ich nun diese Werte mit z.B. den Werten des Parents auf dem mein GraphPaper liegt, versorgen könnte, wäre ich alle Sorgen los.

Viele Dank
Jazzman

[BUG]

Delphi-Quellcode:

TYPE
  TGraphPaper = CLASS(TImage)
...
  CONSTRUCTOR Create(MyParent: TWinControl; Title: STRING); REINTRODUCE;
  PROCEDURE SetBounds(ALeft, ATop, AWidth, AHeight: INTEGER); OVERRIDE;
...
  private
   created: boolean; 
...
END;

Delphi-Quellcode:

CONSTRUCTOR TGraphPaper.Create(MyParent: TWinControl; Title: STRING);

BEGIN
  created := false;
  INHERITED CREATE(MyParent);
...
  created := true;
END;

Delphi-Quellcode:

PROCEDURE TGraphPaper.SetBounds(ALeft, ATop, AWidth, AHeight: INTEGER);
BEGIN
  INHERITED SetBounds(ALeft, ATop, AWidth, AHeight);
  if created then Zeichne;
...

Damit würde das Zeichnen nicht während der Erstellung ausgeführt werden.

Zitat:

Zitat von stahli (Beitrag 1056564)

Alternativ kannst Du doch die Zeichnen-Funktion einfach abbrechen, wenn Width oder Height 0 sind.

Das ist auch eine Idee, allerdings sollte man dann auch negative Werte ausfiltern. Das könnte/sollte man eventuell auch zusätzlich machen.

[stahli]

Zitat:

Zitat von shima

Dein Konstruktor ist auch falsch
Jedes Control ist auch eine Komponente; logisch weil von TComponent sich alle Controls ableiten.
Das Problem bzw. die Einschränkung ist nun, dass alle Klassen, die von TComponent ableiten folgenden Konstruktor verwenden MÜSSEN:
constructor Create(AOwner: TComponent); virtual;
Man darf zwar einen abweichenden Konstruktor erstellen, aber dieser Konstruktor wird von der VCL niemals aufgerufen!
Die VCL kennt deinen Konstruktor nicht und kann ihn daher nicht aufrufen.
Alle Daten (mit Ausnahme des Owners) müssen über Properties oder Methodenaufrufe in das Objekt gebracht werden.

Also ich störe mich immernoch an Deinem Konstruktor (wie auch shima schrieb). Was der Compiler genau aus Deinem verdrehten Konstruktor macht, kann ich nicht recht einordnen.
Du solltest das etwas einfacher und strukturierter angehen.
- Komponente mit einem normalen Konstruktor erzeugen.
- Parent zuweisen
- in der Paint-Methode Deine Gitter zeichnen

Ich denke, dann wird das alles etwas übersichtlicher.

Grundsätzlich könntest Du auch von einem Panel ableiten und die Paint-Methode ersetzen (wenigstens damit einmal ein paar Versuche anstellen).

[Jazzman_Marburg]

Lieben Dank an Alle!

Das reicht erstmal zum Nachdenken.

Die Sache mit dem Konstruktor werde ich tatsächlich nochmal überdenken (und wohl auch etwas Nachlesen).

Tolle Truppe hier!

Nacht zusammen!

Jazzman

[Aphton]

Wenn du bereit wärst, die ganze Komponente hier gepackt in einer Unit anzuhängen und die man dann recht einfach - dh. ohne irgendwelche großartigen Anpassungen - debuggen könnte, würde ich gerne helfen. Ansonsten ratet man nur ins Ungewisse und bekommt jede Menge Codeverbesserungen und Tipps, die eig. nicht das Urpsrungsproblem lösen (jedoch aber sehr wichtig sind..)

[Bummi]

Ein nicht ganz zu vernachlässigender Nachteil bei der Ableitung von Timage ist auch der ganze Datenmüll (bitmap) der im DFM mitgespeichert wird und Programme unnötig aufbläht.

[shmia]

Hier mal eine Zusammenfassung der Klassen, die für die Darstellung von "Grafischen Dingen" in Frage kommen:

1.) TGraphicControl
Geeignet, wenn man nur ein graphische Object anzeigen möchte und keine Steuerung über Tastatus oder Maus benötigt.
Man muss von TGraphicControl ableiten und die Methode Paint überschreiben.
Innerhalb von Paint zeichnet man auf das Canvas-Objekt.
Es ist ein Fehler, wenn man ausserhalb der Methode Paint etwas auf den Canvas zeichnet.
2.) TCustomControl
wie TGraphicControl, nur das man zusätzlich ein Window-Handle hat und somit auf Messages von Tastatur und Maus reagieren kann.
3.) TPaintBox
Ableiten von dieser Klasse ist nicht sinnvoll.
Stattdessen benützt man das Event OnPaint um das Zeichnen auf das Formular zu deligieren.
Der Code für das Zeichnen liegt im Formular.
4.) TImage
Ableiten von dieser Klasse ist nicht sinnvoll.
Stattdessen kann man beliebige Bilder aus Dateien, Streams oder TImageList laden.
Man kann das anzuzeigende Bild aus im Formular laden, d.h. schon zur Entwicklungszeit
wird ein Bild (Bitmap, jpeg, Gif,...) zugewiesen
Ausserdem eignet sich TImage auch als gepufferte Anzeige.
Man kann also von Aussen etwas auf das Image zeichnen und es bleibt solange bestehen,
bis man etwas Neues drüber zeichnet oder eine neues Bild lädt.
5.) TPanel
Ein Panel ist eine Ableitung von TCustomControl.
Wenn man den Rahmen, den das Panel mitbringt gebrauchen kann,
dann darf man von TPanel ableiten.
Ansonsten sollte man TCustomControl als Basisklasse verwenden.

Es gibt also 3 Komponenten, von den man ableiten darf:
TGraphicControl, TCustomControl und TPanel
und zwei Komponenten von denen man nicht ableiten darf:
TPaintBox und TImage
Dass manche Programmierer dagegen verstossen bedeutet nicht das es richtig ist.

Und jetzt noch etwas für Turbo-Delphi Programmierer:
da man keine eigene Komponenten installieren kann, ist es besser wenn man nicht eigene Komponenten ableitet sondern TPaintBox oder TImage benützt.
Ich mach' hier mal Schluss; weitere Infos wie man TPaintBox oder TImage richtig benützt ggf. später.