On Fri, May 06, 2005 at 08:10:23PM +0200, Andre Poenitz wrote: > On Fri, May 06, 2005 at 05:48:34PM +0300, Martin Vermeer wrote: > > On Fri, 2005-05-06 at 15:28, Martin Vermeer wrote: > > > > > > > > The second reported crash still happens, but is rarer and presumably > > > unrelated: > > > > > > # InsetTabular::getNearestCell() x=82 y=150 > > > Assertion triggered in pit_type LyXText::getPitNearY(int) const by > > > failing check "theCoords.getParPos().find(this) != > > > theCoords.getParPos().end()" in file text2.C:854 > > > > This is fixed by the attached, which simply shunts out cursor up/down > > for the duration of screen redraw / coordinate cache maintenance. > > That's pretty bad from the pov of a reliable scripting interface.
I tried also a while loop, hanging until updating finished... but that only left all off LyX hanging. Figures. > > The problem was again, that the cursor got ahead of itself and went to a > > cell below or above with the coordinate cache in statu nascendi, before > > the relevant lyxtext paragraph entry was ready. I don't know if we > > should look for a deeper reason for this; as Angus pointed out, there's > > an obscene number of bv.update() calls sprinkled over the code. > > > > Also, don't ask me if this is the only place where such a bypass > > operation would be called for. At least the crashes have stopped. > > > > Ideas? > > I'd still like somebody to try out that 'command queue' approach. > I'd think this fixes this particular problem properly. > > Andre' > > PS: If Alfredo doesn't shout within a few hours that he'll give it a try > I'd try to convince the family that this is important... Yes... - Martin
pgpmoVkaNEcrl.pgp
Description: PGP signature
