nicht visuellen Komponenten auf den Forms

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

Zitat von himitsu:

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 von himitsu:

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 von himitsu:

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.

[TurboMagic]

Du könntest mal in QP (https://quality.embarcadero.com schauen,
ob dein Wunsch schon als Feature Request erfasst ist. Falls ja, könntest du dafür stimmen und die Nummer
hier posten. Evtl. stimmen dann noch mehr Leute hier dafür.

Falls es noch nicht erfasst ist, einfach einen neuen Feature Request eingeben und auch dann die Nummer
hier posten...

Evtl. wird's dann ja mal umgesetzt...