PtTrend question & bug report

bridged with qdn.public.qnxrtp.photon
Bill Caroselli

PtTrend question & bug report

Post by Bill Caroselli » Wed Sep 17, 2003 4:46 pm

What is the intended use of length on the PtTrend's Pt_ARG_TREND_DATA
resource?

If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.

Also, there is a buglet in PhAB's display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.

Wojtek Lerch

Re: PtTrend question & bug report

Post by Wojtek Lerch » Wed Sep 17, 2003 6:25 pm

Bill Caroselli <qtps@earthlink.net> wrote:
What is the intended use of length on the PtTrend's Pt_ARG_TREND_DATA
resource?

If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.
Why? The general rule for array resources is that the length is the
number of elements in the array you're providing. The resource is an
array of short. The length is the number of shorts in the array.

Do you think the following paragraph in the docs needs improvement:

If the widget is displaying multiple trends, the data buffer must
contain the new data for each trend: data for the first trend is
followed by data for the second trend, and so on. The application
must set len to be the total number of points being added, not the
number of points per trend.

Also, there is a buglet in PhAB's display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.
This is just one of symptoms of the fact that neither PhAB nor the
widget library has a general way to distinguish between signed and
unsigned resources. The problem does not exist when you get a resource
using a pointer -- it's your responsibility to make sure that the
pointer has the correct type. But if get a resource without using a
pointer, it always comes back as a signed long, and if it's a signed
char or short, it doesn't get correctly sign extended.

I believe the PhAB folks are working on a fix for this, but I'm not sure
when it'll actually be released.

Bill Caroselli

Re: PtTrend question & bug report

Post by Bill Caroselli » Wed Sep 17, 2003 7:31 pm

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > Bill Caroselli <qtps@earthlink.net> wrote:
What is the intended use of length on the PtTrend's Pt_ARG_TREND_DATA
resource?

If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.
WL > Why? The general rule for array resources is that the length is the
WL > number of elements in the array you're providing. The resource is an
WL > array of short. The length is the number of shorts in the array.

WL > Do you think the following paragraph in the docs needs improvement:

WL > If the widget is displaying multiple trends, the data buffer must
WL > contain the new data for each trend: data for the first trend is
WL > followed by data for the second trend, and so on. The application
WL > must set len to be the total number of points being added, not the
WL > number of points per trend.

I guess what threw me here was that if I added a point at a time when
there was two trends, nothing ever changed ever. I would have expected
it to update the first trend and leave the second trend alone. Instead
it just ignored the new data.

Also, there is a buglet in PhAB's display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.
WL > This is just one of symptoms of the fact that neither PhAB nor the
WL > widget library has a general way to distinguish between signed and
WL > unsigned resources. The problem does not exist when you get a resource
WL > using a pointer -- it's your responsibility to make sure that the
WL > pointer has the correct type. But if get a resource without using a
WL > pointer, it always comes back as a signed long, and if it's a signed
WL > char or short, it doesn't get correctly sign extended.

WL > I believe the PhAB folks are working on a fix for this, but I'm not sure
WL > when it'll actually be released.

I've never actually used a PtNumeric. I didn't realize that it
couldn't be used with unsigned data types. That should be spelled out
with *BIG RED LETTERS!*

Wojtek Lerch

Re: PtTrend question & bug report

Post by Wojtek Lerch » Thu Sep 18, 2003 1:49 am

"Bill Caroselli" <qtps@earthlink.net> wrote in message
news:bkacq7$7kv$1@inn.qnx.com...
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:
WL > Bill Caroselli <qtps@earthlink.net> wrote:
What is the intended use of length on the PtTrend's Pt_ARG_TREND_DATA
resource?

If I have two trend lines and I want to plot 1 new sample for each
trend line, it is apparently necessary to set this to 2. I was
expecting to use 1.

WL > Why? The general rule for array resources is that the length is the
WL > number of elements in the array you're providing. The resource is an
WL > array of short. The length is the number of shorts in the array.

WL > Do you think the following paragraph in the docs needs improvement:

