rgheck wrote:
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().
Then either we call Dialog::hideView(), or we call close(), or we
implement hideEvent(). The difference of hide() is that the window is
that the dialog will be restored at its orginal position.
I don't know exactly what the best thing to do here is: override
hide() in DialogView.h so it calls Dialog::disconnect()?
No, I think we should just call close() instead of hide().
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.
I guess hide() was used for the reason above and it was working with the
former GuiDialog infrastructure, but with session support now, this is
not a problem, we should just call close(). One day, maybe in 1.7, we
should also probably destroy the dialog instead of just closing it.
There's another issue here, too, by the way, with other dialogs that
might use GuiDialog: Hitting "Escape" doesn't normally call closeEvent().
Hum, yes, I guess this call hideEvent()...
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.
I guess we have no other choice but implementing hideEvent().
By the way, are there two dialog frameworks at the moment? One based
upon GuiDialog and one based upon DialogView? Where is this headed?
Ideally? Or at least in my ideal world? To the eradication of
GuiDialog... :-)
Abdel.
