I'm randomly getting these erros while checking/unchecking checkboxex created for some datagrid cells. Cannot find yet a way to isolate and reproduce it.
These checkboxes are created using: "DataGrid.AddCheckBox(LC, LR);"
Could you please tell under what circumstances this could happen, so I would know exactly what to investigate?
Thanks.
More details:
I'm using event OnCellCheckBoxChange, and several validation/calculation methods are called when the event is fired.
Many other cells are accessed, and many values may be modified.
Under some circumstances I could not tell (it completely random), while checking/unchecking checkboxes, the "no parent window" appears.
Discovered something interesting:
procedure TCustomCheckBox.Toggle;
begin
if Observers.IsObserving(TObserverMapping.EditLinkID) then
begin
if TLinkObservers.EditLinkIsReadOnly(Observers) then
Exit;
if TLinkObservers.EditLinkEdit(Observers) then
TLinkObservers.EditLinkModified(Observers);
end;
case State of
cbUnchecked:
if AllowGrayed then State := cbGrayed else State := cbChecked;
cbChecked: State := cbUnchecked;
cbGrayed: State := cbChecked;
end;
try
if Observers.IsObserving(TObserverMapping.EditLinkID) then
if TLinkObservers.EditLinkIsEditing(Observers) then
TLinkObservers.EditLinkTrackUpdate(Observers);
if Observers.IsObserving(TObserverMapping.ControlValueID) then
begin
TLinkObservers.ControlValueModified(Observers);
TLinkObservers.ControlValueTrackUpdate(Observers);
end;
except
SetFocus;
raise;
end;
end;
This is part of Vcl.StdCtrls.
When it runs State := cbChecked/cbUnchecked, TTMSFNCDataGridCheckBoxCell.DoCheckChange is called, and then DoCellCheckChange is called, and then when the flow goes back to vcl.stdctrls, sometimes the TCustomCheckBox is nil, the Observers property is nil, and then it enters the exception block.
Vcl.StdCtrls also has a bug. When it enters the exception block, the first statement is "SetFocus". In our case, the "Self" CustomCheckBox is invalid, so the SetFocus raises this no parent error, masking the real exception that is a simple and classic "Access Violation", and making us look for child/parent controls inconsistencies.
I tried to isolate which kind of cells access is cousing the checkbox to be destroyed inside of my methods, but just could notice that everytime I had a call to SetCell in the same grid that fired the OnCellCheckBoxChange, I get this random issue with the invalid TCustomcheckBox. Something is destroying it sometimes when I set other cells values in the same datagrid. If I just change cells values in nested child grids, there is no error.
As a workaround, I added a local version of vcl.stdctrls, and commented SetFocus / raise.
I can later try to make those cell value assignments out of OnCellCheckBoxChange scope, but I believe it'll require some weird timer logic with update flag checking.
The GIF & video is the output after I comment just the "SetFocus" in Vcl.StdCtrls.
Each of these checkboxes respond to the same OnCellCheckBoxChange event, the same grid calculations and assignments are made, and ther's no special processing depending on which Checkbox had been clicked.
Hi!
Please help needed. No comments?
Due to the holidays there is some delay with our support and we are currently working through it.
The responsible developer will get back to you as soon as possible.
Hi,
We already did some changes that are going to be part of the next TMS FNC UI Pack release which should avoid this. What you can also try is the following:
procedure TForm1.GridCellCheckBoxChange(Sender: TObject; ACol, ARow: Integer);
begin
TThread.ForceQueue(nil,
procedure
begin
// all the validation / SetCell calls that touch other cells
end);
end;
Hi @Pieter ,
I'm also having similar trouble when calling custom methods starting from AfterCloseInplaceEditor event. If a dialog is shown, like MessageDlg, then an access violation will be trown afterwards.
Is there a safe way to run methods that could have extra user interaction ran from within these kind of datagrid's events ?
(meanwhile, using ForceQueue too)
The best way to deal with this is still the ForceQueue. We'll investigate if we can find a better solution.