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

[Jazzman_Marburg]

Hallo Gemeinde.

Mein TImage Nachfahre TGraphPaper macht mir Kummer. Das Ding soll einfach sowas wie kariertes Rechenblatt darstellen, wo ich dann später ein Koordinaten-System uä. reichzeichne. Ich leite also von TImage ab:

Code:

TGraphPaper = CLASS(TImage)

Im Konstruktor steht:

Code:

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

BEGIN

  INHERITED CREATE(MyParent);
  Parent    := MyParent;
  ...

Mit INHERITED CREATE(MyParent) wird die SetBounds Methode von TImage aufgrufen (INHERITED SetBounds(ALeft, ATop, AWidth, AHeight)-- denn mein GraphPaper soll sich mit dem Resizing seines Parents neuzeichnen - bzw. dessen Größe entsp. anpassen.
Das wird hier erledigt:

Code:

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

  INHERITED SetBounds(ALeft, ATop, AWidth, AHeight);

  Zeichnen;
  ...

Jetzt zum eigentlichem Problem:
In der Methode Zeichnen greife ich auf WIDTH und HEIGHT zu, um die Anzahl der Rechenkästchen zu bestimmen, die gezeichnet werden sollen. Dort knallt es aber, da eine Division durch Null erfolgt, weil: WIDTH und HEIGHT zu diesem Zeitpunkt (Create) den Wert Null haben. Klar die Zeile Parent := MyParent; kommt ja auch erst später (ich frage mich gerade: Bekommt es an dieser Stelle, die Größe seines Parents :?:).
Aber wie kann ich denn meinem Objekt nun initial eine Größe zuweisen, bevor das SetBounds gerufen wird?

Ich hoffe ich konnte mich halbwegs verständlich machen.
Vielleicht hat jemand ja eine Idee?

Lieben Dank
Gruß, Jazzman

[Sir Rufo]

Delphi-Quellcode:

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

BEGIN

  INHERITED CREATE(MyParent);
  Parent := MyParent;  // <-- ist das nicht überflüssig? Wird mit inherited Create(MyParent) doch schon gesetzt
  ...

[Jazzman_Marburg]

Zitat:

Zitat von Sir Rufo (Beitrag 1056554)

Delphi-Quellcode:

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

BEGIN

  INHERITED CREATE(MyParent);
  Parent := MyParent;  // <-- ist das nicht überflüssig? Wird mit inherited Create(MyParent) doch schon gesetzt
  ...

Ja, in der Tat -- aber es ändert nichts an der Sache wenn ich es wegnehme!
Beim ersten Aufruf von Zeichnen ist WIDTH = 0 und HEIGHT = 105: Weder 0 noch 105 machen irgendwie einen Sinn (scheint sich in diesem Stadium noch um Zufallswerte zu handeln). Bekommt mein Objekt nach INHERITED CREATE(MyParent) nun die Größe seines Parents oder nicht? Und wenn nicht: Ich kann ja nicht einfach Width = 50 un Height = 50 schreiben (nur damit mal ein beliebiger aber von Null verschiedener Wert dort steht, weil ja damit dirket wieder SetBounds gerufen wird ==> Endlos-Loop).

Sehr verwirrend das.

Gruß
Jazzman

[shmia]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1056551)

Ich leite also von TImage ab

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.

Wenn dein Control nicht auf Tasten und Mausklicks reagieren soll dann von TGraphicControl ableiten.
Falls dein Control auf Tasten und Mausklicks reagieren soll, dann von TCustomControl ableiten.

[Jazzman_Marburg]

Jetzt nochmal konkret nachgefragt (zu TGraphicControl komme ich später):

Wenn ich Stepwise debugge, dann springen wir nach einem Create in den Constructor:

Code:

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

BEGIN

  INHERITED CREATE(MyParent); // Hiernach springen wir sofort in SetBounds!
  ...
END;

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

  INHERITED SetBounds(ALeft, ATop, AWidth, AHeight); // 0, 0, 0, 105

  Zeichnen;
END;

Woher kommen die Werte 0, 0, 0, 105 für ALeft, ATop, AWidth, AHeight? Wer setzt diese Werte? Bzw. kann ich sie nicht auch setzen -- und wenn ja wo und wie?

Gruß

[stahli]

Was verstehe ich denn jetzt nicht? Im Constructor wird doch der Owner gesetzt, nicht der Parent?

Versuch mal, die Parent-Zuweisung auszuklammern und zur Laufzeit zuzuweisen, nachdem der Constructor komplett durchgelaufen ist...
(Ich bin nicht sicher, aber vielleicht ist die Zuweisung zu früh.)

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

Delphi-Quellcode:

procedure Zeichnen;
begin
  if (Width = 0) or (Height = 0) then
    Exit;
  ...
end;

Ich habe mir für ähnliche Zwecke eine TRaster erstellt. Diese liegt über einem "Designer" (TScrollBox). Sie ist transparent und Maustransparent, zeichnet ein Punkteraster und kann Laserlines für ein auf dem Designer selektiertes Objekt zeichnen. Vielleicht nützt Dir das ja als Anregung...

Delphi-Quellcode:

  TRaster = class(TPaintBox)
  private
    FLaserControl: TControl;
    procedure SetLaserControl(const Value: TControl);
  protected
    procedure CMHitTest(var Msg: TWMMouse); message CM_HITTEST;
  public
    constructor Create(AOwner: TComponent); override;
    destructor Destroy; override;
    procedure Paint; override;
    function Designer: TodDesigner; virtual;
    property LaserControl: TControl read FLaserControl write SetLaserControl;
  end;


