[patch_done] DevExpress (quantumgrid) and ZeosLib
Moderators: gto, EgonHugeist, olehs
[patch_done] DevExpress (quantumgrid) and ZeosLib
Hello,
I am trying to work with zeoslib (svn) and Devexpress (Delphi 2010). I have this:
1.- TZquery (or TZReadOnlyQuery).
2.- Standard Datasetassociated with the TZQuery
3.- QuantumGrid (devexpress) associated with the Dataset.
When I active the Query, EOF is true.
When I go to ZQuery1.first, EOF is true.
If I "disconnect" QuantumGrid from TZQuery, then EOF is false on both situations.
If I sustitute:
TZQuery with TADODataSet
TZQuery with PgQuery (Devart)
TZQuery with ...............
And reconnect it with QuantumGrid, all is ok. EOF is false.
It seems a problem with ZeosLib ONLY.
Greetings.
I am trying to work with zeoslib (svn) and Devexpress (Delphi 2010). I have this:
1.- TZquery (or TZReadOnlyQuery).
2.- Standard Datasetassociated with the TZQuery
3.- QuantumGrid (devexpress) associated with the Dataset.
When I active the Query, EOF is true.
When I go to ZQuery1.first, EOF is true.
If I "disconnect" QuantumGrid from TZQuery, then EOF is false on both situations.
If I sustitute:
TZQuery with TADODataSet
TZQuery with PgQuery (Devart)
TZQuery with ...............
And reconnect it with QuantumGrid, all is ok. EOF is false.
It seems a problem with ZeosLib ONLY.
Greetings.
What we've also found is:
When a TZQuery is attached to a DevExpress control (not only grid, but lookupcombo etc.),
any action which causes the record pointer to move does not work.
e.g. TZQuery.locate, .first, .last, .next, .prior etc.
The DevExpress control ALWAYS move the record pointer to the eof position of the recordset.
Our present temporary workaround is to issue a TZQuery.disablecontrols before doing these actions and then issue a TZQuery.enablecontrols afterwards.
Looking forward to see the ultimate solution.
When a TZQuery is attached to a DevExpress control (not only grid, but lookupcombo etc.),
any action which causes the record pointer to move does not work.
e.g. TZQuery.locate, .first, .last, .next, .prior etc.
The DevExpress control ALWAYS move the record pointer to the eof position of the recordset.
Our present temporary workaround is to issue a TZQuery.disablecontrols before doing these actions and then issue a TZQuery.enablecontrols afterwards.
Looking forward to see the ultimate solution.
Here is the answer from DevExpress support services. They tell us it is an issue with ZeosLib and the DevExpress "way of do".
In spite of the advice, it doesn't run at all. The only solution is disable controls.
In spite of the advice, it doesn't run at all. The only solution is disable controls.
First, let me explain how cxGrid works in default loading mode.
When you open some DataSet, the cxGrid saves the current position (via bookmarks), loads all data to the DataController object and restores its position in the DataSet:
[Delphi]However, the TZQuery incorrectly processes the restoration of the position via bookmarks.Code: Select all
procedure LoadData; ... SavePos; First; ... while not IsEOF do begin ARecordIndex := DataStorage.AppendRecord; DataStorage.ReadRecord(ARecordIndex, AValueDefReader); Self.DoReadRecord(ARecordIndex); Next; end; ... RestorePos; ...
That is why you see this behavior (Eof = true).
To solve this problem, you can manually call the ZQuery1.First method or use our cxGrid in GridMode.
Please refer to the "Grid Mode" topic of the ExpressQuantumGrid documentation to learn more about it.
Hope, it will help you achieve the required functionality.
We've found that when a TZQuery is linked to a quantumgrid,
and when one of the columns is sorted, the eof problem seems not appearing. We'll do more tests on that. And it seems not consistent with what they said.
I think that Quantum being sold as a commercial software should provide more support. How can they just throw a few words and go away like that? Maybe they're right but at least they should provide some evidence.
and when one of the columns is sorted, the eof problem seems not appearing. We'll do more tests on that. And it seems not consistent with what they said.
I think that Quantum being sold as a commercial software should provide more support. How can they just throw a few words and go away like that? Maybe they're right but at least they should provide some evidence.
Rickyxp,
I only can insist and re-open the issue if I can object something to the DevExpress support answer. If nobody of the ZeosLib developers can help here then I cannot do any more.
* DevExpress runs fine with any other dataset components I have tested (PostgresDAC, Devart Oracle and Postgres native, native Delphi datasets....) except with ZeosLib.
* ZeosLib runs fine with standard DbGrid (i have not checked any more grid) but not with DevExpress.
I cannot do anything more.
I only can insist and re-open the issue if I can object something to the DevExpress support answer. If nobody of the ZeosLib developers can help here then I cannot do any more.
* DevExpress runs fine with any other dataset components I have tested (PostgresDAC, Devart Oracle and Postgres native, native Delphi datasets....) except with ZeosLib.
* ZeosLib runs fine with standard DbGrid (i have not checked any more grid) but not with DevExpress.
I cannot do anything more.
yapt,
I just encounter problem with standard grid - please see: http://zeosbugs.firmos.at/view.php?id=216
I don't have devex components so I can only assume that we have common problem but can you test this?
I just encounter problem with standard grid - please see: http://zeosbugs.firmos.at/view.php?id=216
I don't have devex components so I can only assume that we have common problem but can you test this?
yapt,
I investigated this further and (maybe?) solved problem completely. Attached pactch against rev776 solves all my problems and maybe yours also. Please try it.
Modifications from last patch are included in file.
P.S.
Also corrected possible problem with unassigned ApplicationHandleException pointer.
I investigated this further and (maybe?) solved problem completely. Attached pactch against rev776 solves all my problems and maybe yours also. Please try it.
Modifications from last patch are included in file.
P.S.
Also corrected possible problem with unassigned ApplicationHandleException pointer.
You do not have the required permissions to view the files attached to this post.
Rev.779 doesn't completely solve problem (Lazarus64 wont work). I posted (maybe) final solution here: http://zeosbugs.firmos.at/file_download ... 0&type=bug. More info: http://zeosbugs.firmos.at/view.php?id=216
Last edited by trupka on 28.01.2010, 16:55, edited 2 times in total.