Anzeigeproblem bei eigener DB-Text-Komponente auf DBCtrlGrid

[mschaefer]

Moin, moin,

Habe eine eigene DBText-Komponente die auf einem Formular auch bestens Funktioniert.
Auf einem DBGrid wird sie aber nicht auf allen Panels angezeigt. Woran liegt das :?:
Mich interessiert das auch für komplexere Komponenten. Mir fehlt wohl irgendein
Ereignis zum Neuzeichnen. Ok soweit so lausig...

Im Anhang liegt ein Beispielprojekt (D6), wo die Kompo dynamisch erzeugt wird, damit man
zum Testen nichts installieren muß.

Viele Grüße // Martin

[marabu]

Hallo Martin,

ich kann keine Anomalie feststellen. Ich habe die Unit UDBText in der Uses-Klausel nach ganz hinten verschoben, damit auch mit deiner Komponente getestet wird. Hast du Hinweise, wie ich dein Anzeigeproblem nachvollziehen könnte?

Freundliche Grüße

[mschaefer]

Schönen Morgen,

Die Probleme fangen an, wenn man die Datensätze wechselt.

Meine Komponente liegt rechts neben dem "Test" auf dem DBCtrlGrid (nicht die Große ganz rechts). Das lausige Ding akutaliseirt bei mir nicht in allen Panels, sondern nur im geradea akutellen Panel. Folge: Die anderen Panels bleiben leer.


Viele Grüße // Martin


PS: Man kann die Parenteigenschaft meiner Kompo ändern, dann erscheint Sie auch auf anderen Elementen,
da ist natürlich kein Problem, da keien weiteren Panels gezeichnet werden müssen.

[marabu]

Nicht deine Komponente ist das Problem, sondern die Art wie du sie zur Laufzeit auf das Grid klebst. Durch meine Änderung an deiner Uses-Klausel habe ich ja auch rechts deine Komponente - und die funktioniert, soweit ich das erkennen kann.

[mschaefer]

Das Problem tritt nur bei DBCtrlGrid auf.
Hm, irgendwie reden wir noch aneinander Vorbei... weiß der Geier...
Tja, ich probier das mal mit einer Grafik, dass bringt dies doch anschaulicher.


An die Stelle wo ich von Hand den roten Pfeil gezeichnet habe, müßte die
Komponente eigentlich "1351" anzeigen. Tut sie nicht. Es bleibt leer. Da hakt es.
Dafür zeigt sie die 1351 eine Zeile weiter oben an, wo eigentlich "1231" steht.


Viele Grüße // Martin



PS: Egal ob installiert oder dynamisch erzeugt, bekomme ich folgendes Verhalten:

[stahli]

Hallo mschaefer,

ich kann Deinen Quelltext hier im Dienst nicht laden und testen (ich weiß also nicht, was Deine Kompo genau anders macht), daher nur mal eine Vermutung:

Vielleicht wird sie ja gezeichnet und zeigt nur einen Leerstring an.
Ändere doch zuerst mal die Hintergrundfarbe oder füge dem Ausgabetext die aktuelle Uhrzeit hinzu.
Wenn nur die Uhrzeit angezeigt wird, erfolgt die Anzeige, aber der "Feldinhalt" ist leer.

Das könnte dann möglichweise am Datensatzpuffer liegen. Das Problem hatte ich bei einer eigenen Dantenbankkomponente (die mehrere Datensätze anzeigt) auch schon. Ich musste dann noch den Puffer in einer ausreichenden Größe festlegen.


(hoffe, das bringt Dir was)

Stahli

[Hansa]

Hallo Martin,

sehe auch nicht, was da genau los ist. Allerdings fällt mir folgendes auf :

Delphi-Quellcode:

  TDBText = class(TCustomLabel)

Die Klasse heißt genauso wie die von Delphi, nämlich "TDBText". :shock: Ob das mal gutgeht. Das nächste ist die Ableitung von TCustomLabel. Wozu das ? Dadurch handelst Du dir ein, tatsächlich mit den Datalinks rumhantieren zu müssen und sämtliche Sachen vom TLabel nachprogrammieren zu müssen. Wieso nicht das TLabel verwenden ? Und diese erweitern.

Habe selber einige DB-Komponenten. Bei denen bin ich aber immer von den Delphi-eigenen für DBs ausgegangen. In diesem Falle wäre das eben ein TDBText. Wo kommen die Infos über das DataLink eigentlich her ? Normalerweise kennt die keiner. :mrgreen: Außer Marco Cantu.

[stahli]

