[email protected] wrote:
> It occurred to me to try the following, which seems to
> work okay. Other than being relatively inefficient,
> do you guys see any issues with it?
>
> Thanks again,
> Stan
>
> void
> relabel(Fl_Widget* w, char const* newlabel, bool copy = false)
> {
> static std::string spaces(" ");
> if(w->label()) {
> spaces.resize(1);
> while(fl_width(spaces.c_str()) < fl_width(w->label())) {
> spaces += ' ';
> }
> w->label(spaces.c_str());
> w->redraw_label();
> }
> if(copy) w->copy_label(newlabel); else w->label(newlabel);
> w->redraw_label();
> }
I was tempted to say that this wouldn't work, because redraw_label() would only
mark the label to be drawn, but wouldn't draw it at this moment, and because
(...see also Matthias' reply), but you wrote that it "seems to work okay".
This made me curious, and I looked at the sources (hey, it's open source, you
can do this yourself ;-) ). What I saw, lets me propose to try the following
shorter version:
void
relabel(Fl_Widget* w, char const* newlabel, bool copy = false)
{
w->redraw_label();
if(copy) w->copy_label(newlabel); else w->label(newlabel);
w->redraw_label();
}
Much shorter, isn't it? I didn't test it, but I'd bet that it works as well ;-)
However, I'd say that this is completely unsupported, because such behavior
isn't documented anywhere. (Or is it?)
Why should this work? The first w->redraw_label() will _damage()_ the window's
region, where the _old_ label is (was), and the second call will damage() the
window's region, where the _new_ label is (will be). The real drawing will then
happen with the new label, and the bigger region will be cleared with the
window's background (or any other group or widget).
And that is the reason, why your version works. Surprising ...
But: since this is (IMHO) unsupported, I suggest to use Matthias' proposal with
another widget for the changing text.
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
