Forcing widget to be in front of all others

QNX Newsgroups (Archives) qdn.public.qnx4.photon
1

Hi-

This should be an easy one…

I have a PtBasic widget that I’m using to detect button presses without consuming the events. The idea is to use this to implement an automatic logout feature for my application. If no button presses occur within a certain amount of time, the application changes its state. The widget is invisible and lies in front of the application.

It almost works. The problem is that when the user brings up a PtWindow (belonging to the application), the window appears in front of the widget and I’m unable to detect button events in that region. Is there any way to force a specific widget to always be in front?

Most of the PtBasic widget’s parameters are defined with PhAB. Here is the code I’m using to set the position of the widget in event space:


nargs= 0;
PtSetArg( &args[nargs++], Pt_ARG_REGION_PARENT, Ph_ROOT_RID, 0 );
PtSetArg( &args[nargs++], Pt_ARG_REGION_INFRONT, Ph_DEV_RID, 0 );
PtSetArg( &args[nargs++], Pt_ARG_REGION_FIELDS,
Ph_REGION_IN_FRONT | Ph_REGION_PARENT,
Ph_REGION_IN_FRONT | Ph_REGION_PARENT );
PtSetResources( ABW_base_overlay, nargs, args );
PtReRealizeWidget( ABW_base_overlay ); // Probably unnecessary.



Any thoughts?

TIA,

  • Pete
2

So if I understand correctly, you have a big invisible PtBasic widget that
convers the whole window, so it will recognize all clicks in your window.

It almost works. The problem is that when the user brings up a PtWindow
(belonging to the application),

So why don’t you do the same for this PtWindow (using a PtBasic)

Markus


the window appears in front of the widget and I’m unable to detect button
events in that region. Is there any way to force a specific widget to
always be in front?

Most of the PtBasic widget’s parameters are defined with PhAB. Here is
the code I’m using to set the position of the widget in event space:


nargs= 0;
PtSetArg( &args[nargs++], Pt_ARG_REGION_PARENT, Ph_ROOT_RID, 0 );
PtSetArg( &args[nargs++], Pt_ARG_REGION_INFRONT, Ph_DEV_RID, 0 );
PtSetArg( &args[nargs++], Pt_ARG_REGION_FIELDS,
Ph_REGION_IN_FRONT | Ph_REGION_PARENT,
Ph_REGION_IN_FRONT | Ph_REGION_PARENT );
PtSetResources( ABW_base_overlay, nargs, args );
PtReRealizeWidget( ABW_base_overlay ); // Probably
unnecessary.



Any thoughts?

TIA,

  • Pete
3

Previously, Markus Loffler wrote in qdn.public.qnx4.photon:

So if I understand correctly, you have a big invisible PtBasic widget that
convers the whole window, so it will recognize all clicks in your window.

Exactly.

It almost works. The problem is that when the user brings up a PtWindow
(belonging to the application),
So why don’t you do the same for this PtWindow (using a PtBasic)

Because I have over 22 pop-up windows in the application. It would be a real hassle to modify them all.

  • Pete
4

Pete DiMarco <peted.NOSPAM@nospam.ifsreg.com> wrote:
: Previously, Markus Loffler wrote in qdn.public.qnx4.photon:
:> So if I understand correctly, you have a big invisible PtBasic widget that
:> convers the whole window, so it will recognize all clicks in your window.

: Exactly.

:> > It almost works. The problem is that when the user brings up a PtWindow
:> (belonging to the application),
:> So why don’t you do the same for this PtWindow (using a PtBasic)

: Because I have over 22 pop-up windows in the application.
: It would be a real hassle to modify them all.


My first thought was I have done this with a PtRegion widget and it worked
fine. I then realised in the particular application I am thinking about,
we were not running a window manager. pwm may very well mess with the
ordering or the regions. I wouldn’t have thought so, but since you are
already making your region right behind the device region, it appears to
be the problem.

There is an event defined which would be just want you want (Ph_EV_COVERED)
but unfortunately, the docs says it is not implimented yet. Otherwise you
could make yourself sensitive to that even and force yourself to the front
again if anyone tries to cover you.

You may be able to make yourself sensitive to the Ph_EV_WM events and use
that as notification that the window manager has moved someone in front of
you (and change yourself back to the front).

Rick…

Rick Duff Internet: rick@astra.mb.ca
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL: http://www.astra.mb.ca
+1 (204) 987-7475 Fax: +1 (204) 987-7479

5

Previously, rick@astra.mb.ca wrote in qdn.public.qnx4.photon:

Pete DiMarco <> peted.NOSPAM@nospam.ifsreg.com> > wrote:
: Previously, Markus Loffler wrote in qdn.public.qnx4.photon:
:> So if I understand correctly, you have a big invisible PtBasic widget that
:> convers the whole window, so it will recognize all clicks in your window.

