Dialog window image corruption

This is damn freaky. I have a dialog window. The setup() routine
initializes all of the data fields from internal memory.

If I leave the dialog window on the screen and load new values the
physical appearance of the window is harmed. (This is done by clicking
on a load button, which pops up a file select widget. When a file is
selected the file is read into a struct and the dialog setup() routine is
called again.)

I have uploaded to my QUICS account (bcaroselli) a before.bmp and an
after.bmp screep shot so that you can see what I’m talking about.

Here’s where it gets wierd. If I click on any of the widgets that were
harmed they get re-drawn correctly. Or, if I pop up another window and
pass it over any part of one of the harmed widgets they get re-drawn
correctly.

The only thing that has changed in this program is that I now have my own
cover function for open() called sp_open() that parses space characters
into and out of the file name as appropriate. BTW, the sp_open() does
work.

Note: I have used the word harmed here only to not use a photon verb like
damage or destroy. I am not doing any of those things.

I have no idea in the world what to even look at. I’ve stopped my program
in the setup() routine before the calls to PtSetResource() for
Pt_ARG_TEXT_STRING. The ascii strings are correct and of correct sizes.

Is there any real reason why I can’t call my setup() callback again
without the dialog having been destroyed in the meantime? This used to
work.

Help me Photon-Wan Kanobi. Your my only hope.

A little more information:

In my setup() routine I have the following two lines:
SetTextString( AbGetABW( format_widget_group[ nc ].osd_desc_text ), format.formats[ nc ].osd_desc );
SetTextString( AbGetABW( format_widget_group[ nc ].prtr_desc_text ), format.formats[ nc ].prtr_desc );

SetTextString() is a convienence function that looks like this:
void SetTextString ( PtWidget_t * widget, const char * string )
{
PtSetResource( widget, Pt_ARG_TEXT_STRING, string, 0 );
return;
}

format_widget_group is an array of structures that has the ABN_values for
each of the widgets that I need to update.

All of this works perfectly on the first pass through my setup(). Also,
if I comment out either of the two lines above, the subsequent passes
through setup() also work, except that that appropriate field isn’t
updated.

So again, is there any obscure rule that says I can’t call my setup()
routine more than once to set the text resource for a widget more than
once. I know this can’t be true!


Bill Caroselli <qtps@earthlink.net> wrote:
BC > This is damn freaky. I have a dialog window. The setup() routine
BC > initializes all of the data fields from internal memory.

BC > If I leave the dialog window on the screen and load new values the
BC > physical appearance of the window is harmed. (This is done by clicking
BC > on a load button, which pops up a file select widget. When a file is
BC > selected the file is read into a struct and the dialog setup() routine is
BC > called again.)

BC > I have uploaded to my QUICS account (bcaroselli) a before.bmp and an
BC > after.bmp screep shot so that you can see what I’m talking about.

BC > Here’s where it gets wierd. If I click on any of the widgets that were
BC > harmed they get re-drawn correctly. Or, if I pop up another window and
BC > pass it over any part of one of the harmed widgets they get re-drawn
BC > correctly.

BC > The only thing that has changed in this program is that I now have my own
BC > cover function for open() called sp_open() that parses space characters
BC > into and out of the file name as appropriate. BTW, the sp_open() does
BC > work.

BC > Note: I have used the word harmed here only to not use a photon verb like
BC > damage or destroy. I am not doing any of those things.

BC > I have no idea in the world what to even look at. I’ve stopped my program
BC > in the setup() routine before the calls to PtSetResource() for
BC > Pt_ARG_TEXT_STRING. The ascii strings are correct and of correct sizes.

BC > Is there any real reason why I can’t call my setup() callback again
BC > without the dialog having been destroyed in the meantime? This used to
BC > work.

BC > Help me Photon-Wan Kanobi. Your my only hope.

Two more things:

First, if I put a PtDamageWidget() at the end of my setup() routine all
works as expected. But I don’t consider this exceptable.

Second, I don’t know if this is related but, the dialog widget is on top
of a PtRaw widget that is drawn using an off screen context. However, the
OS_Context is NOT being updated at the time that this dialog exists. I.E.
the PtRaw is only used during data collection mode. This dialog can only
be requested if your NOT in data collection mode.


Bill Caroselli <qtps@earthlink.net> wrote:
BC > A little more information:

BC > In my setup() routine I have the following two lines:
BC > SetTextString( AbGetABW( format_widget_group[ nc ].osd_desc_text ), format.formats[ nc ].osd_desc );
BC > SetTextString( AbGetABW( format_widget_group[ nc ].prtr_desc_text ), format.formats[ nc ].prtr_desc );

