Raw widget questions...

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

I have an application that I’m porting to QNXRTP… It opens a number of
windows, each containing a raw widget, a few buttons, and a few numeric
floats… I’ve got two questions that I’d really appreciate answers
for…

Firstly, how do I select which raw widget receives draw (Pg*) events? I
know that each raw widget has to have its own draw function (which it
does), but I’d like to be able to set up the raw widgets and change
multiple raw widgets without having to damage them to force a re-draw
(this has to do with the way the original code is set up… I really
don’t want to have to re-do it!).

Secondly, I’ve noticed that when moving a window over (only) the buttons
/ numerics, they automatically repair themselves. However, when I move
a window over both the buttons (or numerics) AND the raw widget, the
buttons / numerics aren’t re-drawn. I can include a “PtDrawWidget” call
in the raw draw function, but I was wondering if this was normal
behaviour (I do a PtSuperClassDraw within the raw drawing function as
well…)

Any answers greatly appreciated!

Robert Craig.

2

Robert Craig <rcraig@sympatico.ca> wrote:

I have an application that I’m porting to QNXRTP… It opens a number of
windows, each containing a raw widget, a few buttons, and a few numeric
floats… I’ve got two questions that I’d really appreciate answers
for…

Firstly, how do I select which raw widget receives draw (Pg*) events? I
know that each raw widget has to have its own draw function (which it
does), but I’d like to be able to set up the raw widgets and change
multiple raw widgets without having to damage them to force a re-draw
(this has to do with the way the original code is set up… I really
don’t want to have to re-do it!).

I’m not getting a clear picture of what you’re trying to do here,
so correct me if I make a wrong assumption, OK?

The thing about PtRaw widgets in Photon is that they allow you an
arena in which you generate your own drawing (using the Pg*()
functions), which are turned into draw events by the library.
Receiving draw events is more the sort of thing done by the
graphics drivers, which turn them into whatever sort of voodoo is
appropriate to get pixels on your CRT.

If what you’re after is a way for you to generate new drawings
inside the PtRaw widgets, then you should consider working with
whatever is triggering the change. If you’re getting periodic
timing from a PtTimer, it has a callback that you can use to poke
the appropriate PtRaw. Using a system timer via pulse and input
function? Same sort of deal. Hardware driven via a file
descriptor interface? Look at the docs for PtAppAddFd().

Secondly, I’ve noticed that when moving a window over (only) the buttons
/ numerics, they automatically repair themselves. However, when I move
a window over both the buttons (or numerics) AND the raw widget, the
buttons / numerics aren’t re-drawn.

Odd – does the raw widget overlap the other sort? Where are
they in the widget hierarchy? Which is closest to the user, the
button/numeric or the raw? (NB, the lower the widget is on the
widget hierarchy, the closer it is to the user.)

I can include a “PtDrawWidget” call
in the raw draw function, but I was wondering if this was normal
behaviour (I do a PtSuperClassDraw within the raw drawing function as
well…)

Hmmm. I’ve normally seen only Pg*() functions used, but I’ve
never done anything particularly dramatic. Mind you, I can’t
find PtDrawWidget() doc’ed in the 2.0 Photon library reference
anywhere. It doesn’t seem to be in the 1.14 docs, either.

I hope this is some help, at least… :slight_smile:


Norbert Black
QSSL Training Services

3

Sorry about that… It’s my poor terminology / explanation…

I’ll re-phrase the question…

If I have multiple PtRawWidgets that have been created, can I select which
widget will be drawn to with the Pg* functions… (e.g. I have 16 widgets and
I would like to draw a line in widget 2 and a circle in widget 15…). The
separate draw functions do take care of this but there’s a messy reason why
I’d like to be able to initialise everything before the raw draw functions
come in to play…


With regards to the non-redrawing of buttons / numerics, all of the widgets
(raw / buttons / numerics) have the same parent (the window in which they were
created). The raw widget does not overlay the buttons / numerics.
PtDrawWidget is a function that I picked out of a header file and isn’t
documented (:->>). Just playing around to try and get something to work…

Clear as mud?

Thanks!
Robert Craig.



Norbert Black wrote:

Robert Craig <> rcraig@sympatico.ca> > wrote:
I have an application that I’m porting to QNXRTP… It opens a number of
windows, each containing a raw widget, a few buttons, and a few numeric
floats… I’ve got two questions that I’d really appreciate answers
for…

Firstly, how do I select which raw widget receives draw (Pg*) events? I
know that each raw widget has to have its own draw function (which it
does), but I’d like to be able to set up the raw widgets and change
multiple raw widgets without having to damage them to force a re-draw
(this has to do with the way the original code is set up… I really
don’t want to have to re-do it!).

