Rodney Dowdall <rdowdall@qnx.com> wrote:
RD > Hey Bill
RD > After reviewing the code, it appears that this should have worked the
RD > way that you had it before, without out changing the parent. Would it
RD > be possible for you to send me a small example of your setup? I want to
RD > see if I can reproduce the problem here and either explain why you were
RD > getting the behaviour your were getting, or submit a bug on it.
RD > Thanks,
RD > Rodney
RD > Bill Caroselli wrote:
Rodney Dowdall <> rdowdall@qnx.com> > wrote:
RD > Hello Bill
RD > I believe the problem is that hotkeys get delivered to the parent window
RD > and then distrusted from there. If the parent window is the one that is
RD > supposed to receive the hotkey, then it is probably consuming the event
RD > and therefore not passing it on to it’s child window. I can think of
RD > two ways around this:
RD > 1. In the dialogs initialization, PtReparent the dialog to Pt_NO_PARENT.
RD > 2. In your hotkey callback, check a flag that sees if the Dialog is up.
RD > If it is then don’t consume the hotkey.
RD > Thanks,
RD > Rodney
Thanks. PtReparentWidget() worked great.
I am satisfied with what is happeneing now. However, if you want to
recreate it just:
- create a base window,
- add a hotkey that calls CANCEL,
- add a button,
- on that button add a dialog callback that pops up a dialog,
- on that dialog add the same hotkey callback that calls CANCEL
Compile, link & run.
Click on the button to pop up the dialog.
Press your hotkey.
I would have expected only the dialog window to be dismissed, but
the base window is dismissed instead. If you use a CODE callback instead
of a CANCEL callback you can see that the dialog code callback never
gets called.
However, like I said, using the PtReparentWidget() works just fine for me.