StringGrid: Auf Ändern der Spalten-/Zeilenanzahl reagieren

[Fussball-Robby]

Hey,
ich habe eine eigene Komponente, die vom TStringGrid abgeleitet ist. Für den weiteren Gebrauch ist es wichtig, dass das Grid gleichviele Spalten und Zeilen hat. Bisher habe ich bei der entsprechenden Methode auf Gleichheit geprüft, und, wenn es nicht gleichviele waren, eine Exception geworfen. Ich fände es allerdings eleganter, beim Ändern von RowCount bzw. ColCount das entsprechend andere gleich mitzuändern. Dazu müsste ich mitbekommen, wenn eine dieser Eigenschaften geändert wird. Gibt es da irgendeine Message, auf die ich reagieren könnte o.Ä.?

[toms]

Hallo

Warum schreibst du nicht deine eigene Prozedur wo beides geändert wird?

[Fussball-Robby]

Zitat:

Zitat von toms

Warum schreibst du nicht deine eigene Prozedur wo beides geändert wird?

Wann soll ich diese denn dann aufrufen? Man soll ganz normal im OI z.B. RowCount ändern können, woraufhin sich dann ColCount auch ändert.

[toms]

Zitat:

Zitat von Fussball-Robby

Zitat:

Zitat von toms

Warum schreibst du nicht deine eigene Prozedur wo beides geändert wird?

Wann soll ich diese denn dann aufrufen? Man soll ganz normal im OI z.B. RowCount ändern können, woraufhin sich dann ColCount auch ändert.

Ach so, du meinst im OI. Dann kommst du wohl nicht darum herum eine eigene Komponente von TStringGrid abzuleiten.

[Hansa]

Zitat:

Zitat von toms

Dann kommst du wohl nicht darum herum eine eigene Komponente von TStringGrid abzuleiten.

Und weil er genau das gemacht hat, hat er die Frage gestellt. Siehe #1 :roll: Ich hofe Du hast die VCL-Quellen. Irgendwo muss im Constructor das hier gemacht werden :

Delphi-Quellcode:

inherited;
FColCount := FRowCount;

SetColCount gibts auch. Oh je, muss das gerade ein TStringgrid sein ? Wo ist die beste Stelle das unterzubringen ? Ist CreateParams geeignet ? :gruebel: Die Grids.pas hat fast 6000 Zeilen. Da scrollt man sich ja die Flossen wund. :shock:

[sx2008]

Zitat:

Zitat von Fussball-Robby

ich habe eine eigene Komponente, die vom TStringGrid abgeleitet ist.

Du solltest von TCustomStringGrid ableiten.
Damit kannst du verhindern, dass RowCount und ColCount im OI überhaupt sichtbar werden.
Stattdessen gibst du ein eigenes Property (RowColCount oder GridSize) heraus.

[DeddyH]

Zitat:

Zitat von Hansa

Ich hofe Du hast die VCL-Quellen.

Bei D7 Enterprise sind die dabei ;)

[Hansa]

Ob das immer stimmt ? :mrgreen: Habs aber doch noch gesehen wo das gemacht werden kann :

Delphi-Quellcode:

  TStringGrid = class(TDrawGrid)
  private
...
  public
    constructor Create(AOwner: TComponent); override;

Also gilt das vorher gesagte und das ist ja dann kein Problem.

[Hansa]

Zitat:

Zitat von sx2008

..Du solltest von TCustomStringGrid ableiten.
Damit kannst du verhindern, dass RowCount und ColCount im OI überhaupt sichtbar werden.
Stattdessen gibst du ein eigenes Property (RowColCount oder GridSize) heraus.

Dann kann er aber gleich das komplette Rad neu erfinden. Guck dir mal an, wieviele Properties dann selbst bearbeitet werden müssten. :shock: Der wird ja nicht mehr froh. :mrgreen:

[sx2008]

Zitat:

Zitat von Hansa

Zitat:

Zitat von sx2008

..Du solltest von TCustomStringGrid ableiten.
Damit kannst du verhindern, dass RowCount und ColCount im OI überhaupt sichtbar werden.
Stattdessen gibst du ein eigenes Property (RowColCount oder GridSize) heraus.

Dann kann er aber gleich das komplette Rad neu erfinden. Guck dir mal an, wieviele Properties dann selbst bearbeitet werden müssten.

Hast leider recht - es gibt kein TCustomStringGrid, sondern nur ein TCustomDrawGrid.
Würde es aber ein TCustomStringGrid geben, dann wäre das die richtige Lösung, denn er bräuchte dann die Properties nur veröffentlichen.
Und das Veröffentlichen von Properties ist ganz einfach:

Delphi-Quellcode:

  TDrawGrid = class(TCustomDrawGrid)
  published
    property Align;  // erhöhe die Sichtbarkeit von protected auf published
    property Anchors;// dito

[Hansa]