WL > If the widget is displaying multiple trends, the data buffer must
WL > contain the new data for each trend: data for the first trend is
WL > followed by data for the second trend, and so on. The
application
WL > must set len to be the total number of points being added, not
the
WL > number of points per trend.

I guess what threw me here was that if I added a point at a time when
there was two trends, nothing ever changed ever. I would have expected
it to update the first trend and leave the second trend alone. Instead
it just ignored the new data.
You mean you would expect that you do it repeatedly, the first trend would
move and the second one would stay in place? No, it doesn't work that
way...
Also, there is a buglet in PhAB's display of Min Value. If I enter a
negitive value it is redisplayed as a unsigned short. I am running
6.2.1B.

WL > This is just one of symptoms of the fact that neither PhAB nor the
WL > widget library has a general way to distinguish between signed and
WL > unsigned resources. The problem does not exist when you get a
resource
WL > using a pointer -- it's your responsibility to make sure that the
WL > pointer has the correct type. But if get a resource without using a
WL > pointer, it always comes back as a signed long, and if it's a signed
WL > char or short, it doesn't get correctly sign extended.

WL > I believe the PhAB folks are working on a fix for this, but I'm not
sure
WL > when it'll actually be released.

I've never actually used a PtNumeric. I didn't realize that it
couldn't be used with unsigned data types. That should be spelled out
with *BIG RED LETTERS!*
No, it's not a PtNumeric problem -- it's the way PhAB reads the Min Value
back from PtTrend. Since it's using the "no pointer" method,
PtGetResources() returns the value in the long "value" field of a PtArg_t.
It does that by copying the 16 bits of the short into the low 16 bits of the
long, and since it has no idea whether the short is signed or not, it always
sets the other 16 bits of the long to zero. Perhaps it would have been a
better idea to always sign-extend it -- if we have to return some values
incorrectly, it's probably better to break very big unsigned shorts than all
the negative signed shorts. But I'm not sure if changing it *now* would be
such a great idea...

Bill Caroselli

Re: PtTrend question & bug report

Post by Bill Caroselli » Thu Sep 18, 2003 1:09 pm

Wojtek Lerch <wojtek_l@ottawa.com> wrote:
WL > "Bill Caroselli" <qtps@earthlink.net> wrote in message
I've never actually used a PtNumeric. I didn't realize that it
couldn't be used with unsigned data types. That should be spelled out
with *BIG RED LETTERS!*
WL > No, it's not a PtNumeric problem -- it's the way PhAB reads the Min Value
WL > back from PtTrend. Since it's using the "no pointer" method,
WL > PtGetResources() returns the value in the long "value" field of a PtArg_t.
WL > It does that by copying the 16 bits of the short into the low 16 bits of the
WL > long, and since it has no idea whether the short is signed or not, it always
WL > sets the other 16 bits of the long to zero. Perhaps it would have been a
WL > better idea to always sign-extend it -- if we have to return some values
WL > incorrectly, it's probably better to break very big unsigned shorts than all
WL > the negative signed shorts. But I'm not sure if changing it *now* would be
WL > such a great idea...


AAAHHHHH!!!!!

I understand, and agree, don't change logic like that this late in
the game.

But the good news is this, if the application (and that includes PhAB)
knows that the value being returned is a short, then it just has to:
long value;
short s_value;
s_value = (value & 0xffff);
The sign bit from the original short should be preserved, right?

Please write that up as a bug fix. There is nothing more annoying than
to type in one number have it echo back something entirely different
than what you typed.

Wojtek Lerch

Re: PtTrend question & bug report

Post by Wojtek Lerch » Thu Sep 18, 2003 3:45 pm

Bill Caroselli <qtps@earthlink.net> wrote:
Wojtek Lerch <wojtek_l@ottawa.com> wrote:
WL > No, it's not a PtNumeric problem -- it's the way PhAB reads the Min Value
WL > back from PtTrend. Since it's using the "no pointer" method,
WL > PtGetResources() returns the value in the long "value" field of a PtArg_t.
WL > It does that by copying the 16 bits of the short into the low 16 bits of the
WL > long, and since it has no idea whether the short is signed or not, it always
WL > sets the other 16 bits of the long to zero. Perhaps it would have been a
WL > better idea to always sign-extend it -- if we have to return some values
WL > incorrectly, it's probably better to break very big unsigned shorts than all
WL > the negative signed shorts. But I'm not sure if changing it *now* would be
WL > such a great idea...
....
But the good news is this, if the application (and that includes PhAB)
knows that the value being returned is a short, then it just has to:
The bad news is that PhAB does not know that the value is a short.
long value;
short s_value;
s_value = (value & 0xffff);
The sign bit from the original short should be preserved, right?
Yes; you don't even need to do the &0xffff part.

