Bug bei DataSource/DataSet State (dsInsert) & SetEnabled & DisableControls

[DSCHUCH]

Hallo,

ist jemand folgender Bug bekannt? Resultat sind unter anderem schief stehende DB-Navigatoren.

Form, DataSet, DataSource, DBNavigator

Delphi-Quellcode:

DataSet.Open;
DataSet.DisableControls;  //DataSource merkt sich State in FState (dsBrowse)
DataSet.Insert;           //da Disabled Controls, keine Änderung im DataSource
DataSource.Enabled:=True; //DataSource bekommt zwangsstate "dsInsert"
DataSet.Post;             //da Disabled Controls, keine Änderung im DataSource, bleibt auf dsInsert
DataSet.EnableControls;   //Abgleich von FDisabledState und DataSet.State: dsBrowse = kein Umsetzen des State der DataSource, somit steht das ungleich. Totales Durcheinander der Status. ;

Delphi-Quellcode:

TDataSet.EnableControls;
...
if FDisableState <> FState then DataEvent(deUpdateState, 0); //durch das falsch zwischengesetzte State mittels Enabled:=True schlägt es hier fehl

Somit steht DataSource auf Insert, DataSet auf Browse.

In kurz: ein wechsel des DataSet.BrowseMode zu vor DisableControls und wechsel des DataSource.EnabledState während DisabledControls führt zum Bug.

[p80286]

[OT]
wer keine datensensitiven Controls verwendet, kennt soche Fehler nicht
[/OT]

Gruß
K-H

[Sherlock]

Ist es ein Bug, oder ein Fehler in der Anwendung der Komponenten?
Würdest Du das wirklich so machen wollen, bzw. was erhoffst du dir von Deinem Vorgehen?

Sherlock

[DSCHUCH]

[OT]wer keine Datensensitiven Komponenten verwendet, muß sich diese selbst bauen oder er braucht die X-Fache Entwicklungszeit [/OT]

Das ist ein Bug. Das Problem ist, das andere Komponentenhersteller bestimmte Status voraussetzen.
https://www.devexpress.com/Support/C...etails/T114617

So hatten wir zB einfach im Before/After-Insert unserer Basisklassen ein Enabled:=True eingebaut. Resultat ist dann aber dieser Bug, wenn mit DisableControls gearbeitet wurde.

Letztlich ist es ein Bug, da es einfach zu einem fehlerhaften Status führt. Insb. da im SetEnabled nicht mal auf If Enabled=Value then Exit geprüft wurde. Wenn das so nicht sein darf, also Enabled im DisableControls umstellen, muß eine Exception kommen.

Wir haben das Problem bei uns jetzt gelöst, allerdings mal wieder haufenweise Stunden für diesen Senf versenkt.

[Dejan Vu]

Blöde Frage: Wer fummelt denn am DataSource.Enabled herum? Mir käme das auch nicht in den Sinn.

Aber es ist ein Bug, keine Frage...

[BadenPower]

Zitat von Dejan Vu:

Blöde Frage: Wer fummelt denn am DataSource.Enabled herum? Mir käme das auch nicht in den Sinn.

Da muss ich Dir endlich einmal Recht geben.

Die Frage ist wirklich nur blöd.

Schon einmal über eine benutzerabhängige Datenanzeige nachgedacht, bei der das Layout der Anwendung nicht verändert wird.

[Dejan Vu]

Zitat von BadenPower:

Da muss ich Dir endlich einmal Recht geben.

Qualität setzt sich eben durch.

[BadenPower]

Zitat von Dejan Vu:

Zitat von BadenPower:

Da muss ich Dir endlich einmal Recht geben.

Qualität setzt sich eben durch.

Wie misst man die Qualität blöde Fragen zu stellen?

Wäre die obige Frage jetzt eine Frage, welche qualitativ an Dein hohes Niveau herankommt?

[DSCHUCH]

Enabled:=False schaltet alle Datensensitiven Komponenten komplett ab, als wäre das DataSet geschlossen bzw hätten diese kein DataSource zugewiesen. Nutzen wir zB wenn eine Suche keinen Treffer ergibt und man nicht will, das durch AutoEdit=True dann automatisch ein Datensatz angelegt werden kann.

Zum Rest (Qualität blöder Fragen) kann ich heute aufgrund schlechter Laune nichts gutes / ironisches beisteuern, dazu gab es heute schon zu viele

[Dejan Vu]

Danke für die Aufklärung: Interessant, hatte ich nie auf dem Schirm. Ich hab -glaube ich- einfach immer das TDatasource vom TDatset entkoppelt.