I need a dialog to receive a guaranteed callback whenever
it is no longer visible (blocked by some other widget)
I’ve tried catching Pt_CB_LOST_FOCUS and sometimes the
callback is not called.
How can I do this?
Previously, Ken Schumm wrote in qdn.public.qnx4.photon:
I’ve tried catching Pt_CB_LOST_FOCUS and sometimes the
callback is not called.
To expound on this a bit, as I read the Photon docs,
Pt_CB_LOST_FOCUS seems to be intended for text widgets
only. In our case, I have tried to attach it to a
dialog module. On my desktop it appears to work
flawlessly, but on our target it is not always called
when the dialog is covered.
The target does not use pwm, but if pwm was required
it would seem that the lost focus callback would never
get called. Instead, it is called maybe 50% of the
time when the dialog is covered.
Curious.
Hi Ken,
I have skopen to one of the developers and here is the info he passed on to me:
Hope this helps
Regards
Brenda
Ken Schumm <kwschumm@qsolv.com> wrote:
Previously, Ken Schumm wrote in qdn.public.qnx4.photon:
I’ve tried catching Pt_CB_LOST_FOCUS and sometimes the
callback is not called.
To expound on this a bit, as I read the Photon docs,
Pt_CB_LOST_FOCUS seems to be intended for text widgets
only. In our case, I have tried to attach it to a
dialog module. On my desktop it appears to work
flawlessly, but on our target it is not always called
when the dialog is covered.
The Pt_CB_LOST_FOCUS is not restricted to text widgets only, but its
main purpose is to keep track of focus within a window. Most of this
stuff is handled internally within the library – neither Photon now pwm
knows about widgets and focus.
The target does not use pwm, but if pwm was required
it would seem that the lost focus callback would never
get called. Instead, it is called maybe 50% of the
time when the dialog is covered.
What happens when a window is losing focus to another window, depends on
whether you’re running pwm. The window manager sends a special event to
the window to notify it that it has lost focus; the library responds to
that event by invoking LOST_FOCUS callbacks of any widgets involved.
Without a window manager, there’s no concept of focus. Key events go to
whatever region the cursor points to, and you don’t get the window
manager events that tell you when you lose focus. If windows knew
whether a window manager is running or not, they could use boundary
events instead, but they don’t.
Curious.
Thanks, Brenda, that is good information.
So my original question remains.
How can my app know when a dialog is visibly blocked
without running pwm?
Previously, Gui Group wrote in qdn.public.qnx4.photon:
Hi Ken,
I have skopen to one of the developers and here is the info he passed on to me:
Hope this helps
Regards
Brenda
Ken Schumm <> kwschumm@qsolv.com> > wrote:
Previously, Ken Schumm wrote in qdn.public.qnx4.photon:I’ve tried catching Pt_CB_LOST_FOCUS and sometimes the
callback is not called.
To expound on this a bit, as I read the Photon docs,
Pt_CB_LOST_FOCUS seems to be intended for text widgets
only. In our case, I have tried to attach it to a
dialog module. On my desktop it appears to work
flawlessly, but on our target it is not always called
when the dialog is covered.The Pt_CB_LOST_FOCUS is not restricted to text widgets only, but its
main purpose is to keep track of focus within a window. Most of this
stuff is handled internally within the library – neither Photon now pwm
knows about widgets and focus.The target does not use pwm, but if pwm was required
it would seem that the lost focus callback would never
get called. Instead, it is called maybe 50% of the
time when the dialog is covered.What happens when a window is losing focus to another window, depends on
whether you’re running pwm. The window manager sends a special event to
the window to notify it that it has lost focus; the library responds to
that event by invoking LOST_FOCUS callbacks of any widgets involved.Without a window manager, there’s no concept of focus. Key events go to
whatever region the cursor points to, and you don’t get the window
manager events that tell you when you lose focus. If windows knew
whether a window manager is running or not, they could use boundary
events instead, but they don’t.Curious.
Previously, Ken Schumm wrote in qdn.public.qnx4.photon:
Thanks, Brenda, that is good information.
So my original question remains.
How can my app know when a dialog is visibly blocked
without running pwm?
ping
[…]
Hi Ken,
One possible way is to use a timer to periodically check if the dialog
is covered using PtWidgetVisibleExtent(). If the function returns zero then
the widget( in your case the dialog) is completely covered.
Regards
Brenda
Ken Schumm <kwschumm@qsolv.com> wrote:
Previously, Ken Schumm wrote in qdn.public.qnx4.photon:
Thanks, Brenda, that is good information.So my original question remains.
How can my app know when a dialog is visibly blocked
without running pwm?ping
[…]
That might work, but … YUCK, polling.
If that’s the only way I’ll redesign the way the gui works.
Thanks,
Ken
Previously, Gui Group wrote in qdn.public.qnx4.photon:
Hi Ken,
One possible way is to use a timer to periodically check if the dialog
is covered using PtWidgetVisibleExtent(). If the function returns zero then
the widget( in your case the dialog) is completely covered.Regards
Brenda