: Exactly.

:> > It almost works. The problem is that when the user brings up a PtWindow
:> (belonging to the application),
:> So why don’t you do the same for this PtWindow (using a PtBasic)

: Because I have over 22 pop-up windows in the application.
: It would be a real hassle to modify them all.


My first thought was I have done this with a PtRegion widget and it worked
fine. I then realised in the particular application I am thinking about,
we were not running a window manager. pwm may very well mess with the
ordering or the regions. I wouldn’t have thought so, but since you are
already making your region right behind the device region, it appears to
be the problem.

As it turns out, we’re not using pdm or pwm on our target… but they are running on my development system. I’ll try experimenting without them running and see if there is a difference.

  • Pete
6

Hi Folks-

Here’s a quick summary of the problem I’m having:

I’m trying to use a transparent widget in front of my application to detect all button-press events. I want to use this information to control a screensaver and to automatically log users out of my application. (I’m not running pwm on the target.) Unfortunately, every time the application creates a pop-up window, the window appears in front of the transparent widget.


Previously, rick@astra.mb.ca wrote in qdn.public.qnx4.photon:

Pete DiMarco <> peted.NOSPAM@nospam.ifsreg.com> > wrote:
: Previously, Markus Loffler wrote in qdn.public.qnx4.photon:
:> So if I understand correctly, you have a big invisible PtBasic widget that
:> convers the whole window, so it will recognize all clicks in your window.

: Exactly.

:> > It almost works. The problem is that when the user brings up a PtWindow
:> (belonging to the application),
:> So why don’t you do the same for this PtWindow (using a PtBasic)

: Because I have over 22 pop-up windows in the application.
: It would be a real hassle to modify them all.


My first thought was I have done this with a PtRegion widget and it worked
fine. I then realised in the particular application I am thinking about,
we were not running a window manager. pwm may very well mess with the
ordering or the regions. I wouldn’t have thought so, but since you are
already making your region right behind the device region, it appears to
be the problem.

I’ve finally gotten around to changing my screensaver/login timeout code. I’m now using a transparent PtRegion to detect button events. Unfortunately, I’m still having problems with pop-up windows. Here’s my code:

area.pos.x= 0;
area.pos.y= 0;
area.size.w= 640;
area.size.h= 480;
PtSetArg( &args[nargs++], Pt_ARG_AREA, &area, 0 );

PtSetArg( &args[nargs++], Pt_ARG_FILL_COLOR, Pg_TRANSPARENT, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_PARENT, 0, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_INPUT_GROUP,
cbinfo->event->input_group, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_SENSE, ~0,
Ph_EV_BUT_PRESS | Ph_EV_BUT_RELEASE );

PtSetArg( &args[nargs++], Pt_ARG_REGION_INFRONT, Ph_DEV_RID, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_FLAGS, ~0, Ph_FORCE_FRONT );

PtSetArg( &args[nargs++], Pt_ARG_REGION_OPAQUE, ~0,
Ph_EV_PTR_ALL | Ph_EV_EXPOSE );

PtSetArg( &args[nargs++], Pt_ARG_REGION_FIELDS, ~0,
Ph_REGION_ORIGIN | Ph_REGION_RECT | Ph_REGION_EV_SENSE
| Ph_REGION_EV_OPAQUE | Ph_REGION_PARENT | Ph_REGION_FLAGS );

PtSetParentWidget( NULL );
Base_Region_Wgt= PtCreateWidget( PtRegion, NULL, nargs, args );
PtSetParentWidget( ABW_base );

PtAddEventHandler( Base_Region_Wgt, Ph_EV_BUT_PRESS, base_region_cb, NULL );



Anybody see what I’m doing wrong?

TIA,

  • Pete
7

Hi-

Could somebody at QSSL take a look at the code segment below and tell me what I’m doing wrong (or if I’m trying to do something that can’t be done)? My boss is getting impatient waiting for me to do an alpha release of our app. :slight_smile:

TIA,

  • Pete


    Previously, Pete DiMarco wrote in qdn.public.qnx4.photon:

Hi Folks-

Here’s a quick summary of the problem I’m having:

I’m trying to use a transparent widget in front of my application to detect all button-press events. I want to use this information to control a screensaver and to automatically log users out of my application. (I’m not running pwm on the target.) Unfortunately, every time the application creates a pop-up window, the window appears in front of the transparent widget.

I’ve finally gotten around to changing my screensaver/login timeout code. I’m now using a transparent PtRegion to detect button events. Unfortunately, I’m still having problems with pop-up windows. Here’s my code:

area.pos.x= 0;
area.pos.y= 0;
area.size.w= 640;
area.size.h= 480;
PtSetArg( &args[nargs++], Pt_ARG_AREA, &area, 0 );