BC > SetTextString() is a convienence function that looks like this:
BC > void SetTextString ( PtWidget_t * widget, const char * string )
BC > {
BC > PtSetResource( widget, Pt_ARG_TEXT_STRING, string, 0 );
BC > return;
BC > }

BC > format_widget_group is an array of structures that has the ABN_values for
BC > each of the widgets that I need to update.

BC > All of this works perfectly on the first pass through my setup(). Also,
BC > if I comment out either of the two lines above, the subsequent passes
BC > through setup() also work, except that that appropriate field isn’t
BC > updated.

BC > So again, is there any obscure rule that says I can’t call my setup()
BC > routine more than once to set the text resource for a widget more than
BC > once. I know this can’t be true!


BC > Bill Caroselli <qtps@earthlink.net> wrote:
BC > BC > This is damn freaky. I have a dialog window. The setup() routine
BC > BC > initializes all of the data fields from internal memory.

BC > BC > If I leave the dialog window on the screen and load new values the
BC > BC > physical appearance of the window is harmed. (This is done by clicking
BC > BC > on a load button, which pops up a file select widget. When a file is
BC > BC > selected the file is read into a struct and the dialog setup() routine is
BC > BC > called again.)

BC > BC > I have uploaded to my QUICS account (bcaroselli) a before.bmp and an
BC > BC > after.bmp screep shot so that you can see what I’m talking about.

BC > BC > Here’s where it gets wierd. If I click on any of the widgets that were
BC > BC > harmed they get re-drawn correctly. Or, if I pop up another window and
BC > BC > pass it over any part of one of the harmed widgets they get re-drawn
BC > BC > correctly.

BC > BC > The only thing that has changed in this program is that I now have my own
BC > BC > cover function for open() called sp_open() that parses space characters
BC > BC > into and out of the file name as appropriate. BTW, the sp_open() does
BC > BC > work.

BC > BC > Note: I have used the word harmed here only to not use a photon verb like
BC > BC > damage or destroy. I am not doing any of those things.

BC > BC > I have no idea in the world what to even look at. I’ve stopped my program
BC > BC > in the setup() routine before the calls to PtSetResource() for
BC > BC > Pt_ARG_TEXT_STRING. The ascii strings are correct and of correct sizes.

BC > BC > Is there any real reason why I can’t call my setup() callback again
BC > BC > without the dialog having been destroyed in the meantime? This used to
BC > BC > work.

BC > BC > Help me Photon-Wan Kanobi. Your my only hope.

\

Bill Caroselli – Q-TPS Consulting
1-(708) 308-4956 <== Note: New Number
qtps@earthlink.net

Bill Caroselli wrote:

First, if I put a PtDamageWidget() at the end of my setup() routine all
works as expected. But I don’t consider this exceptable.

Agreed. It’s the job of PtSetResource() to damage the affected portions
of the widget.

Second, I don’t know if this is related but, the dialog widget is on top
of a PtRaw widget that is drawn using an off screen context. However, the
OS_Context is NOT being updated at the time that this dialog exists. I.E.
the PtRaw is only used during data collection mode. This dialog can only
be requested if your NOT in data collection mode.

By “dialog widget”, you’re not referring to the window, right? In other
words, the PtRaw is in the same window as the widgets that look wrong,
correct?

It’s not unusual that when you change the contents of a widget, widgets
behind it are told to draw. What does your raw widget’s draw function
do if called in this context?

Have you tried unrealizing the raw widget when it’s not used?

Wojtek Lerch <Wojtek_L@yahoo.ca> wrote:
WL > Bill Caroselli wrote:

First, if I put a PtDamageWidget() at the end of my setup() routine all
works as expected. But I don’t consider this exceptable.

WL > Agreed. It’s the job of PtSetResource() to damage the affected portions
WL > of the widget.

Second, I don’t know if this is related but, the dialog widget is on top
of a PtRaw widget that is drawn using an off screen context. However, the
OS_Context is NOT being updated at the time that this dialog exists. I.E.
the PtRaw is only used during data collection mode. This dialog can only
be requested if your NOT in data collection mode.

WL > By “dialog widget”, you’re not referring to the window, right? In other
WL > words, the PtRaw is in the same window as the widgets that look wrong,
WL > correct?

WL > It’s not unusual that when you change the contents of a widget, widgets
WL > behind it are told to draw. What does your raw widget’s draw function
WL > do if called in this context?

WL > Have you tried unrealizing the raw widget when it’s not used?

The PtRaw is on the base window. The base window takes up the entire
screen. The raw widget takes up most of the base window. There are also
some buttons and some status information.

The raw widget is initialized to a splash screen image when it’s not in
use. When it IS is use it displays something like your PtTrends widget
except that events and certain data points are labeled.