I’m not getting a clear picture of what you’re trying to do here,
so correct me if I make a wrong assumption, OK?

The thing about PtRaw widgets in Photon is that they allow you an
arena in which you generate your own drawing (using the Pg*()
functions), which are turned into draw events by the library.
Receiving draw events is more the sort of thing done by the
graphics drivers, which turn them into whatever sort of voodoo is
appropriate to get pixels on your CRT.

If what you’re after is a way for you to generate new drawings
inside the PtRaw widgets, then you should consider working with
whatever is triggering the change. If you’re getting periodic
timing from a PtTimer, it has a callback that you can use to poke
the appropriate PtRaw. Using a system timer via pulse and input
function? Same sort of deal. Hardware driven via a file
descriptor interface? Look at the docs for PtAppAddFd().

Secondly, I’ve noticed that when moving a window over (only) the buttons
/ numerics, they automatically repair themselves. However, when I move
a window over both the buttons (or numerics) AND the raw widget, the
buttons / numerics aren’t re-drawn.

Odd – does the raw widget overlap the other sort? Where are
they in the widget hierarchy? Which is closest to the user, the
button/numeric or the raw? (NB, the lower the widget is on the
widget hierarchy, the closer it is to the user.)

I can include a “PtDrawWidget” call
in the raw draw function, but I was wondering if this was normal
behaviour (I do a PtSuperClassDraw within the raw drawing function as
well…)

Hmmm. I’ve normally seen only Pg*() functions used, but I’ve
never done anything particularly dramatic. Mind you, I can’t
find PtDrawWidget() doc’ed in the 2.0 Photon library reference
anywhere. It doesn’t seem to be in the 1.14 docs, either.

I hope this is some help, at least… > :slight_smile:

Norbert Black
QSSL Training Services

4

Robert Craig <rcraig@sympatico.ca> wrote:

Sorry about that… It’s my poor terminology / explanation…

No problem.

I’ll re-phrase the question…

If I have multiple PtRawWidgets that have been created, can I select which
widget will be drawn to with the Pg* functions… (e.g. I have 16 widgets and
I would like to draw a line in widget 2 and a circle in widget 15…). The
separate draw functions do take care of this but there’s a messy reason why
I’d like to be able to initialise everything before the raw draw functions
come in to play…

OK, that we can do… :slight_smile:

The various Pg*() functions take a position argument to tell them
where in the x/y plane to draw the line/curve/pixel/etc. Figure
out where the origin of each of your PtRaw widgets is in absolute
coordinates, and store them in a bunch of globals. From there,
you can pluck out that offset, and the drawing will show up
overlaying the PtRaw. Thereafter, if the PtRaw is
damaged/moved/whatever, and a redraw is forced, then the raw
drawing function of the widget will take over and redraw. You’ll
want to keep a “template” of whatever it is that is supposed to
be drawn safe somewhere that gets updated each time you make
these “out of widget” modifications.

There may be synchronization/coordination issues if you’re trying
to replace the existing contents of the PtRaw with a completely
new one, rather than adding a bit more to an existing pattern.
For that situation, I’d bite the bullet and have the raw drawing
functions to all the work – much less fuss in the end, I’d
guess.


Secondly, I’ve noticed that when moving a window over (only) the buttons
/ numerics, they automatically repair themselves. However, when I move
a window over both the buttons (or numerics) AND the raw widget, the
buttons / numerics aren’t re-drawn.

Odd – does the raw widget overlap the other sort? Where are
they in the widget hierarchy? Which is closest to the user, the
button/numeric or the raw? (NB, the lower the widget is on the
widget hierarchy, the closer it is to the user.)

With regards to the non-redrawing of buttons / numerics, all of the widgets
(raw / buttons / numerics) have the same parent (the window in which they were
created). The raw widget does not overlay the buttons / numerics.

Wierd… :-/ Does this persist in a tiny little sample app? If
so, I’d suggest you start a separate thread with word “bug” in
the title, and hopefully someone from the Photon R&D group will
be along in a few moments to see what’s up. I know I’m at a loss
(not that that’s a new thing… :slight_smile: )

Clear as mud?

Even clearer!

I’ll look back in on the thread tomorrow if I get a chance. Let
us know how you get on.


Norbert Black
QSSL Training Services

5

Norbert Black wrote:

Robert Craig <> rcraig@sympatico.ca> > wrote:
Sorry about that… It’s my poor terminology / explanation…

No problem.

I’ll re-phrase the question…

If I have multiple PtRawWidgets that have been created, can I select which
widget will be drawn to with the Pg* functions… (e.g. I have 16 widgets and
I would like to draw a line in widget 2 and a circle in widget 15…). The
separate draw functions do take care of this but there’s a messy reason why
I’d like to be able to initialise everything before the raw draw functions
come in to play…