... da kommen wir der Sache schon näher ;-)

So ahnlich habe ich das auch gemacht. Ich habe mehrere Standardkomponenten und die DB-fähig gemacht, indem ich diese mit meinen zwei Komponenten DBSqlID bzw. DBSqlWhere erweitert und verbunden habe. Beide sind von DBSqlCustom abgeleitet.

DBSqlId ist relativ einfach aufgebaut und gibt Inhalte eines Datensatzes zurück (benutze ich derzeit in DBPanelSql, DBLabelSql, DBEditSql, DBRadioGroupSql, DBUpDownSql). DBSqlWhere ermöglicht es, mehrere Datensätze anzuzeigen (derzeit DBPanelsSql, DBTabControlSql), dafür muss ein entsprechender Datensatzpuffer eingerichtet werden, sonst gibt es bei Zugriffen nur Leerstrings.

Die Besonderheiten meiner Kompos sind:
- Anzeige beliebiger Datensätze (abhängig von einem ID-Feld und unabhängig vom aktuellen Datensatz)
- sofortiges Ändern in der Datenbank (jeder eingegebene Buchstabe im DBEditSql ist sofort in allen anderen Datenbankkomponenten zu sehen
- Änderungen von Join-Datenmengen, indem dazu lediglich eine UpdateTabelle, UdateIdField und UpdateIdValue definiert werden muss
- filtern und sortieren von Datenmengen, einstellbar in der Komponente selbst
- automatisches Drag&Drop für das Verschieben von Datensätzen (es muss ein PosField definiert werden und die Komponente ändert dann die entsprechenden Positionswerte)
- koppeln und entkoppeln von Datenmengenkomponenten (jede kann also unterschiedliche Datensätze anzeigen oder diese mit anderen syncronisieren)

Was macht denn Deine Komponente besonderes? Nutzt Du nur den aktuellen Datensatz der Datenmenge oder auch mehrere Datensätze?


Stahli

PS: Mit den FieldDataLinks habe ich mich mehrere Wochen beschäftigt ;-)

[mschaefer]

Ja ich habe den Weg gewählt, weil ich das Verhalten von erweiterten Non-DB-Komponenten 1:1 bei den DB-Kompos haben wollte. Das sind manchamal ganz triviale Dinge:

z.B. 1: ein Memo, das seine Hintergrundfarbe beim Anklicken ändert. Damit ich das nicht beim DBMemo nochmal programmieren mußte, ist das mit einer Overlayclasse dann DB-fähig gemacht worden.

z.B. 2: eine Labelkomponente die alle Linefeeds ausfiltert und nur eine bestimmte Anzahl Zeichen anzeigt. Die wird als Vorschaukomponente in einer Listenausgabe auf die Daten eines Memos der Detailansicht angestzt.

Der Weg hat mir schon viel Arbeit abgenommen, aber das DBCtrlGrid-Problem habe ich leider bei einer Reihe von Kompos bisher nicht gelöst bekommen.

@Hansa:
Das mit dem DBText als gleichen Namen macht vielleicht was aus. Bei mir geht es, bei Marabu nicht oder nur mit Usesumstellung. Du hast natürlich recht, wenn Du darauf Hinweist, dass man solche Benennugen besser lassen sollte. Brauchte ein möglichst einfaches Projektbeispiel und mit erweiterten Memos wird das recht komplex.

Viele Grüße // Martin

PS: @stahli habe keine Komponenten dabei, die mehrere Datensätze bearbeiten. Da bist Du wohl weiter!

PPS: Jetzt habe ich "Marco Cantu" doch erstmal gogglen müssen. Die Idee mit dem DataLink kam bei einem Projekt, was zeitlich hart an der Crashgrenze war. Aber Marco könnte man mal ja noch fragen...

[marabu]

Hallo Martin,

Zitat:

Zitat von mschaefer

@Hansa: Das mit dem DBText als gleichen Namen macht hier tatsächlich nichts, da die Projektunit bevorzugt wird.

nicht in deiner Demo. Wie ich schon in Beitrag #2 schrieb, musste ich die Unit UDBTEXT in der Uses-Klausel ans Ende schieben, weil sonst die original VCL-Komponente verwendet wurde. Dadurch habe ich beobachten können, dass dein Anzeigeproblem erstmal nichts mit deiner Komponente zu tun hat, sondern damit, dass die Komponente erst zur Laufzeit auf das Grid gelegt wird.

Zitat:

Zitat von mschaefer

irgendwie reden wir noch aneinander Vorbei

Immer noch?

