nanogui: Thread: repeated XSetClipMask question

hi all,

I made an application with a label whose contents are updated with the
current time each second:
if I uupdate the time with a

    dateAndTimeLabel->value(s);

the value of the label is updated but it is written on the old value,
so the result it a complete mess.

If I use:
   dateAndTimeLabel->hide();
   dateAndTimeLabel->value(s);
   dateAndTimeLabel->show();

the label is correctly updated, but I see on the console a

XSetClipMask 285

message for each update.

dateAndTimeLabel is defined as follows:

 { Fl_Output* o = dateAndTimeLabel = new Fl_Output(HEADER1_DATE_X,
                                                    HEADER1_DATE_Y,
                                                    HEADER1_DATE_W,
                                                    HEADER1_DATE_H);
  o->box(FL_NO_BOX);  // FL_FLAT_BOX);
  o->labeltype(FL_NO_LABEL);
  //o->labelfont(1);
  //o->labelsize(24);
  o->textfont(HEADER1_FONT_TYPE);
  o->textsize(HEADER1_FONT_SIZE);
  o->value("");
  }

it it correct to implement an updatin clock in this way?
that "isXSetClipMask 285" indicates any memory leak?
Which is the correct way to implement an updating clock?

thanks
giammy

-- 
Gianluca Moro          http://groups.yahoo.com/group/embeddeditalia/
ISCRIVITI alla             Mailing List Italiana su LINUX EMBEDDED
####@####.####   www.giammy.com

: that "isXSetClipMask 285" indicates any memory leak?

As indicated in the NXLIB source, there's currently a memory
leadk in XSetClipMask, a region is allocated and
not free'd.  You should the the FLTK underchassis to see
where XSetClipMask is used, and then determine where
a call to GrDestroyRegion might called from.


: it it correct to implement an updatin clock in this way?
: Which is the correct way to implement an updating clock?

I'm not big on C++, so I can't give advice here.  Another
idea might be to keep a drawable around and use a timer
to draw the new time when required, without recreating
the FL_Output* each time.

Regards,

Greg

Hi,

We fixed this memory leak by making the 
region a static pointer and calling destroy on
re-entering the function if the pointer is not null.

old C++ trick ;-)

Robin



--- Greg Haerr ####@####.#### wrote:

> : that "isXSetClipMask 285" indicates any memory
> leak?
> 
> As indicated in the NXLIB source, there's currently
> a memory
> leadk in XSetClipMask, a region is allocated and
> not free'd.  You should the the FLTK underchassis to
> see
> where XSetClipMask is used, and then determine where
> a call to GrDestroyRegion might called from.
> 
> 
> : it it correct to implement an updatin clock in
> this way?
> : Which is the correct way to implement an updating
> clock?
> 
> I'm not big on C++, so I can't give advice here. 
> Another
> idea might be to keep a drawable around and use a
> timer
> to draw the new time when required, without
> recreating
> the FL_Output* each time.
> 
> Regards,
> 
> Greg
> 
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ####@####.####
> For additional commands, e-mail:
> ####@####.####
> 
> 


		
___________________________________________________________ 
What kind of emailer are you? Find out today - get a free analysis of your email personality. Take the quiz at the Yahoo! Mail Championship. 
http://uk.rd.yahoo.com/evt=44106/*http://mail.yahoo.net/uk 

: We fixed this memory leak by making the 
: region a static pointer and calling destroy on
: re-entering the function if the pointer is not null.

If it works for you, great.  I'm not sure this will
work for the general case, since the mask region
isn't associated with the specific gc, but all
gc's.  Another fix (more work) might be to
mark the region r as 'temp' and have
GrSetGCRegion delete temp regions when
a new region is specified...

: 
: old C++ trick ;-)

Yes...  'static' comes in handy in C too !