But you do need to know that the value is a short.
Please write that up as a bug fix. There is nothing more annoying than
to type in one number have it echo back something entirely different
than what you typed.
It would be justified if it were different because the value you typed
in was incorrect and the widget had to adjust it. But in this case, the
widget accepted the value you typed in and it's just the library that
reports it as a completely different valuue; and I agree it's a bug and
it's annoying. I probably could think of one or two things that are
even more annoying, but that doesn't change the fact that basically I
agree with you. ;-)

Bill Caroselli

Re: PtTrend question & bug report

Post by Bill Caroselli » Thu Sep 18, 2003 5:38 pm

Wojtek Lerch <wojtek_l@yahoo.ca> wrote:

WL > The bad news is that PhAB does not know that the value is a short.

Well I'm sure that PhAB should know that PtTrend's Min Value is a short.
So I guess your saying that the dialog box doesn't know it's working on
a PtTrend.MinValue.

Perhaps there should be 4 dialog for editing a numeric resource.
short
long
unsigned short
unsigned long

Oh well. I'll let it go for now and wait to 6.3.

Wojtek Lerch

Re: PtTrend question & bug report

Post by Wojtek Lerch » Thu Sep 18, 2003 7:33 pm

Bill Caroselli <qtps@earthlink.net> wrote:
Wojtek Lerch <wojtek_l@yahoo.ca> wrote:

WL > The bad news is that PhAB does not know that the value is a short.

Well I'm sure that PhAB should know that PtTrend's Min Value is a short.
Not really. If PtGetResources() knew how to return the correct value,
PhAB wouldn't need to care about whether the widget internally stores it
as a short or a long. The real problem is not that PhAB doesn't know
that the value -1 comes back as 65535 for some resources or as 255 for
some others: the problem is that it doesn't always come back as -1.

It's not the same as the fact that if you actually try to set the
resource to 65535 or to 655359, the widget will set it to -1.
Personally, I think widgets should be allowed to do this kind of mildly
silly things if you try to set a resource to a completely silly value.
But that's when you set it from code -- PhAB should know what values are
completely silly, and shouldn't allow you to set them. If a resource
can only accept values between 0 and 100, PhAB shouldn't let you try to
set it to 101, or 65565, or 655359. PhAB doesn't need to know whether a
resource like that is stored in 8 or 16 bits and whether it's declared
signed or unsigned in the code, but PhAB needs to know the range of
valid values.

The good news is that this one is currently being worked on. And it may
even make it possible for PhAB to work around the first one. The bad
news is that the first one is tough -- we're using all the bits in the
resource definition records already, and there's no way to add
information about the signedness to it without breaking backwards
compatibility.

Bill Caroselli

Re: New Question

Post by Bill Caroselli » Fri Sep 19, 2003 3:05 pm

OK. PtTrend isn't quite going to do what I need.

I'm looking for some advice from one of you real low level photon gurus.

I need to present multiple trendlines, kind of like a heart beat
monitor. I need to change the color of the lines while their coming
out. (I.E. New points only. I won't change pixels after they've been
displayed.) I also need to change background color as new points are
being displayed. I need to be able to draw a line across all trendlines
to mark certain events. And I need to be able to draw text, both
horizontally and vertically.

As these things are drawn I want them to scroll with the trendline.
(BTW, I will never draw text near the edges so I won't have to worry
about clipping text as it is being drawn.)

My thoughts were this:

1) Use a PtTrend and overlay the text and background colors somehow.
I'm not sure that this can be done. If is can be done, I don't think
I can make the PtTrend scroll it all.

2) Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?

