PtWindow doesn't resize

Using PhAB (in conjuntion w/Momentics Pro; QNX 6.3 SP1 - at least):
Build full-screen base window to operate (resize) in both 1024x768 and
1280x1024 graphics environments. Remaining area in base window is a
“workspace” for various windows displayed in response to a button
press originating in one of the toolbars. Base window and toolbars
(top, right, bottom edges) look good in both modes.

Here’s the problem: button-triggered callback PtWindows are not
filling the workspace when sized for 1024x768 but realized in
1280x1024 mode. It (the callback window) remains small but properly
positioned at the upper left hand corner. I think I have set the
appropriate resize flags.

I notice that PtWindow is a derived from PtDisJoint, a widget with no
parent. Does this explain why no “anchorage” flags are available in
Resources control panel? Also does this explain the lack of
cooperation between base window and this PtWindow callback module?
If so, can anyone suggest an alternative method to drive the
workspace display?

By the way, I’ve tried to force a larger PtWindow by changing its
Pt_ARG_DIM property. But I want to do it if and only if the
environment is 1280. A simple test would be to PtGetResource(…,
Pt_ARG_DIM, …) for the base window but when I make that call and
printf() dim.w and dim.h, I get ridiculously large numbers (e.g.
52172 x 2052). These look more like the entire display “carpet” than
the screen-filling base window size. What’s up with that?

rlb wrote:

Using PhAB (in conjuntion w/Momentics Pro; QNX 6.3 SP1 - at least):
Build full-screen base window to operate (resize) in both 1024x768 and
1280x1024 graphics environments. Remaining area in base window is a
“workspace” for various windows displayed in response to a button
press originating in one of the toolbars. Base window and toolbars
(top, right, bottom edges) look good in both modes.

If you’re putting your various “windows” inside the “workspace” in the
main window and expect them to stay there, it might be a good idea to
make them picture modules rather than separate windows. Windows are
more appropriate when you want to allow people to grab the frame of a
window and move it around or resize if without affecting other windows.
Windows are “disjoint”, in the sense that even though a child window
stays in front of its parent window, it’s not considered to be
inside it.

Here’s the problem: button-triggered callback PtWindows are not
filling the workspace when sized for 1024x768 but realized in
1280x1024 mode. It (the callback window) remains small but properly
positioned at the upper left hand corner. I think I have set the
appropriate resize flags.

The resize flags dictate a widget whether to resize itself to
accommodate its contents. It has nothing to do with resizing to the
size of the screen. If you want your window to be the size of the
screen, maximize it by setting Ph_WM_STATE_ISMAX in its state
(Pt_ARG_WINDOW_STATE).

I notice that PtWindow is a derived from PtDisJoint, a widget with no
parent. Does this explain why no “anchorage” flags are available in
Resources control panel? Also does this explain the lack of
cooperation between base window and this PtWindow callback module?

That’s correct: a disjoint widget cannot be anchored to its parent. If
you want it anchored, you don’t want a disjoint widget. In PhAB, you
can use a picture module to quickly fill a container in a window with
some pre-defined contents. But you’ll need to write some code to do that.

By the way, I’ve tried to force a larger PtWindow by changing its
Pt_ARG_DIM property. But I want to do it if and only if the
environment is 1280. A simple test would be to PtGetResource(…,
Pt_ARG_DIM, …) for the base window but when I make that call and
printf() dim.w and dim.h, I get ridiculously large numbers (e.g.
52172 x 2052). These look more like the entire display “carpet” than
the screen-filling base window size. What’s up with that?

Is there a chance that your code to get the dimensions is incorrect?
Getting resources can be tricky. In the case of the dimensions,
PtWidgetDim() is safer (and, incidentally, faster).

BTW Keep in mind that in general, a freshly created window may not know
its position or size yet, because they may be determined by the window
manager and delivered to the window in an event. Until you have started
to run the main loop and received the event, the widget’s idea of its
size or position may be out of sync with where the window manager has
really put it. This applies to windows that are created at the default
position or are created maximized, and it also happens while a person is
moving or resizing the window by dragging its frame.

Wojtech,

Thanks for clarifying the situation. I’ll look at both possibilities:

\

  1. using PtWidgetDim() for checking size of base window
  2. implementing a picture module even though “… you’ll need to write
    some code to do that.”

The latter comment of yours reflects the fact that, when configuring a
callback, the choices are code, dialog or window – no picture module
option.

Thanks again,
rlb

rlb wrote:

Thanks for clarifying the situation. I’ll look at both possibilities:

  1. using PtWidgetDim() for checking size of base window
  2. implementing a picture module even though “… you’ll need to write
    some code to do that.”

The latter comment of yours reflects the fact that, when configuring a
callback, the choices are code, dialog or window – no picture module
option.

Right. With dialog modules (as opposed to window modules) you could get
away without any code of your own – you’d just need to set up all the
dialogs to sit on top of each other. A dialog-type callback checks
whether its dialog window is already open, and if it is, it just brings
the window to the front.

With picture modules, you need to specify a container that the widgets
will be inserted into, and most likely you’ll need to remove any
previous contents first. This boils down to three lines of code:

PtClearWidget( ABW_the_container );
ApCreateModule( ABM_the_picture_module, ABW_the_container, NULL );
PtReRealizeWidget( ABW_the_container );

For more details, take a look at the ApCreateModule() page in the docs,
in particular the “Usage with picture modules” section.