OK, that we can do… > :slight_smile:

The various Pg*() functions take a position argument to tell them
where in the x/y plane to draw the line/curve/pixel/etc. Figure
out where the origin of each of your PtRaw widgets is in absolute
coordinates, and store them in a bunch of globals. From there,
you can pluck out that offset, and the drawing will show up
overlaying the PtRaw. Thereafter, if the PtRaw is
damaged/moved/whatever, and a redraw is forced, then the raw
drawing function of the widget will take over and redraw. You’ll
want to keep a “template” of whatever it is that is supposed to
be drawn safe somewhere that gets updated each time you make
these “out of widget” modifications.

Ahhh… Cool. Hadn’t thought of that. Does this assume that all of the
raw widgets are in the same window (I’m guessing yes (?))? What if the
raw widgets are in separate windows?


There may be synchronization/coordination issues if you’re trying
to replace the existing contents of the PtRaw with a completely
new one, rather than adding a bit more to an existing pattern.
For that situation, I’d bite the bullet and have the raw drawing
functions to all the work – much less fuss in the end, I’d
guess.

Yeah. The tracking is all taken care of, there’s just an initial
display
problem in which I create each window / raw widget, draw axes and then
move
to the next window / widget. I then have to go back and put the data on
each raw widget in one go. If I don’t somehow switch widgets, all of
my line graphs end up in the same raw widget… (Ouch!) This is a port
of
routines that were used in QNX Windows where the window switching was
simple.



Secondly, I’ve noticed that when moving a window over (only) the buttons
/ numerics, they automatically repair themselves. However, when I move
a window over both the buttons (or numerics) AND the raw widget, the
buttons / numerics aren’t re-drawn.

Odd – does the raw widget overlap the other sort? Where are
they in the widget hierarchy? Which is closest to the user, the
button/numeric or the raw? (NB, the lower the widget is on the
widget hierarchy, the closer it is to the user.)

With regards to the non-redrawing of buttons / numerics, all of the widgets
(raw / buttons / numerics) have the same parent (the window in which they were
created). The raw widget does not overlay the buttons / numerics.

Wierd… :-/ Does this persist in a tiny little sample app? If
so, I’d suggest you start a separate thread with word “bug” in
the title, and hopefully someone from the Photon R&D group will
be along in a few moments to see what’s up. I know I’m at a loss
(not that that’s a new thing… > :slight_smile: > )

I strongly suspect an ummm… internal (to my application) feature. I
distilled
down the basic window creation and it works as it should. I’ll have to
dig through my stuff a bit more and see where I’ve messed things up. At
least
I now know that what the correct operation is!


Thanks for the help!
Robert.

6

Robert Craig <rcraig@sympatico.ca> wrote:

