Stack trace when entering a value in SQLQuery1HEAD_DEPT:
#0 TFIELD__CALCLOOKUPVALUE(<error reading variable>) at .\fcl-db\src\base\fields.inc:617
#1 TDATASET__CALCULATEFIELDS(0x97508 '', <error reading variable>) at .\fcl-db\src\base\dataset.inc:150
#2 TDATASET__GETCALCFIELDS(0x26df8c0 #168#248'm'#2#204#250'm'#2#1, <error reading variable>) at .\fcl-db\src\base\dataset.inc:472
#3 TDATASET__EDIT(<error reading variable>) at .\fcl-db\src\base\dataset.inc:1698
#4 TDATASET__INTERNALCANCEL(<error reading variable>) at .\fcl-db\src\base\dataset.inc:934
#5 ?? at :0
#6 TCUSTOMGRID__EDITORKEYPRESS(0xa1a38, 49 '1', <error reading variable>) at grids.pas:7598
TField.CalcLookupValue is where LookupCache is tested.
What do you suggest? That aText should contain the string value as it would be displayed without the handler?
function TField.GetDisplayText: String;
begin
///SetLength(Result, 0);
GetText(Result, True);
if Assigned(OnGetText) then
OnGetText(Self, Result, True);
end;
The current behavior is in line with many event handlers.
Assign an TDBGrid.OnDrawColumnCell or a TForm.OnPaint and enter no code: nothing will be drawn.
although I disagree with this behavior it is understandable up to a point. Windows solved this problem by allowing the callback procedure to flag the message handled so it does not paint anything if it is flagged or paint everything if it is not, but this is not comparable to the problem at hand a draw procedure has many levels and can't be broken down to smaller steps (this is a design flow in my view btw) so it is understandable to have an all or nothing policy including call the callback before the default paint, to avoid screen flicker and speed up the application responsiveness. Of course the paint is called a few dozen times a second and is a lot slower than a simple move/convert of a few bytes overall so it makes sense to cut off the old for the sake of the new.
On data events on the other hand (especially on bufdataset which already has the data in memory) it is a design flow not to pass that data to the user's event.There is no all or nothing and most of the times some kind of check on the existing data would be required.
As it is now we have created a dangerous re-entrance situation think of it like this the user writes the event checks the text variable sees nothing and calls the displaytext property to get the text. That of course forces its application in to a loop which eventually will eat up all his stack and raise an exception.
This simple change will probably avoid most problems but hey you know what Einstein said about stupidity and the universe no guaranties can be made other than actively guarding against the re-entrance.
I hope I made my self clear of what I mean speed hack instead of stable I didn't mean to say that the framework is not stable.
Yep. By calling StringField1.RefreshLookupList;
Noted for future reference. I'm going to check for a more generic method first though and I'll report back.
Another known messy situation is that the lookupdataset is set active when the binding is done between field and lookupdataset. This causes some spurious activation of datasets when the form is streamed. Some bugreports and forum threads discuss this behavior.
Oh right I think I remember one of those it was resent as well.
Noted. first open the lookup datasets then link them to the lookup fields.
The good think is that everything is dynamic in my application even field definition and creation so I can just move a line of code or two up a few steps and this is no issue.
Thank you for your time as always you have been most helpful.
Recent
