DataGrid Crash to Desktop Revisited
Bob Sneidar
bobsneidar at iotecdigital.com
Wed Dec 18 19:45:51 EST 2019
This is likely the culprit in the datagrid library. There are a number of places where it is called:
private command _SelectionChanged pPreviouslyHilitedIndexes
dispatch "selectionChanged" with sHilitedIndexes, pPreviouslyHilitedIndexes
end _SelectionChanged
I think what is needed is a way to discern that a selectionChanged handler is already in progress when setting the dgData. I could trace all the way through the datagrid library, but it's late, and I was hoping someone could quick fix this for me. I do this a LOT, strange as it seems.
Bob S
> On Dec 18, 2019, at 16:30 , Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
>
> Hi all.
>
> I have isolated the issue I presented some time ago, where selecting a record in a datagrid crashed Livecode to desktop. It can be reproduced easily enough.
>
> Create a stack with a single datagrid, add 2 records. In the script of the datagrid have a selectionChanged handler like so:
>
> on selectionChanged
> put the dgHilitedIndex of me into tHilitedIndex
> put the dgDataOfIndex [tHilitedIndex] of me into aDGData [1]
> set the dgData of me to aDGData
> end selectionChanged
>
> This demonstrates that a datagrid's selectionChanged handler cannot set it's own dgData! Neither can any other handler in the executionContexts that selectionChanged calls, while that selectionChanged is still in the executionContexts. (That's too confusing.)
>
> In other words, while a datagrid's selectionChanged handler is "running" nothing can change the contents of the datagrid.
>
> I'm not sure why this is, but I think it's because the datagrid library does something internernally that triggers another selectionChanged, causing an infiinite loop, forcing the engine to bail out.
>
> Any ideas?
>
> Bob S
More information about the use-livecode
mailing list