Sorry, that wasn't very clear. Let me re-state all of this.
Here was the original problem. Suppose you open the reference dialog,
click on a label name, and choose "Go to Label". That button then
changes to "Go back". Now you hit cancel and then re-open the dialog.
The button will still say "Go back" and, worse, if you choose another
label, you'll automatically be sent back. So the solution was to make
hitting Cancel call a new routine reset_dialog() that simply resets the
button to "Go to Label" and resets the tracking variable at_ref_ to
false. I also included a call to reset_dialog() in closeEvent(), so that
hitting the X in the upper right corner will reset the dialog as well.
So now the new problem: Hitting escape closes the dialog but does not
generate a closeEvent() and so the dialog does not get reset. This is
easy enough to solve:
connect(this, SIGNAL(rejected()), this, SLOT(reset_dialog()))
But now note that, in the same way, hitting escape, which does result in
the dialog being closed, does not result in slotClose() being called.
Nor, for that matter, would hitting the X result in slotClose() being
called. I'm guessing that this isn't a large problem, since there aren't
a ton of bug reports being filed about this. Nonetheless, insofar as I
understand the structure of this code, it seems like slotClose() should
be called whenever the dialog closes and not just when it's closed as a
result of the user hitting the cancel button. So the question was
basically whether we should have something like:
connect(this, SIGNAL(rejected()), form_, SLOT(slotClose()))
in pretty much every dialog, and whether closeEvent() shouldn't be
routinely re-implemented to call slotClose().
Richard
Abdelrazak Younes wrote:
> Richard Heck wrote:
>>
>> I've discovered a problem with my fix for bug 3461, at changeset
>> 17920. The problem there was that the dialog needed to be reset when
>> it was closed by hitting the cancel button. What I've realized is
>> that the same problem arises with the escape button: Hitting escape
>> does not trigger slotClose(), and it does not trigger a closeEvent(),
>> either. It's easy enough to deal with this by connecting rejected()
>> to something appropriate. The first question is to what it should be
>> connected, and whether it should be connected to slotClose(). The
>> second question is
>> whether this is a more general problem. Should ESC be connected to
>> slotClose() elsewhere?
>
> Isn't this QDialogView::slotRestore() you are looking for?
>
>> if so, should this be done in some more general manner?
>
> Maybe yes but don't forget that "Cancel" is usually for cancelling ;-)
> If you want to do that, that would be QDialogView::slotOK(). But I
> think it is better to restore the state before cancelling; and that is
> done by Dialog::RestoreButton().
>
> Quite convoluted...
>
> Abdel.
>
--
==================================================================
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==================================================================
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
