nicht visuellen Komponenten auf den Forms

[Kostas]

Hallo Zusammen,

Wir haben Delphi seit Delphi 1 Lizenziert. :-)

Genauso lange habe ich ein Anliegen welches ich jetzt mal vorbringen möchte.

Ich habe die Tage umgestellt auf Delphi11. Wir haben mehrere Projekte laufen und teilweise große Projekte mit über 200 Formularen. Mich stören die nicht visuellen Komponenten auf den Forms. Mit Strg+H kann ich diese ein-/ausblenden. Dennoch fände ich es besser wenn sie separiert wären, ähnlich wie ein Data-Modul. Man könnte rechts unten bei „Code, Design, Historie“ eine zusätzliche Auswahl geben würde z.B. „Data“ Dabei werden NUR die nicht visuellen Komponenten angezeigt auf eine weiße Fläche. Wenn ich auf Design klicke sehe ich dann nur die visuellen Komponenten ohne den nicht visuellen Komponenten. In dem aktuellen Projekt haben wir 288 Formulare. Die FireDac Komponenten die auf der Form liegen werden auch exklusiv für die Form benötigt. Ich kann sie also nicht in ein DataModul auslagern. Könnte ich schon, aber dafür müsste ich für jedes Form eine zusätzlich Datei für das Datamodul anlegen und manuell instanziieren. Dennoch setzen wir DataModul sehr intensiv ein aber eben nicht für jede Form. Eine saubere Trennung wäre hier sehr hilfreich. In Delphi11 wurde in dieser Richtig zumindest etwas verbessert so dass Namen der Komponenten in ein nicht transparentes Rechteck gezeichnet werden. So sind die Namen sicherlich besser zu lesen aber bei Forms mit sehr vielen Komponenten reicht das immer noch nicht aus.

Auch ärgert mich die Tatsache dass bei so voll gepackte Forms, es sehr lange dauert bis sie aufgebaut werden wenn man zwischen Code und Form umschaltet. Bei Delphi 5 wird die Form sofort ohne Zeitverzögerung aufgebaut.

Mich würde jetzt Eure Meinung interessieren.

Gruß Kostas

[TiGü]

Gar nicht erst auf das Formular/Data Module ziehen sondern im Code zur Laufzeit erzeugen ist keine Option?
Der GExperts von dummzeuch/Thomas Müller hat dafür auch einen Wizard: https://gexperts.org/tour/index.html...s_to_code.html

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1505873)

Gar nicht erst auf das Formular/Data Module ziehen sondern im Code zur Laufzeit erzeugen ist keine Option?

Das mag in vielen Fällen wirklich eine Option sein. Allerdings möchte man gerade bei datensensitiven Forms oft auch schon zur Designzeit reale Daten sehen. Insofern würde ich auch eher eine bessere Übersicht durch geeignete IDE-Unterstützung favorisieren. Der Ansatz mit dem zusätzlichen Data Tab sollte sich wohl über ein entsprechendes Plugin realisieren lassen.

BTW, wieso eigentlich kriege ich bei dem GExperts-Link eine Trojaner-Warnung?

[himitsu]

Strg+H (siehe Kontextmenü im Formdesigner) -> nichtvisuelle Komponenten ausblenden



PS: wir haben uns eigene Komponenten gebastelt.
z.B. einen TDataSource-Nachfahren, wo direkt ein DataSet (hier ein TPgQuery) im Constructor intern erstellt wird und dessen wichtigste Property in die DataSource durchgeschleift wurden.

schon hast du nur noch halb so viele DB-Kompoenten, bzw. halb so viel Arbeit


Und einige standardmäßigen Master-Detail-Datasets sind ebenfalls als Subkomponenten innerhalb so einer Query-Komponente aktivierbar, also noch weniger DB-Komponenten direkt auf der Form.

[Kostas]

Wie Uwe schon beschrieben hat ist es zwingend notwendig. Ich verwende in diesem Projekt die DevExpress Komponenten. Um das Grid zu erzeugen muss ich die Query öffnen. Dabei werden alle Feder der Query ausgelesen und damit das Grid aufgebaut.

[Kostas]

Zitat:

Zitat von himitsu (Beitrag 1505875)

PS: wir haben uns eigene Komponenten gebastelt.
z.B. einen TDataSource-Nachfahren, wo direkt ein DataSet (hier ein TPgQuery) im Constructor intern erstellt wird und dessen wichtigste Property in die DataSource durchgeschleift wurden.