One of those buttons on the base window pops up the dialog window. That
button is disabled when in data collection mode. The dialog window
formats teh traces of my oscilliscope.

The deal is that when I read in a new config file that was saved with
formats for the various traces, some of the PtLabel, PtText, and
PtToggleButtons are completely or partily erased.

Would it help if I uploaded the application so that you can see this
happen first hand.

I really think think this is a photon issue and not a problem with my
code.

I can give you instructions to make the problem occur in less than 10
keystrokes/mouse clicks.


Bill Caroselli <qtps@earthlink.net> wrote:
BC > Wojtek Lerch <Wojtek_L@yahoo.ca> wrote:
BC > WL > Bill Caroselli wrote:

First, if I put a PtDamageWidget() at the end of my setup() routine all
works as expected. But I don’t consider this exceptable.

BC > WL > Agreed. It’s the job of PtSetResource() to damage the affected portions
BC > WL > of the widget.

Second, I don’t know if this is related but, the dialog widget is on top
of a PtRaw widget that is drawn using an off screen context. However, the
OS_Context is NOT being updated at the time that this dialog exists. I.E.
the PtRaw is only used during data collection mode. This dialog can only
be requested if your NOT in data collection mode.

BC > WL > By “dialog widget”, you’re not referring to the window, right? In other
BC > WL > words, the PtRaw is in the same window as the widgets that look wrong,
BC > WL > correct?

BC > WL > It’s not unusual that when you change the contents of a widget, widgets
BC > WL > behind it are told to draw. What does your raw widget’s draw function
BC > WL > do if called in this context?

BC > WL > Have you tried unrealizing the raw widget when it’s not used?

BC > The PtRaw is on the base window. The base window takes up the entire
BC > screen. The raw widget takes up most of the base window. There are also
BC > some buttons and some status information.

BC > The raw widget is initialized to a splash screen image when it’s not in
BC > use. When it IS is use it displays something like your PtTrends widget
BC > except that events and certain data points are labeled.

BC > One of those buttons on the base window pops up the dialog window. That
BC > button is disabled when in data collection mode. The dialog window
BC > formats teh traces of my oscilliscope.

BC > The deal is that when I read in a new config file that was saved with
BC > formats for the various traces, some of the PtLabel, PtText, and
BC > PtToggleButtons are completely or partily erased.

Sounds like a plan… Especially if you could first try to narrow it
down by removing as many pieces as you can without making the problem go
away…

Bill Caroselli wrote:

Would it help if I uploaded the application so that you can see this
happen first hand.

I really think think this is a photon issue and not a problem with my
code.

I can give you instructions to make the problem occur in less than 10
keystrokes/mouse clicks.

I can do this today.

Do you need a compilable version?

The reason I ask is that I use several libraries that aren’t my own.


Wojtek Lerch <Wojtek_L@yahoo.ca> wrote:
WL > Sounds like a plan… Especially if you could first try to narrow it
WL > down by removing as many pieces as you can without making the problem go
WL > away…

WL > Bill Caroselli wrote:

Would it help if I uploaded the application so that you can see this
happen first hand.

I really think think this is a photon issue and not a problem with my
code.

I can give you instructions to make the problem occur in less than 10
keystrokes/mouse clicks.

Bill Caroselli wrote:

I can do this today.

Do you need a compilable version?

The reason I ask is that I use several libraries that aren’t my own.

Can you remove them without making the problem go away? :wink:

If not, I guess we can try with just the executable and the PhAB
project. Not necessarily compilable, but at least loadable into PhAB.
It’s a PhAB project, right?

Wojtek Lerch <> Wojtek_L@yahoo.ca> > wrote:
WL > Sounds like a plan… Especially if you could first try to narrow it
WL > down by removing as many pieces as you can without making the problem go
WL > away…

WL > Bill Caroselli wrote:

Would it help if I uploaded the application so that you can see this
happen first hand.

I really think think this is a photon issue and not a problem with my
code.

I can give you instructions to make the problem occur in less than 10
keystrokes/mouse clicks.

Wojtek Lerch <Wojtek_L@yahoo.ca> wrote:
WL > Bill Caroselli wrote:

I can do this today.

Do you need a compilable version?

The reason I ask is that I use several libraries that aren’t my own.

WL > Can you remove them without making the problem go away? :wink:

WL > If not, I guess we can try with just the executable and the PhAB
WL > project. Not necessarily compilable, but at least loadable into PhAB.
WL > It’s a PhAB project, right?

It is a PhAB program.

I’ve been trying to strip stuff away since early this morning.
I’m getting a link error but I can’t find the reference to the missing
modual.

I’ll post as soon as I am able.

Bill Caroselli wrote:

I’ll post as soon as I am able.

No rush. :wink: