DataGrid Crash to Desktop Revisited

[Bob Sneidar]

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