3) Use a PtLabel (image type) and define my own PhImage_t. (My plan
is to use 1 byte per pixel.) I can do my own graphics into this image
(I think) and I can do my own blitting of this image. But can I draw
text into my PhImage_t?

BTW, I'd like to update my image 4-10 times per second.

What is the best aproach?

Dave Rempel

Re: New Question

Post by Dave Rempel » Fri Sep 19, 2003 3:57 pm

Bill Caroselli wrote:
OK. PtTrend isn't quite going to do what I need.

I'm looking for some advice from one of you real low level photon gurus.

I need to present multiple trendlines, kind of like a heart beat
monitor. I need to change the color of the lines while their coming
out. (I.E. New points only. I won't change pixels after they've been
displayed.) I also need to change background color as new points are
being displayed. I need to be able to draw a line across all trendlines
to mark certain events. And I need to be able to draw text, both
horizontally and vertically.

As these things are drawn I want them to scroll with the trendline.
(BTW, I will never draw text near the edges so I won't have to worry
about clipping text as it is being drawn.)

My thoughts were this:

1) Use a PtTrend and overlay the text and background colors somehow.
I'm not sure that this can be done. If is can be done, I don't think
I can make the PtTrend scroll it all.

2) Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
Yes, using PtBlit()
3) Use a PtLabel (image type) and define my own PhImage_t. (My plan
is to use 1 byte per pixel.) I can do my own graphics into this image
(I think) and I can do my own blitting of this image. But can I draw
text into my PhImage_t?
You can draw text into your PhImage_t using a memory context
(PmMemCreateMC())
BTW, I'd like to update my image 4-10 times per second.

What is the best aproach?

Bill Caroselli

Re: New Question

Post by Bill Caroselli » Fri Sep 19, 2003 10:16 pm

Dave Rempel <drempel@qnx.com> wrote:
DR > Bill Caroselli wrote:
My thoughts were this:

2) Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
DR > Yes, using PtBlit()

I'm using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
inside of my main window.

Also on my main window I have a PtButton I've added for diagnostic
purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
row.

The blitting is working, *BUT* the draw function for my PtRaw is also
being called. Nothing should be damaging the widget.

Why is the draw function being called?

I'm using blitting because I don't want to redraw the whole thing!
The button that I'm clicking does not over lap PtPanelGrou in any way.

Bill Caroselli

Re: New Question

Post by Bill Caroselli » Fri Sep 19, 2003 10:49 pm

Bill Caroselli <qtps@earthlink.net> wrote:
BC > Dave Rempel <drempel@qnx.com> wrote:
BC > DR > Bill Caroselli wrote:
My thoughts were this:

2) Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > DR > Yes, using PtBlit()

BC > I'm using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > inside of my main window.

BC > Also on my main window I have a PtButton I've added for diagnostic
BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > row.

BC > The blitting is working, *BUT* the draw function for my PtRaw is also
BC > being called. Nothing should be damaging the widget.

BC > Why is the draw function being called?

BC > I'm using blitting because I don't want to redraw the whole thing!
BC > The button that I'm clicking does not over lap PtPanelGrou in any way.

I did a little more research. It is the call to PtBlit that is
damaging the widget. If I comment out the PtBlit() call then my draw
function does not get called.

What am I doing wrong?

Bill Caroselli

Re: New Question

Post by Bill Caroselli » Mon Sep 22, 2003 3:29 pm