{ TRaster }

procedure TRaster.CMHitTest(var Msg: TWMMouse);
begin
  inherited;
  Msg.Result := 0;
end;

constructor TRaster.Create(AOwner: TComponent);
begin
  inherited;
end;

function TRaster.Designer: TodDesigner;
begin
  if Owner is TodDesigner then
    Result := (Owner as TodDesigner)
  else
    Result := nil;
end;

destructor TRaster.Destroy;
begin
  inherited;
end;

procedure TRaster.Paint;
var
  odDesigner: TodDesigner;
  X, Y: Integer;
  mi, ma: Integer;
begin
  inherited;
  if Owner is TodDesigner then
  begin
    odDesigner := (Owner as TodDesigner);
    if (odDesigner.ShowRasterX > 1) and (odDesigner.ShowRasterY > 1) then
    with Canvas do
    begin
      if (LaserControl <> nil) and (Designer <> nil) then
      begin
        ma := 1;
        mi := 0;
        Pen.Color := clSkyBlue;
        MoveTo(0, Designer.VertScrollBar.Position + LaserControl.Top - ma);
        LineTo(Width, Designer.VertScrollBar.Position + LaserControl.Top - ma);
        MoveTo(0, Designer.VertScrollBar.Position + LaserControl.Top + LaserControl.Height - mi);
        LineTo(Width, Designer.VertScrollBar.Position + LaserControl.Top + LaserControl.Height - mi);
        MoveTo(Designer.HorzScrollBar.Position + LaserControl.Left - ma, 0);
        LineTo(Designer.HorzScrollBar.Position + LaserControl.Left - ma, Height);
        MoveTo(Designer.HorzScrollBar.Position + LaserControl.Left + LaserControl.Width - mi, 0);
        LineTo(Designer.HorzScrollBar.Position + LaserControl.Left + LaserControl.Width - mi, Height);
        Pen.Color := clBlack;
      end;
      Y := odDesigner.RasterFrame + odDesigner.RasterYDif;
      while Y < Height do
      begin
        X := odDesigner.RasterFrame + odDesigner.RasterXDif;
        while X < Width do
        begin
          Pixels[X, Y] := clGray;
          Inc(X, odDesigner.ShowRasterX);
        end;
        Inc(Y, odDesigner.ShowRasterY);
      end;
    end;
  end;
end;

procedure TRaster.SetLaserControl(const Value: TControl);
begin
  if FLaserControl <> Value then
  begin
    FLaserControl := Value;
    Refresh;
  end;
end;

[shmia]

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:

Delphi-Quellcode:

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.

[Jazzman_Marburg]

Ja, das wird sicher helfen (TRaster) -- aber bleiben noch ein paar Fragen.
Was ich nicht verstehe:

Zitat:

Zitat von shmia (Beitrag 1056559)

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1056551)

Ich leite also von TImage ab

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.

Wenn dein Control nicht auf Tasten und Mausklicks reagieren soll dann von TGraphicControl ableiten.
Falls dein Control auf Tasten und Mausklicks reagieren soll, dann von TCustomControl ableiten.

Zitat:

Zitat von stahli (Beitrag 1056564)

Ich habe mir für ähnliche Zwecke eine TRaster erstellt.

Wieso kann der Kollege für sein TRaster von TPaintBox ableiten -- mir wird aber gesagt, TImage wäre ganz falsch?

Wenn doch TImage schon fast alles enthält was ich benötige -- wieso soll man nicht davon ableiten -- stattdessen TGraphicControl nehmen, dem ich dann mühsam noch alles "beibringen" muß, was TImage schon kann?

Danke & Gruß

[Jazzman_Marburg]

Moooment!
Kann es sein dass ich da etwas elementares durcheinander werfe:
Ich benutze TurboDelphi -- was bekanntlich keine User eigenen Komponenten erlaubt! D.h. ich erzeuge keine visuellen Komponenten, sondern althergebracht Objekte zur Laufzeit.

Als Grundlage für mein GraphPaper habe ich ein Beispiel aus einem Buch - dort wurde von TImage abgeleitet, umd mit REGISTER die (visuelle) Komponente registriert. Ich bin dann einfach hin und dachte, naja eine Komponente kannste nicht gebrauchen, und hab dann einfach die REGISTER Prozedur weggeschmissen und den Rest so gelassen.

Kann es nicht sein, dass das der Kardnial-Fehler war?
Und ich deshalb doch lieber von TGraphicControl ableiten sollte?

(Das würde zumindest den Knoten in meinem Kopf gerade entwirren).

Jazzman

[shmia]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1056566)

Wieso kann der Kollege für sein TRaster von TPaintBox ableiten -- mir wird aber gesagt, TImage wäre ganz falsch?

TPaintbox ist auch die falsche Basisklasse; muss dann wohl eine Jugendsünde von Stahli gewesen sein.

TPaintbox erfüllt folgenden Zweck:
das Zeichnen wird über das Event OnPaint an das Formular deligiert.
Das bedeutet man kann immer die gleiche Komponente TPaintbox verwenden und damit ganz unterschiedliche Dinge zeichnen weil der Zeichencode auf dem Formular liegt.
Wenn man von TPaintbox ableitet, dann ignoriert man damit den Sinn und Zweck der Paintbox.
TPaintbox müsste eigentlich eine "versiegelte Klasse" sein von der man nicht ableiten kann.

[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.

[Bummi]

darf ich noch hinzufügen daß dem von mir bevorzugten TGraphicControl probremlos Mausevents hinzugefügt werden können, Tastaturevents habe ich noch nie gebraucht, ich vermute ist ähnlich trivial.