voll cool. Ich habe mich damit kaum beschäftigt. :-(

Etwas OT. Ich habe mal in ein DevExpress Beispiel gesehen wir man eine Komponenten ohne Ableitung Funktionalität injizieren kann. Mich würde interessieren ob folgendes machbar wäre: Alle Controls die an das DataSource gebunden sind, wechseln die Hintergrundfarbe je nach state. Die Edit Felder bekommen als Hintergrundfarbe Grün bei Insert, Geld bei Edit, Rot bei delete. Die IBObjects Komponenten können das. Das vermisse ich so sehr bei DevExpress und bei TMS. Für den Anwender ist das so Hilfreich zu sehen welche Aktion wird gerade durchgeführt und welche Felder sind betroffen. Ich habe es schon probiert alle Controls der Form zu durchlaufen und bei den betroffenen Felder die Farbe zu setzen, aber besonders hilfreich ist es nicht wenn kann mehrere duzend Querys mit der Form verbunden sind. So wie es IBO gelöst hat ist es wirklich genital. Angefragt habe ich bei DevExpress und bei TMS. Beide erkennen den Vorteil nicht, oder es ist zu aufwendig das zu implementieren auf Basis von DataSet und DataSource.

Gruß Kostas

[himitsu]

Nja, wir haben eh fast alle Komponenten nochmal bgeleitet, auch Edits (TEdit, bzw. TdxEdit), oder die DevExpressGrids.
Einmal um eigenen Funktionen hinzuzufügen, bzw. um so Komponenten-Bugfixes/Erweiterungen auf allen gefühlt 2 Millionen Forms verteilen zu können.

Delphi-Quellcode:

type
  TMyQuery = class(TDataSource)
  private
    FQuery: TPgQuery;
    function  GetActive:       Boolean;
    procedure SetActive(Value: Boolean);
    function  GetSQL:          TStrings;
    procedure AssignSQL(Value: TStrings);
  public
    constructor Create(AOwner: TComponent); override;
  published
    property Active: Boolean read GetActive write SetActive default False;
    property SQL: TStrings read GetSQL write AssignSQL;
  end;

procedure Register;
begin
  RegisterComponents(IrgendeinName, [TMyQuery]);
end;

constructor TMyQuery.Create(AOwner: TComponent);
begin
  inherited;
  FQuery := TPgQuery.Create(Self);
  FQuery.Name := 'PgQuery';  // bei uns über .SetName auf Self.Name+'_Query' gesetzt ... noch schöner für's Debugging
end;

function TMyQuery.GetActive: Boolean;
begin
  Result := FQuery.Active;
end;

procedure TMyQuery.SetActive(Value: Boolean);
begin
  FQuery.Active := Value;
end;

function TMyQuery.GetSQL: TStrings;
begin
  Result := FQuery.SQL;
end;

procedure TMyQuery.AssignSQL(Value: TStrings);
begin
  // nicht FQuery.SQL := Value;  (wird wollen ja nur den Inhalt ändern)
  FQuery.SQL.Assign(Value);
end;

Und dann eben noch um eine Collection erweitert, wo TMyQuery als Subkomponenten für MasterDetail rein kommen, sowie StandardSQL (Komponente hat nur den SQLNamen und holt sich den SQL.Text aus einer Tabelle), oder die Field.DisplayText und Formatierungen kommen im AfterOpen aus einer FieldAlias-Tabelle uvm.


Einige der Haupttabellen sind direkt als eigene TMyQuery-Nachfahren erstellt, wo SQL und SubQueries vordefiniert sind.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1505875)

einen TDataSource-Nachfahren, wo direkt ein DataSet (hier ein TPgQuery) im Constructor intern erstellt wird und dessen wichtigste Property in die DataSource durchgeschleift wurden.

Das widerspricht irgendwie meinen Vorstellungen von Entkopplung. Meine DataSets liegen in der Regel auf einem DataModule, während die DataSources dann im Form oder Frame liegen. Es kommt auch häufig genug vor, dass mehrere DataSources auf ein DataSet verlinkt sind, um z.B. mehrere Frames zu synchronisieren. Aber wenn das für euch OK ist, warum nicht?

[himitsu]

Das ist mehr "vereinfachung", also Dinge, die öfters zusammen vorkommen, sind automatisiert/zusammengefasst.

Es kommst sehr oft vor, dass DataSource und DataSet zusammen sind (aneinander hängen), also sind sie auch "zusammen".



Du kannst deine DataSouce ja auch mit auf das DataModule legen, dann sind DS und DS zusammen.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1505885)

Du kannst deine DataSouce ja auch mit auf das DataModule legen, dann sind DS und DS zusammen.

Ähm, nein: Tweaking DFM Loading

Zitat:

While the data controls must reside on the form and the data source(s) should better be on the form, too (I will explain later why), the TDataSet descendants are better placed on a separate data module. This allows the separation of the data logic from the UI and (hopefully) encourages reuse.

...

This seems also a good place to explain the TDataSource should stay in the form rule mentioned in the beginning.

The official one is: One can easily change the dataset in the data source of an individual form instance without interferring with others also using a datasource in a datamodule.

The unofficial one is: Sometimes the IDE looses these connections, f.i. when the data module cannot be opened. In that case it is easier to re-connect the dataset of one data source on the form instead the data sources of several data controls.