Norbert Black wrote:
If I have multiple PtRawWidgets that have been created, can I select which
widget will be drawn to with the Pg* functions… (e.g. I have 16 widgets and
[snip]

OK, that we can do… > :slight_smile:

The various Pg*() functions take a position argument to tell them
where in the x/y plane to draw the line/curve/pixel/etc. Figure
out where the origin of each of your PtRaw widgets is in absolute
coordinates, and store them in a bunch of globals.
[snip]



Ahhh… Cool. Hadn’t thought of that. Does this assume that all of the
raw widgets are in the same window (I’m guessing yes (?))? What if the
raw widgets are in separate windows?

No, the widgets can be anywhere in absolute Photon space –
separate widgets, separate parents, etc. When you do an
explicit Pg*() call, you’re really just scribbling on the inside
of the CRT. The raw widgets are there to let you make that
scribbling persist, but don’t care at all if you scribble over
top of them. That’s why I mentioned that you need to clue them
in to whatever “setup scribbling” you’ve done so that they can
take ownership of making it persistant later on.



There may be synchronization/coordination issues if you’re trying
to replace the existing contents of the PtRaw with a completely
new one, rather than adding a bit more to an existing pattern.
For that situation, I’d bite the bullet and have the raw drawing
functions to all the work – much less fuss in the end, I’d
guess.

Yeah. The tracking is all taken care of, there’s just an initial
display problem in which I create each window / raw widget,
draw axes and then move to the next window / widget. I then
have to go back and put the data on each raw widget in one go.
If I don’t somehow switch widgets, all of my line graphs end up
in the same raw widget… (Ouch!)

Your cup runneth over… :slight_smile:

This is a port of routines that were used in QNX Windows where
the window switching was simple.

Never got much practical experience with QNX Windows, so all I
can say is that the standard mantra in Tech. Support back in my
days on the phone was that “you’re going to save yourself time in
the long run by reimplementing your original GUI design using
Photon programming concepts under the covers, rather than try to
do a direct port”. This was (if memory serves) from David Gibbs,
who was at that point Tech. Support’s QNX Windows guru (among
other things).

Anyway, it looks like this particular port will get over this
particular hill without incident. :slight_smile: Have fun with the
remainder, OK?

Norbert Black
QSSL Training Services

7

Robert Craig <rcraig@sympatico.ca> wrote in message
news:3A53CD99.5F74BB94@sympatico.ca…

Norbert Black wrote:

Robert Craig <> rcraig@sympatico.ca> > wrote:
Sorry about that… It’s my poor terminology / explanation…

No problem.

I’ll re-phrase the question…

If I have multiple PtRawWidgets that have been created, can I select
which
widget will be drawn to with the Pg* functions… (e.g. I have 16
widgets and
I would like to draw a line in widget 2 and a circle in widget 15…).
The
separate draw functions do take care of this but there’s a messy
reason why
I’d like to be able to initialise everything before the raw draw
functions
come in to play…

OK, that we can do… > :slight_smile:

The various Pg*() functions take a position argument to tell them
where in the x/y plane to draw the line/curve/pixel/etc. Figure
out where the origin of each of your PtRaw widgets is in absolute
coordinates, and store them in a bunch of globals. From there,
you can pluck out that offset, and the drawing will show up
overlaying the PtRaw. Thereafter, if the PtRaw is
damaged/moved/whatever, and a redraw is forced, then the raw
drawing function of the widget will take over and redraw. You’ll
want to keep a “template” of whatever it is that is supposed to
be drawn safe somewhere that gets updated each time you make
these “out of widget” modifications.

Ahhh… Cool. Hadn’t thought of that. Does this assume that all of the
raw widgets are in the same window (I’m guessing yes (?))? What if the
raw widgets are in separate windows?

You will need to do a PgSetRegion (PtWidgetRid
(window_containing_raws_to_draw));
prior to drawing raw widgets in various windows from a single function.
All drawing will be relative to th upper left corner of the selected window
unless you call
PgSetTranslation() to change that.

There may be synchronization/coordination issues if you’re trying
to replace the existing contents of the PtRaw with a completely
new one, rather than adding a bit more to an existing pattern.
For that situation, I’d bite the bullet and have the raw drawing
functions to all the work – much less fuss in the end, I’d
guess.

Yeah. The tracking is all taken care of, there’s just an initial
display
problem in which I create each window / raw widget, draw axes and then
move
to the next window / widget. I then have to go back and put the data on
each raw widget in one go. If I don’t somehow switch widgets, all of
my line graphs end up in the same raw widget… (Ouch!) This is a port
of
routines that were used in QNX Windows where the window switching was
simple.




Secondly, I’ve noticed that when moving a window over (only) the
buttons
/ numerics, they automatically repair themselves. However, when I
move
a window over both the buttons (or numerics) AND the raw widget,
the
buttons / numerics aren’t re-drawn.

Looks like you are setting clipping in the raw draw func, but aren’t
clearing it, so
other widgets which draw after your raw ones are clipped out.
General rule, if you PtClipAdd() you must PtClipRemove() before returning.


Odd – does the raw widget overlap the other sort? Where are
they in the widget hierarchy? Which is closest to the user, the
button/numeric or the raw? (NB, the lower the widget is on the
widget hierarchy, the closer it is to the user.)

With regards to the non-redrawing of buttons / numerics, all of the
widgets
(raw / buttons / numerics) have the same parent (the window in which
they were
created). The raw widget does not overlay the buttons / numerics.

Wierd… :-/ Does this persist in a tiny little sample app? If
so, I’d suggest you start a separate thread with word “bug” in
the title, and hopefully someone from the Photon R&D group will
be along in a few moments to see what’s up. I know I’m at a loss
(not that that’s a new thing… > :slight_smile: > )


I strongly suspect an ummm… internal (to my application) feature. I
distilled
down the basic window creation and it works as it should. I’ll have to
dig through my stuff a bit more and see where I’ve messed things up. At
least
I now know that what the correct operation is!


Thanks for the help!
Robert.

8

Snip…

Ahhh… Cool. Hadn’t thought of that. Does this assume that all of the
raw widgets are in the same window (I’m guessing yes (?))? What if the
raw widgets are in separate windows?

You will need to do a PgSetRegion (PtWidgetRid
(window_containing_raws_to_draw));

That was the magic function.

Looks like you are setting clipping in the raw draw func, but aren’t
clearing it, so
other widgets which draw after your raw ones are clipped out.
General rule, if you PtClipAdd() you must PtClipRemove() before returning.

Yes. That’s exactly what I was doing. That’s the problem with porting
legacy code. Sometimes you forget what it does in the innards!

Looks like I’m now fully operational. Thanks for the help!
Robert Craig.