Abdelrazak Younes wrote:
rgheck wrote:
Stefan Schimanski wrote:
I've noticed something similar, though I haven't seen it reliably
(and so
haven't yet filed a bug report). Sometimes when I try to add one
citation,
what happens is that a previously inserted citation in the same
paragraph is
*modified*, even though the cursor wasn't next to that citation when I
selected Insert > Citation.
I see that very often and am very annoyed by it. Especially you
cannot undo it. So it destroys data and should be critical...
I can reproduce this as follows: Click on a citation inset, then hit
"escape". Now try to insert a citation. It modifies the one you had
clicked on before. I think this is because hitting "escape" bypasses
the normal dialog closing code. (I've seen this problem before.) As a
result, the open_insets_ map doesn't get modified, and
open_insets["citation"] is still pointing at that old inset instead
of being 0.
I'll bet if you deleted it before trying to inset a citation, you'd
get a crash.
The problem must affect every dialog--inset pair, for the same reason.
Abdel will know what to do. Right Abdel?
OK, I think I fixed it at rev25158.
That didn't do it, because GuiCitation has its own closeEvent(). I think
I've fixed it now, but there's still a problem with the Cancel button.
This calls hide() and so doesn't call closeEvent(). I don't know exactly
what the best thing to do here is: override hide() in DialogView.h so it
calls Dialog::disconnect()? And actually, for the same reason, we have a
problem even with the OK button: That calls hide(), too. I guess just
changing these to close() would fix it, but I'm not sure why hide() was
used in the first place. Anyway, you'll know what to do.
There's another issue here, too, by the way, with other dialogs that
might use GuiDialog: Hitting "Escape" doesn't normally call
closeEvent(). This is a problem I had a while ago. To solve it, I put this:
connect(this, SIGNAL(rejected()), this, SLOT(cleanUp()));
into GuiCitation, and that eventually calls close(). It may be that we
should put something similar into GuiDialog that would make sure
Dialog::disconnect() gets called.
By the way, are there two dialog frameworks at the moment? One based
upon GuiDialog and one based upon DialogView? Where is this headed?
rh