PtSetArg( &args[nargs++], Pt_ARG_FILL_COLOR, Pg_TRANSPARENT, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_PARENT, 0, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_INPUT_GROUP,
cbinfo->event->input_group, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_SENSE, ~0,
Ph_EV_BUT_PRESS | Ph_EV_BUT_RELEASE );

PtSetArg( &args[nargs++], Pt_ARG_REGION_INFRONT, Ph_DEV_RID, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_FLAGS, ~0, Ph_FORCE_FRONT );

PtSetArg( &args[nargs++], Pt_ARG_REGION_OPAQUE, ~0,
Ph_EV_PTR_ALL | Ph_EV_EXPOSE );

PtSetArg( &args[nargs++], Pt_ARG_REGION_FIELDS, ~0,
Ph_REGION_ORIGIN | Ph_REGION_RECT | Ph_REGION_EV_SENSE
| Ph_REGION_EV_OPAQUE | Ph_REGION_PARENT | Ph_REGION_FLAGS );

PtSetParentWidget( NULL );
Base_Region_Wgt= PtCreateWidget( PtRegion, NULL, nargs, args );
PtSetParentWidget( ABW_base );

PtAddEventHandler( Base_Region_Wgt, Ph_EV_BUT_PRESS, base_region_cb, NULL );



Anybody see what I’m doing wrong?

TIA,

  • Pete
8

Pete DiMarco <peted.NOSPAM@nospam.ifsreg.com> wrote:

Could somebody at QSSL take a look at the code segment below and tell me what I’m doing wrong (or if I’m trying to do something that can’t be done)? My boss is getting impatient waiting for me to do an alpha release of our app. > :slight_smile:

Sorry for the delay. I had some techical problems posting to the
newsgroups lately…

There are a few minor problems with your code but I don’t think any of
them should prevent it from working:

Setting both Pt_ARG_REGION_INFRONT and Pt_ARG_REGION_PARENT is
redundant (but harmless unless they conflict). In your case,
Pt_ARG_REGION_INFRONT will be ignored anyway because you’re not
setting the Ph_REGION_IN_FRONT flag. (BTW Remember that if you put
your region behind a non-force-front region by setting
Pt_ARG_REGION_INFRONT, the Ph_FORCE_FRONT flag will automatically be
cleared.)

Similarly, you’re setting Pt_ARG_REGION_INPUT_GROUP but not
Ph_REGION_INPUT_GROUP. But that’s OK – I don’t see a good reason
for you to set Pt_ARG_REGION_INPUT_GROUP anyway…

There is one piece of the puzzle still missing: how do you create your
pop-up windows?

Previously, Pete DiMarco wrote in qdn.public.qnx4.photon:
Hi Folks-

Here’s a quick summary of the problem I’m having:

I’m trying to use a transparent widget in front of my application to detect all button-press events. I want to use this information to control a screensaver and to automatically log users out of my application. (I’m not running pwm on the target.) Unfortunately, every time the application creates a pop-up window, the window appears in front of the transparent widget.

I’ve finally gotten around to changing my screensaver/login timeout code. I’m now using a transparent PtRegion to detect button events. Unfortunately, I’m still having problems with pop-up windows. Here’s my code:

area.pos.x= 0;
area.pos.y= 0;
area.size.w= 640;
area.size.h= 480;
PtSetArg( &args[nargs++], Pt_ARG_AREA, &area, 0 );

PtSetArg( &args[nargs++], Pt_ARG_FILL_COLOR, Pg_TRANSPARENT, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_PARENT, 0, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_INPUT_GROUP,
cbinfo->event->input_group, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_SENSE, ~0,
Ph_EV_BUT_PRESS | Ph_EV_BUT_RELEASE );

PtSetArg( &args[nargs++], Pt_ARG_REGION_INFRONT, Ph_DEV_RID, 0 );

PtSetArg( &args[nargs++], Pt_ARG_REGION_FLAGS, ~0, Ph_FORCE_FRONT );

PtSetArg( &args[nargs++], Pt_ARG_REGION_OPAQUE, ~0,
Ph_EV_PTR_ALL | Ph_EV_EXPOSE );

PtSetArg( &args[nargs++], Pt_ARG_REGION_FIELDS, ~0,
Ph_REGION_ORIGIN | Ph_REGION_RECT | Ph_REGION_EV_SENSE
| Ph_REGION_EV_OPAQUE | Ph_REGION_PARENT | Ph_REGION_FLAGS );

PtSetParentWidget( NULL );
Base_Region_Wgt= PtCreateWidget( PtRegion, NULL, nargs, args );
PtSetParentWidget( ABW_base );

PtAddEventHandler( Base_Region_Wgt, Ph_EV_BUT_PRESS, base_region_cb, NULL );