Freundliche Grüße

[stahli]

Hab eine Idee - muss aber schnell machen, meine Kollegin scheucht mich von Ihrem Rechner weg :-((

DBCtrlGrid missbraucht ja irgendwie die eingebundenen DB-Kompos und zwingt denen die Anzeige auf (anhand der Datensätze SEINES Datenpuffers). Ein normals DBLabel würde ja z.B. immer nur die Anzeige des AKTUELLEN Datensatzes ermöglichen.

Deine Kompo müsste daher vermutlich so kompotibel gemacht werden, dass sie sich, wenn sie in einem DBCtrlGrid plaziert ist, die Datenmengenwerte aus dessen Datenpuffer bezieht...

Soviel erst mal bis zum Feierabend...

Stahli

[mschaefer]

Hallo Marabu,

das mit der Usese Klausel könnte natürlich von den Delphi-Versionen variieren. Bei mir startete er meine, aber das würde das anneinander Vorbeireden erklären, denn Du hattest wahrscheinlich die funktionierende Orginal-DB-Kompo auf Deinem DBCtrlGrid. Ich sollte die Komponente umbenennen. Das Bild Problem kommt dann natürlich auch bei Dir zum vorschein.

Hallo Stahli,
denke da muß der Pfad irgendwo liegen...


Viele Grüße // Martin

[mschaefer]

Moin, moin,

nach einigem Überlegen habe ich folgend meine Quelle zu "DataLink" hervorgekramt!
Allerdings, wie Hansa schon angedeutet hat, gibt es da nicht überaus viel im (W)Internet:

The Unofficial Delphi Component Writing FAQ

Und kommentiert ist das von Hersusgeber John M. Miano folgend:

Zitat:

As far as I can tell the only documentation for TDataLink that exists in the
entire universe is what follows

Das Univers dreht sich aber weiter und vielleicht
findet sich dann doch noch ein MilkyWay mit Infos. :wink:


Viele Grüße // Martin

[Hansa]

Zitat:

Zitat von mschaefer

z.B. ein Memo, das seine Hintergrundfarbe beim Anklicken ändert. Damit ich das nicht beim DBMemo nochmal programmieren mußte, ist das mit einer Overlayclasse dann DB-fähig gemacht worden...

Was ist eine "Overlayclasse" ? :shock: Aber egal : gehe weg von dem DataLink. Das wird zu kompilziert. Wie bereits gesagt : besser die Ereignisse (nicht DB !!)notfalls in eigener Komponente neu machen. Dafür ist der Komponenten-Vorfahr zu rate zu ziehen. Wurde der schon falsch gewählt, tja dann....

[stahli]

Da dürfte Hansa recht haben.

Wenn man nicht wesentliche Datenbankfunktionen verändern möchte sondern eher sonstige Eigenschaften von Komponenten, ist es wohl weniger Aufwand, die Änderungen in der normalen und der Datenbankkomponente zu überschreiben, als sämtliche Datenbankfunktionen neu zu entwickeln.
Man kann ja die eigentlichen Funktionen dafür in einer eigenen Unit auslagern und von TMyColorMemo und TMyDBColorMemo aus gleichermaßen nutzen...
(wenn ich das nicht wieder falsch verstanden habe)

Stahli

[mschaefer]

Ja meine Ausdrucksweise war etwas knapp "abgeleitete Klasse" für Overlayclass.
Der Ansatz ist gerade unterschiedliche Klasssen dadurch DB-fähig zu machen, in dem die
zuletzt abgeleitete Klasse den DB-Zugriff steuert.

Man hat prinzipiell zwei Wege DB-Klasse in der Mitte und alle weiterführenden Klassen
darauf aufstezten oder alle Klassen unter der DB-Klasse. Bei letzterem kann ich eine
nicht DB-Komponente erweitern und die zugehörige DB-Komponente hat nach dem Package
compilieren die gleichen eigenschaften.

Wenn man es einmal aufgebaut hat, ist es nachher deutlich leichter, da man sich nicht
unterschiedliche Properties von DB und nicht DB-Klassen (bis auf den Link) merken muß.

Hoffe ja, dass vielleicht doch noch jemand einen weiteren Gedanken zu der DBCtrlGrid
Sache hat, dann wäre das Verfahren durchgängig gelöst.

Viele Grüße // Martin

[Hansa]

Zitat:

Zitat von mschaefer

Hoffe ja, dass vielleicht doch noch jemand einen weiteren Gedanken zu der DBCtrlGrid Sache hat, dann wäre das Verfahren durchgängig gelöst.

Wie gesagt : Marco Cantu. :lol: Nofalls suche ich das PDF-Buch und bräuchte email-Adresse.

[mschaefer]

Well, moin,

inzwischen bin ich soweit, dass ich mit einer DataLinkListe experimentiere. Offensichtlich brauchet jedes Element auf dem DBCtrlGrid Panel seinen eigenen Datenspeicher. Wie stahli schon vermutete wird jedes Element gezeichnet, aber auf den nicht aktuellen Panels landed ein Leerstring. Soweit zunächst.

Viele Grüße // Martin

[stahli]

Hallo Martin,

also meine Komponenten funktionieren in DBCtrlGrid gar nicht (müssen sie aber auch nicht). DBEditSql (abgeleitet von DBEdit) lässt sich nicht einmal in das Grid einbinden.
Das Grid übernimmt offenbar die Kontrolle über die eingebunden Kompos, ordnet denen seine eigene interne Datenmenge zu und gibt möglicherweise sogar vor, wann diese Kompos neue Dateninhalte anzeigen sollen (sonst würden sie möglicherweise alle den Inhalt des aktuellen Datensatzes anzeigen).
Wenn das so ist, muss das Grid aber die eingebunden Komponenten kennen, um diese für seine Zwecke umzubiegen...

Mit dem FieldDataLink musst Du Dich m.E. nur näher beschäftigen, wenn Du mehrere Datensätze in Deiner Komponente verwalten willst (wie ein DBGrid).

Ansonsten reicht es, einfach nur FieldDataLink einzubinden. So habe ich es für meine Ein-Datensatz-Komponente gemacht:

Delphi-Quellcode:

//
constructor TDBSqlCustom.Create(AOwner: TComponent);
begin
  inherited;
  FFieldDataLink:=TFieldDataLink.Create;
  FieldDataLink.Control:=Self;
  FieldDataLink.OnDataChange:=DataChange;
...

//
procedure TDBSqlCustom.SetDataSet(Value:TDataSet);
begin
  if ((FieldDataLink<>nil) and (FieldDataLink.DataSource<>nil)) then begin
    if (Value<>FieldDataLink.DataSource.DataSet) then begin
      FieldDataLink.DataSource.DataSet:=Value;
      ShowData(True); // Datensatzinhalt anzeigen
    end;
  end;
...

procedure TDBSqlCustom.SetFieldName(Value:String);
begin
  if (FFieldName<>Value) then begin
    FField:=nil;
    FFieldName:=Value;
    FFieldDataLink.FieldName:=FFieldName;
    ShowData(True);
...

procedure TDBSqlCustom.SetDataSource(Value:TDataSource);
begin
  if ((FFieldDataLink<>nil) and (FFieldDataLink.DataSource<>Value)) then begin
    ResetFields(True);
    FFieldDataLink.DataSource:=nil;
    FFieldDataLink.FieldName:='';
    if (not (FFieldDataLink.DataSourceFixed and (csLoading in ComponentState))) then FFieldDataLink.DataSource:=Value;
    if (Value<>nil) then Value.FreeNotification(Self);
    ShowData(True);
...

Für mehrere Datensätze habe ich einen ausreichend großen Puffer für die anzuzeigenden Datensätze angelegt:
FieldDataLinkShow.BufferCount:=100; (wobei ich mehrere Datenmenge syncronisiere und deshalb die Puffergrößen aufeinander abstimmen muss)

Mit FieldDataLinkShow.ActiveRecord:=FieldDataLinkShow. ActiveRecord+-1 kannst Du durch die Datensätze iterieren, ohne dass dies Auswirkungen auf angebundene datensensitive Komponenten hat.
Wenn Du außerhalb des definierten Pufferbereiches kommst, erhältst Du nur noch leere Dateninhalte.

TDBSqlWhere kapselt die ganze Datenbankverbindung und wird von meinen TDBTabControlSql und TDBPanelsSql jeweils benutzt, um "die jeweils nächsten" Datensätze bereitzustellen. Die beiden Komponenten wiederum geben Ihrerseits vor, wann die Dateninhalte der einzelnen Items gezeichnet werden müssen:

Delphi-Quellcode:

//------------------------------------------------------------------------------
//
procedure TDBSqlWhere.SetDBSqlBufferCount(MaxCount:Integer);
var NeedBufferCount:Integer;
begin
  if (MaxCount=0) then MaxCount:=MinBufferCount;
  if ((MaxCount>0) and (RecordCount>0)) then NeedBufferCount:=Min(RecordCount,MaxCount)
  else NeedBufferCount:=RecordCount;
  DBSqlBufferSize:=Max(DBSqlBufferSize,NeedBufferCount);
  if (FieldDataLinkShow.BufferCount<DBSqlBufferSize) then FieldDataLinkShow.BufferCount:=DBSqlBufferSize;
end;

//------------------------------------------------------------------------------
//
procedure TDBSqlWhere.BeginReadRecord(RR:Integer=-1);
begin
  if (RR>0) then FieldDataLinkShow.ActiveRecord:=RR;
  if (FieldDataLinkShow<>nil) then begin
    ActiveDBSqlRecNo:=DataSetShow.RecNo;
    ActiveDBSqlRecord:=FieldDataLinkShow.ActiveRecord;
  end
  else begin
    ActiveDBSqlRecNo:=0;
    ActiveDBSqlRecord:=0;
  end;
  FirstDBSqlRecNo:=ActiveDBSqlRecNo;
  LastDBSqlRecNo:=ActiveDBSqlRecNo;
  ReadDBSqlRecNo:=ActiveDBSqlRecNo;
  FirstDBSqlRecord:=ActiveDBSqlRecord;
  LastDBSqlRecord:=ActiveDBSqlRecord;
  ReadDBSqlRecord:=ActiveDBSqlRecord;
end;

//------------------------------------------------------------------------------
//
function TDBSqlWhere.GetReadRecord(RR:Integer):Boolean;
begin
  Result:=False;
  if ((RR>=0) and (RR<RecordCount)) then begin
    if ((RR<FirstDBSqlRecord) or (FirstDBSqlRecord<0)) then FirstDBSqlRecord:=RR;
    if (RR>LastDBSqlRecord) then LastDBSqlRecord:=RR;
    FieldDataLinkShow.ActiveRecord:=RR;
    Result:=True;
  end;
end;

//------------------------------------------------------------------------------
//
function TDBSqlWhere.ReadRecordIsActive:Boolean;
begin
  Result:=(FieldDataLinkShow.ActiveRecord=ActiveDBSqlRecord);
end;

//------------------------------------------------------------------------------
//
procedure TDBSqlWhere.GoToRecNo(RN:Integer);
begin
  inherited;
  if (DataSetShow<>nil) then begin
    if (RN>RecordCount) then RN:=RecordCount;
    if (RN>0) then DataSetShow.RecNo:=RN;
  end;
end;

//------------------------------------------------------------------------------
//
procedure TDBSqlWhere.EndReadRecord;
begin
  if (FieldDataLinkShow<>nil) then FieldDataLinkShow.ActiveRecord:=ActiveDBSqlRecord;
end;

Das sind zwar etwas ältere Quelltexte, das Prinzip sollte aber erkennbar sein...

Gruß Stahli

[mschaefer]

Moin, moin,


Marabu hat recht! :wink:

Die Komponente wird nicht korrekt angezeigt,weil Sie dynamisch erzeugt wird.
Irgenwo habe ich vergessen diese im Grid zu registrieren. Da liege ich oben auch falsch!

Wie kannich den jetzt herausbekommen,was das Grid macht, wenn die Komponente darauf abgelegt wird :?:


Muß am Wochenende nochmal etwas mehr lesen...

Grüße // Martin


PS Da hat die JVcl doch auch ähnliche Probleme
TJvDBHTLabel doesn't support painting on TDBCtrlGrid

[mschaefer]

Moin, moin,

Wie erstelle ich eine Komponente dynamisch auf einem DBCtrlGrid?

Das läßt mich immer noch nicht los. Inzwischen bin ich soweit,
dass ich davon ausgehe, die dynamisch erstellte Komponente nicht
das TDBCtrlGrid als Parent haben muß, sondern das Panel des
TDBCtrlGrid. Das Panel muß nur im Zugriff liegen, da hakt es im Moment....

@Hansa ich habe bei Marco Cantu etwas auf den Webseiten gesucht.
Das wird wohl auch noch helfen. Danke für den Tipp!

Grüße // Martin

[mschaefer]

Moin, Spätmoin,

Danke an alle im Thread, denn ich habe
von jedem einen Tipp bekommen, für den
nächsten Schritt. Und jetzt kommt die
Lösung im Anhang.

Wofür braucht man das nun?

Das ist die Grundlage für eine Komponente
die mehrere Felder (je nachdem wieviele
der zugrundelegende DataSet hat) selbständig
auf dem DBCtrlGrid anordnet.


Viele Grüße // Martin :cheers: