Application startup position & size

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

Hello,
I have a photon program that I save the x & y position of the window along
with the window extents to an ini file. Then when I startup I try and set
these settings but the window jumps to the saved x & y position and then
back to the 0,0 position.

I have turned off the auto-generated command line arguments in the startup
information window but this makes no difference. I’ve tried putting my
initialisation code as a Setup Function both in the pre-realize and
post-realize call backs, also in the window open and realized call backs
with no luck.

Here’s my call back code :-
PhWindowEvent_t we;
we.event_f = Ph_WM_MOVE;
we.rid = PtWidgetRid(ABW_base);
we.pos.x = setup.x;
we.pos.y = setup.y;
PtForwardWindowTaskEvent(PhGetConnectionid(), &we);

The above code works fine when I call it from my setup dialog but not in any
initialisation routines, I assume I’m calling it to early or something of
that nature ?

The resize and move flags are set for the window. I also have the problem
when I try and use the code below to resize the window I lose the window
frame and the size looks wrong.

PhWindowEvent_t we;
we.event_f = Ph_WM_RESIZE;
we.rid = PtWidgetRid(ABW_base);
we.size.w = setup.w;
we.size.h = setup.h;
PtForwardWindowTaskEvent(PhGetConnectionid(), &we);

I use PtWidgetExtent(ABW_base, &ext) to get the initial values for the width
and height, they tend to agree with the Phab W & H values (although they are
out by 1?).

I use PtGetAbsPosition(ABW_base, &x, &y) to get the absolute window
position, this again works but is out by the window frame size which is 5 in
the x and 21 in the y, will this offset always be consistent ?

Any suggestions or better function calls to do these operations would be
great.

TIA, Brett.

2

Brett Wilton <bdwilton@xtra.co.nz> wrote:

Hello,
I have a photon program that I save the x & y position of the window along
with the window extents to an ini file. Then when I startup I try and set
these settings but the window jumps to the saved x & y position and then
back to the 0,0 position.

I have turned off the auto-generated command line arguments in the startup
information window but this makes no difference. I’ve tried putting my
initialisation code as a Setup Function both in the pre-realize and
post-realize call backs, also in the window open and realized call backs
with no luck.

Here’s my call back code :-
…
PtForwardWindowTaskEvent(PhGetConnectionid(), &we);

The above code works fine when I call it from my setup dialog but not in any
initialisation routines, I assume I’m calling it to early or something of
that nature ?

Setting Pt_ARG_POS should be more reliable, especially in a setup or
initialization function. It tells the widget to do it for you, while
your code talks to the window manager without telling the widget, and
creates a chance that the widget might undo it the next time it talks to
pwm.

The resize and move flags are set for the window. I also have the problem
when I try and use the code below to resize the window I lose the window
frame and the size looks wrong.
…
PtForwardWindowTaskEvent(PhGetConnectionid(), &we);

Setting Pt_ARG_DIM should be more reliable (see above).

I use PtWidgetExtent(ABW_base, &ext) to get the initial values for the width
and height, they tend to agree with the Phab W & H values (although they are
out by 1?).

Are you sure they are?

The width of a rectangle is

rect.lr.x - rect.ul.x + 1

Maybe you’re forgetting to add the 1?

I use PtGetAbsPosition(ABW_base, &x, &y) to get the absolute window
position, this again works but is out by the window frame size which is 5 in
the x and 21 in the y, will this offset always be consistent ?

It should be always consistent with the size of the window frame. Use
PtWindowFrameSize() to obtain the frame size.

But getting the window’s Pt_ARG_POS is much simpler, and returns a
position that’s consistent with setting Pt_ARG_POS.

Any suggestions or better function calls to do these operations would be
great.

In general, if you’re working with widgets and there’s a widget API that
does what you want to do, it’s better to use it. If you use a
lower-level API instead, it may do things behind the widget’s back and
introduce an inconsistency between the state the widget thinks it’s in
and the state you have put it in, which may not always be completely
harmless.

3

Thank you all of your suggestions worked perfectly. Much appreciated.