Richard Heck wrote:
It turns out that the multiple calls are due to the fact that
updateToolbars(), which is called at the end of the dipatch() routine,
also calls update() which calls update_contents(). Since update() also
gets called in, say, the INSET_APPLY routine, you get multiple calls. Is
It turns out that the multiple calls are due to the fact that
updateToolbars(), which is called at the end of the dipatch() routine,
also calls update() which calls update_contents(). Since update() also
gets called in, say, the INSET_APPLY routine, you get multiple calls. Is
it worth looking into
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > By the way, running several of these dialogs through the debugger, I've
> > noticed that this is generally true: if you go through update_contents()
> > once, you'll go through it two or three times. This does not seem like a
> > good thing, but I d
Richard Heck wrote:
This patch was sent to the list a few days back. I'm reposting it before
committing, in case anyone wants to comment.
The previous code for setting a "default" reference was irremediably
broken. State has to be maintained in QRef itself, not in the list
widget, which gets cle
This patch was sent to the list a few days back. I'm reposting it before
committing, in case anyone wants to comment.
The previous code for setting a "default" reference was irremediably
broken. State has to be maintained in QRef itself, not in the list
widget, which gets cleared every time throu
The attached patch addresses these two bugs. I'm not proposing to commit
before beta 2, but comments are nonetheless invited.
The previous code for setting a "default" reference was irremediably
broken. State has to be maintained in QRef itself, not in the list
widget, which gets cleared every ti