Eigene Klasse von TTabsheet

[Pro_RJ]

Halli Hallo,

Ich Arbeite mit BDS2006.

Ich Arbeite in meinem Projekt viel mit Pagecontrols und Tabsheets.
Jetzt soll es dem Anwender ermöglicht werden einzelne Tabsheets ein bzw. auszublenden. Dieses soll über die Eigenschaft "Tabvisible" geschehen.

Zusätzlich ist es aber auch so das zur Laufzeit einzelne Tabsheets per Tabvisible ein und ausgeschaltet werden. z.b. wenn die Register nicht angezeigt werden und nur per ButtonClick auf die nächste Seite gewechselt wird.

Meine Idee war jetzt die, das im setter von Tabvisible geprüft wird, darf das Register Tabvisible True bekommen oder nicht.


Dafür wollte ich mir einfach eine Eigene Klasse erstellen und den Setter überschreiben.

Delphi-Quellcode:

// das Eigene Tabsheet
TMyTabsheet = Class(TTabsheet)
  Property Benutzerdarfeinstellen : Boolean;
  Property Tabvisible : Boolean read getMyTabvisible write setMyTabvisible;

  ....
end;

// Dazu noch das eigene Pagecontrol

TMyPagecontrol = Class(TPagecontrol)
  ....
end;

Das ist ja soweit alles kein Problem.
Das Problem ist folgendes:
Wenn ich zur Entwurfszeit ein Pagecontrol aus der Tool-Palette auf ein Form ziehe dann auf dieses Pagecontrol Rechte maus machen und sage "Neue seite" dann wird ja von der Delphi-IDE automatisch ein Neues Tabsheet erzeugt. nur dieses Tabsheet ist von der Delphi-Klasse TTabsheet und nicht von TMyTabsheet.

Gibt es eine möglichkeit delphi dazu zu bringen mir dann ein Objekt von TMyTabsheet zu erzeugen?
Oder muss ich dann diese ganze Steuerung zum erstellen von neuen Tabsheets usw. selber bauen?

mfg

Jens

[sx2008]

Ich würde die Klassen TTabsheet & TPageControl ganz in Ruhe lassen und die Logik in eine eigene Klasse verlagern.
Damit erspart man sich einige Probleme.
Anstatt also im Code bestimmte TabSheets über Property TabVisible zu ändern "sagst" du das der neuen Stellvertreter-Klasse.

Delphi-Quellcode:

type
TPageUserController = class(TObject)
public
  property Pagecontrol: TPageControl

  procedure SetTabVisible(tab:TTabSheet; Visible:Boolean);
  procedure SetUserVisible(tab:TTabSheet; Visible:Boolean);
end;

Pro Tabsheet benötigt diese Klasse 2 Booleans, die die Infos zwischenspeichern.

[Der schöne Günther]

Hast du mal versucht, TMyTabsheet stattdessen auch TTabsheet zu nennen und damit in deinem Formular das TTabsheet zu überschreiben?

Also in deiner Unit ein

TTabsheet = class(Vcl.ComCtrls.TTabSheet) ?

[Pro_RJ]

noch nicht, da es ja eigentlich einen Namenskonflikt erzeugen würde.
Nur woher soll dann delphi Wissen welches "Tabsheet" erzeugt werden soll?

[Der schöne Günther]

Deins natürlich, denn das verdeckt das "normale" TTabsheet. Nennt sich, glaube ich, Interposer-Klasse. Probier es doch mal aus, ich habe so etwas eben grade noch mit einem TDBGrid gemacht um ihm seine Scrollbalken zu nehmen: Einfach eine TDBGrid-Interposer-Klasse, der Instanz einmal die Scrollbalken genommen und der Interposer-Klasse die UpdateScrollbars -Methode kaputt gemacht. Funktioniert bestens.

[bcvs]

Man könnte die TTabsheets erst von Delphi erstellen lassen und dann manuell im Quellcode und in der DFM nach TMyTabsheet ändern.

Nur so eine Idee, nicht ausprobiert.

[Furtbichler]

Zitat von Der schöne Günther:

Funktioniert bestens.

Glaube ich Dir, nur sobald man in der Uses-Klausel rumfummelt (oder irgend ein blöder Formatierer), kann es passieren, das plötzlich nicht mehr deine Klasse, sondern die Originalklasse verwendet wird. D.h.: Die korrekte Funktion ist von der Reihenfolge der Units der Uses-Klauses abhängig.

Ich halte es für gefährlich, solche Tricks zu verwenden. Außerdem ist es schwer verständlich.

[Der schöne Günther]

Das mache ich ja auch nicht aus Spaß, sondern nur, wenn es nicht anders geht. In meinem Leben bislang zwei mal: Einmal für irgendeinen (unsinnigerweise protected) onXYZ-Event einer TTrackbar und dieses mal eben für die Scrollbalken eines TDBGrid. Also nur für reine Äußerlichkeiten einer VCL-Komponente.

Ein echter Mann würde eine richtige Unterklasse erstellen, aber da eben das mit VCL-Komponenten auf einem Formular doch nicht einfach in kurzer Zeit einfach zu machen ist (oder irre ich mich?), habe ich lieber zu dieser Methode gegriffen.

Da diese "Interposer-Klasse" nicht in einer anderen Unit, sondern in der gleichen wie das Formular: So kann mir doch keine andere Unit diese Klasse verdecken? Meine ist immer ganz oben, richtig?


Aber ja, es ist ein ziemlicher Hack und sollte man nicht zur Gewohnheit werden lassen. Habe ich bislang auch nur in Delphi mit seiner komischen Interpretation von Sichtbarkeitsmodifikatoren gesehen

[Pro_RJ]

Halli Hallo,
danke erstmal für die Anworten.
Aufgrund der Komplexität des Programmes (über 300 Fenster) und auch der Sicherheit habe ich es jetzt wie folgt gelöst:

Jedes Fenster stammt bei uns von einer gemeinsamen Vorfahrenklasse ab (TMYCustomform) diese Steuert die gesamte Benutzerverwealtung. Diese hab ich jetzt so erweitert, das die Tabsheets auch mit in der Benutzerliste gespeichert werden(hier standen bis her nur die Labels,Edits,Butten usw)

Diese Klasse hab ich jetzt um die Eigenschaft "Tabvisible[Page : TTabsheet]" erweitert. Jeder Aufruf von Tabsheet1.tabvisible := true wird auf Self.Tabvisible[Tabsheet1] := True geändert. Damit habe ich einen gemeinsamen Punkt wo ich prüfen kann, ob der Anwender das register sehen darf oder nicht.

Ausserdem habe ich die TPagecontrol Klasse abgeleitet und ein "BeforeChange" implementiert in der ich abfragen kann welches register jetzt angezeigt werden soll. Dieses Ereigniss prüft in der Benutzerliste ob der Anwender in das register darf oder eben nicht. Darf er nicht lasse ich einen wechsel des Registers einfach nicht zu.

Das ist für uns die Sicherere Variante mit relativ geringem Aufwand. und bei der weiteren Entwicklung muss nichts weiter beachtet werden.

mfg
Jens

[Der schöne Günther]

Ah und ich dachte, man kann nicht einfach eine Unterklasse einer VCL-Komponente auf dem Formular erstellen da Delphi doch immer die Oberklasse nimmt? War ich wohl zu dumm dafür, als ich das mal versucht hatte...