Grundsatz der OOP : immer möglichst viel vom Vorgänger erben. Die Custom-Dinger sind dafür gedacht einem Komponentenentwickler zumindest mal die Namen der Methoden zu ersparen. Er hat ein fast leeres Grundgerüst und muss dann alles selber machen. Beim Stringgrid siehts z.B. so aus :

Zitat:

{ TCustomGrid is an abstract base class that can be used to implement
general purpose grid style controls. The control will call DrawCell for
each of the cells allowing the derived class to fill in the contents of
the cell. The base class handles scrolling, selection, cursor keys, and
scrollbars.

Außer ein bisschen Tastatureingaben, Scrollbars usw. ist also nichts fertig.

Das hier ist aber noch viel schlimmer. FColCount ist private deklariert. Es besteht also keine Chance, von dem abgeleiteten Stringgrid aus da dranzukommen. Zumindest nicht ohne Eingriffe im VCL-Quelltext. Vielleicht sieht irgendeiner in den 6000 Zeilen noch irgendeine Möglichkeit. Ich jedenfalls nicht.

Das geht wohl nur über Umwege.

[Fussball-Robby]

Zitat:

Zitat von Hansa

Delphi-Quellcode:

inherited;
FColCount := FRowCount;

Zitat:

Zitat von Hansa

Habs aber doch noch gesehen wo das gemacht werden kann :

Delphi-Quellcode:

  TStringGrid = class(TDrawGrid)
  private
...
  public
    constructor Create(AOwner: TComponent); override;

Also gilt das vorher gesagte und das ist ja dann kein Problem.

Alco im Create FColCount := FRowCount? Das Create wird aber schon aufgerufen, wenn die Komponente auf die Form kommt, danach kann man das noch ändern, wie man will. Ich muss irgendwie mitbekommen, wenn RowCount/ColCount geändert wird, und in der Grids.pas werd ich einfach nicht fündig :wall:
Hat vielleicht jemand noch Ideen?

[Hansa]

Ich sehe nur noch Einführung einer HilfsRow / HilfsCol und da die Werte direkt an ColCount/RowCount übergeben. Oder den Einsatz der Objektablage. D.h. Vererbung auf Form-Ebene. In der Urform müsste dann nur im FormCreate RowCount := ColCount gemacht werden. Und dann eben von dieser Form ableiten, anstatt mit neu -> Form über neu -> weitere -> MeineForm. Das hätte noch den positiven Nebeneffekt, dass man so auch alle Grundeinstellungen/Ereignisse schon in der Urform abhandeln könnte. Die letzte Möglichkeit : auf Lannes warten. Der ist hier für Stringgrids zuständig. :shock: Hexen kann der AFAIK allerdings auch nicht. :mrgreen:

[Fussball-Robby]

Zitat:

Zitat von Hansa

Ich sehe nur noch Einführung einer HilfsRow / HilfsCol und da die Werte direkt an ColCount/RowCount übergeben.

Sowas wollte ich eigentlich vermeiden, aber das ist im Moment wohl das einfachste. Wenn ich aber eine Hilfsproperty mache, kann man die anderen trotzdem noch ändern. Gibt es eine Möglichkeit, die Sichtbarkeit der Propertys runterzusetzen, sodass sie nicht mehr im OI sind?

[marabu]

Hallo Robert,

Sichtbarkeiten kannst du nicht verringern, nur erweitern.

Über eine Redimensionierung deines Grids informiert dich die dafür vorgesehene Methode SizeChanged():

Delphi-Quellcode:

unit MoreGrids;

interface

uses
  SysUtils, Classes, Controls, Grids;

type
  TStringGridEx = class(TStringGrid)
  protected
    procedure SizeChanged(OldColCount, OldRowCount: Longint); override;
  end;

procedure Register;

implementation

procedure TStringGridEx.SizeChanged(OldColCount, OldRowCount: Longint);
begin
  inherited SizeChanged(OldColCount, OldRowCount);
  // ...
end;

procedure Register;
begin
  RegisterComponents('marabu', [TStringGridEx]);
end;

end.

Wenn du selbst die Dimensionen des Grids änderst, hast du doch die volle Kontrolle - auch zur Laufzeit. Worüber also zerbrichst du dir denn da den Kopf?

Grüße vom marabu

[Fussball-Robby]

Perfekt, SizeChanged ist genau das richtige! Danke :cheers:

Delphi-Quellcode:

  inherited SizeChanged(OldColCount, OldRowCount);
  if OldColCount <> ColCount then
    RowCount := ColCount
  else
  if OldRowCount <> RowCount then
    ColCount := RowCount;

Zitat:

Wenn du selbst die Dimensionen des Grids änderst, hast du doch die volle Kontrolle - auch zur Laufzeit. Worüber also zerbrichst du dir denn da den Kopf?

Wenn ich aber aus Versehen z.B. 20 Reihen und nur 19 Spalte habe und es nicht rechtzeitig bemerke, kommt bei der Berechnung, die dann läuft, nachher nutzloses Zeugs raus. Und anstelle vor der Berechnung einen Fehler auszugeben, fand ich es komfortabler, die Sache an der Wurzel zu packen :wink: