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@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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