I'm still waiting to find out why PtBlit() is damaging my widget
(I.E. forcing my draw_f() function ot be called.

I have a new problem.

In my draw function I call:
PhRect_t my_rect;
PtCalcCanvas( widget, &my_rect );
PgSetTranslation( &my_rect.ul, PgRELATIVE );
/* draw stuff */
my_rect.ul.x *= -1;
my_rect.ul.y *= -1;
PgSetTranslation( &my_rect.ul, PgRELATIVE );
where 'widget' is from the draw callback, and this works. Everything I
draw is where I expect it to be.

Later in the program some external event occurs and I try to display a
new object on the PtRaw widget. I call:
PhRect_t my_rect;
PtCalcCanvas( ABW_my_widget, &my_rect );
PgSetTranslation( &my_rect.ul, PgRELATIVE );
/* draw stuff */
my_rect.ul.x *= -1;
my_rect.ul.y *= -1;
PgSetTranslation( &my_rect.ul, PgRELATIVE );
but the translation is off. I.E. it draws too high. Above my PtRaw
widget actually. Note: I left the clipping off just so I could see
where it was drawing.

Why is my translation wrong?

In th PgSetTranslation(), PgRELATIVE is relative to what?
Note: there is no telling what widget had focus when the additional
draw was attempted.


Bill Caroselli <qtps@earthlink.net> wrote:
BC > Bill Caroselli <qtps@earthlink.net> wrote:
BC > BC > Dave Rempel <drempel@qnx.com> wrote:
BC > BC > DR > Bill Caroselli wrote:
My thoughts were this:

2) Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > BC > DR > Yes, using PtBlit()

BC > BC > I'm using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > BC > inside of my main window.

BC > BC > Also on my main window I have a PtButton I've added for diagnostic
BC > BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > BC > row.

BC > BC > The blitting is working, *BUT* the draw function for my PtRaw is also
BC > BC > being called. Nothing should be damaging the widget.

BC > BC > Why is the draw function being called?

BC > BC > I'm using blitting because I don't want to redraw the whole thing!
BC > BC > The button that I'm clicking does not over lap PtPanelGrou in any way.

BC > I did a little more research. It is the call to PtBlit that is
BC > damaging the widget. If I comment out the PtBlit() call then my draw
BC > function does not get called.

BC > What am I doing wrong?

Bill Caroselli

Re: New Question

Post by Bill Caroselli » Mon Sep 22, 2003 5:53 pm

Can someone at QSSL take a stab at this?

Bill Caroselli <qtps@earthlink.net> wrote:
BC > Dave Rempel <drempel@qnx.com> wrote:
BC > DR > Bill Caroselli wrote:
My thoughts were this:

2) Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?
BC > DR > Yes, using PtBlit()

BC > I'm using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > inside of my main window.

BC > Also on my main window I have a PtButton I've added for diagnostic
BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > row.

BC > The blitting is working, *BUT* the draw function for my PtRaw is also
BC > being called. Nothing should be damaging the widget.

BC > Why is the draw function being called?

BC > I'm using blitting because I don't want to redraw the whole thing!
BC > The button that I'm clicking does not over lap PtPanelGrou in any way.

Wojtek Lerch

Re: New Question

Post by Wojtek Lerch » Mon Sep 22, 2003 6:35 pm

Bill Caroselli <qtps@earthlink.net> wrote:
Can someone at QSSL take a stab at this?
PtBlit() damages the portion of the source rectangle that doesn't
overlap with the destination rectangle. For instance, if you're
blitting by one pixel to the right, it'll damage a one-pixel strip along
the left adge of the rectangle.

It also will damage any portions of the destination area where the
corresponding source area is invisible (i.e. outside of the canvas; I
don't think we handle cases where there's another widget on top of the
one you're blitting). For instance, if you take a huge rectangle and
blit it by one pixel to the left, it'll damage a one-pixel strip along
the right edge of the canvas.
Bill Caroselli <qtps@earthlink.net> wrote:
BC > Dave Rempel <drempel@qnx.com> wrote:
BC > DR > Bill Caroselli wrote:

My thoughts were this:

2) Use a PtRaw and draw what I need as I need it. But can I blit my
PtRaw image?


BC > DR > Yes, using PtBlit()

BC > I'm using a PtRaw inside of a PtOSContainer inside of a PtPanelGroup
BC > inside of my main window.

BC > Also on my main window I have a PtButton I've added for diagnostic
BC > purposes. It calls the routine that PtBlit()s my PtRaw by one pixel
BC > row.

BC > The blitting is working, *BUT* the draw function for my PtRaw is also
BC > being called. Nothing should be damaging the widget.

BC > Why is the draw function being called?

BC > I'm using blitting because I don't want to redraw the whole thing!
BC > The button that I'm clicking does not over lap PtPanelGrou in any way.
--
Wojtek Lerch QNX Software Systems Ltd.

Post Reply

Return to “qdn.public.qnxrtp.photon”