Window's DIM has "priority" over COLOR

Clicking on an item (A, B, …, Z) in my_PtTree invokes the callback
which does the following:

  1. Discover that, for example, item X was clicked.
  2. Open the associated window via: w_X = ApCreateModule(ABM_X, …)
  3. Set a special color: PtSetResource(w_X, Pt_ARG_FILL_COLOR, 0)

During the ApCreateModule() phase, the pre-realization code for X,
set_size(), is called. It does this and, for now, only this:

  1. Set value of PhDim_t dim[2] for w_X according to size of base
    window (graphics mode dependent).
  2. Redefine window size: PtSetResource(w_X, Pt_ARG_DIM, &dim, 2)

Cool. Now we have an instance of X with right size and color. But
wait! ALL the windows built from clicking on my_PtTree have the same
size. So we could remove set_size() from all pre-realization
functions and put in the tree callback sections either before or
after #3.

No, this doesn’t adjust size of windows w_A, w_B, … I’m guessing
that window DIM is vital during the ApCreateModule() phase but COLOR
is a minor property that is handled during rendering. Yes? No?
Maybe?

Setting the size of a new window is tricky, because when the widget is
realized, pwm sends you an event back telling you the size and position (in
case you haven’t specified a position, or the window is created maximized);
when the library receives the event, it saves the position in the widget and
applies the size, wiping out any changes that your code might have made
between calling PtRealizeWidget() and PtMainLoop(). Setting the fill
colour, of course, does not involve any such negotiations with the window
manager.

Is there a reason why your modules need to be separate windows, rather than
picture modules used to populate a pane inside the base window?

“rlb” <robert.bottemiller@fmcti-dot-com.no-spam.invalid> wrote in message
news:dllbo3$9uk$1@inn.qnx.com

Clicking on an item (A, B, …, Z) in my_PtTree invokes the callback
which does the following:

  1. Discover that, for example, item X was clicked.
  2. Open the associated window via: w_X = ApCreateModule(ABM_X, …)
  3. Set a special color: PtSetResource(w_X, Pt_ARG_FILL_COLOR, 0)

During the ApCreateModule() phase, the pre-realization code for X,
set_size(), is called. It does this and, for now, only this:

  1. Set value of PhDim_t dim[2] for w_X according to size of base
    window (graphics mode dependent).
  2. Redefine window size: PtSetResource(w_X, Pt_ARG_DIM, &dim, 2)

Cool. Now we have an instance of X with right size and color. But
wait! ALL the windows built from clicking on my_PtTree have the same
size. So we could remove set_size() from all pre-realization
functions and put in the tree callback sections either before or
after #3.

No, this doesn’t adjust size of windows w_A, w_B, … I’m guessing
that window DIM is vital during the ApCreateModule() phase but COLOR
is a minor property that is handled during rendering. Yes? No?
Maybe?

Wojtek Lerch wrote:

[clipping 1st para.]

Is there a reason why your modules need to be separate windows, rather than
picture modules used to populate a pane inside the base window?
The base window has ordinary toolbars at the top and bottom edges. At

the right edge is a PtTree which presents a list of task options for the
user to choose from. The large, remaining area agrees in size with the
available windows – 30-some in number now and due to expand a bit in
the near future. At this time the windows are largely blank, waiting
for other team members to take on the detailed work.

At the start of designing this HMI I really wasn’t sure how best to
implement the presentation of these one-at-a-time “workspace areas.” I
had had a bad experience with dialogs much earlier but that was, I’m
sure, due more to my ignorance than anything else.

I suppose it’s not too late to define a pane in the workspace area and
re-cast the windows as picture modules. I’ve done some research into
picture modules and it’s not clear what advantage they offer from the
viewpoint of the developer or efficiency of the end product. I’d like
to hear about it if there are advantages.

Thanks, Wojtech, for the response.

“rlb” <> robert.bottemiller@fmcti-dot-com.no-spam.invalid> > wrote in message
news:dllbo3$9uk$> 1@inn.qnx.com> …

Clicking on an item (A, B, …, Z) in my_PtTree invokes the callback
which does the following:

  1. Discover that, for example, item X was clicked.
  2. Open the associated window via: w_X = ApCreateModule(ABM_X, …)
  3. Set a special color: PtSetResource(w_X, Pt_ARG_FILL_COLOR, 0)

During the ApCreateModule() phase, the pre-realization code for X,
set_size(), is called. It does this and, for now, only this:

  1. Set value of PhDim_t dim[2] for w_X according to size of base
    window (graphics mode dependent).
  2. Redefine window size: PtSetResource(w_X, Pt_ARG_DIM, &dim, 2)

Cool. Now we have an instance of X with right size and color. But
wait! ALL the windows built from clicking on my_PtTree have the same
size. So we could remove set_size() from all pre-realization
functions and put in the tree callback sections either before or
after #3.

No, this doesn’t adjust size of windows w_A, w_B, … I’m guessing
that window DIM is vital during the ApCreateModule() phase but COLOR
is a minor property that is handled during rendering. Yes? No?
Maybe?
\