Anybody see what I’m doing wrong?

TIA,

  • Pete

–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.

9

Previously, Wojtek Lerch wrote in qdn.public.qnx4.photon:

Pete DiMarco <> peted.NOSPAM@nospam.ifsreg.com> > wrote:

Could somebody at QSSL take a look at the code segment below and tell me what I’m doing wrong (or if I’m trying to do something that can’t be done)? My boss is getting impatient waiting for me to do an alpha release of our app. > :slight_smile:

Sorry for the delay. I had some techical problems posting to the
newsgroups lately…

There are a few minor problems with your code but I don’t think any of
them should prevent it from working:

Setting both Pt_ARG_REGION_INFRONT and Pt_ARG_REGION_PARENT is
redundant (but harmless unless they conflict). In your case,
Pt_ARG_REGION_INFRONT will be ignored anyway because you’re not
setting the Ph_REGION_IN_FRONT flag. (BTW Remember that if you put
your region behind a non-force-front region by setting
Pt_ARG_REGION_INFRONT, the Ph_FORCE_FRONT flag will automatically be
cleared.)

Similarly, you’re setting Pt_ARG_REGION_INPUT_GROUP but not
Ph_REGION_INPUT_GROUP. But that’s OK – I don’t see a good reason
for you to set Pt_ARG_REGION_INPUT_GROUP anyway…

There is one piece of the puzzle still missing: how do you create your
pop-up windows?

They’re all dialogs. When I create them from code I use ApCreateModule(), but most are handled through PhAB.

\

  • Pete
10

Pete DiMarco <peted.NOSPAM@nospam.ifsreg.com> wrote:

Previously, Wojtek Lerch wrote in qdn.public.qnx4.photon:
…
There is one piece of the puzzle still missing: how do you create your
pop-up windows?

They’re all dialogs. When I create them from code I use ApCreateModule(), but most are handled through PhAB.

Are you setting the Ph_WM_FFRONT flag in their Pt_ARG_WINDOW_MANAGED_FLAGS?

–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.

11

Previously, Wojtek Lerch wrote in qdn.public.qnx4.photon:

Pete DiMarco <> peted.NOSPAM@nospam.ifsreg.com> > wrote:
Previously, Wojtek Lerch wrote in qdn.public.qnx4.photon:
…
There is one piece of the puzzle still missing: how do you create your
pop-up windows?

They’re all dialogs. When I create them from code I use ApCreateModule(), but most are handled through PhAB.

Are you setting the Ph_WM_FFRONT flag in their Pt_ARG_WINDOW_MANAGED_FLAGS?

I’ve cleared all the flags in Pt_ARG_WINDOW_MANAGED_FLAGS, Pt_ARG_WINDOW_RENDER_FLAGS, and Pt_ARG_WINDOW_NOTIFY_FLAGS. I assumed they wouldn’t have any effect since I’m not running pwm. In retrospect, I could probably run pwm on our target (it’s going to have more RAM than we originally planned)… assuming pwm doesn’t slow things down on our x386…

  • Pete
12

Pete DiMarco <peted.NOSPAM@nospam.ifsreg.com> wrote:

Previously, Wojtek Lerch wrote in qdn.public.qnx4.photon:
Pete DiMarco <> peted.NOSPAM@nospam.ifsreg.com> > wrote:
Previously, Wojtek Lerch wrote in qdn.public.qnx4.photon:
…
There is one piece of the puzzle still missing: how do you create your
pop-up windows?

They’re all dialogs. When I create them from code I use ApCreateModule(), but most are handled through PhAB.

Are you setting the Ph_WM_FFRONT flag in their Pt_ARG_WINDOW_MANAGED_FLAGS?

I’ve cleared all the flags in Pt_ARG_WINDOW_MANAGED_FLAGS, Pt_ARG_WINDOW_RENDER_FLAGS, and Pt_ARG_WINDOW_NOTIFY_FLAGS. I assumed they wouldn’t have any effect since I’m not running pwm. In retrospect, I could probably run pwm on our target (it’s going to have more RAM than we originally planned)… assuming pwm doesn’t slow things down on our x386…

In that case, all the simple tests I’ve tried failed to reproduce your
problem. Could you put together a simple application that demonstrates
it, and email it to me?

–
Wojtek Lerch (wojtek@qnx.com) QNX Software Systems Ltd.

13

Hi-

Previously, Wojtek Lerch wrote in qdn.public.qnx4.photon:

In that case, all the simple tests I’ve tried failed to reproduce your
problem. Could you put together a simple application that demonstrates
it, and email it to me?

While in the process of creating the test program I was able to fix the bug. :sunglasses: It seems there was an odd interaction between some of the widgets in my app. Also, I had some flags set incorrectly.

Thanks anyway!

  • Pete


    “All’s well that ends.”