| | [ Return to Bugs & Features | Roadmap 1.1 | SVN ⇄ GIT ]
STR #1332
| Application: | FLTK Library |
|---|
| Status: | 1 - Closed w/Resolution |
|---|
| Priority: | 4 - High, e.g. key functionality not working |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | copy_label not working for window titles on win32 with 1.1.7 |
|---|
| Version: | 1.1.7 |
|---|
| Created By: | ianmacarthur |
|---|
| Assigned To: | matt |
|---|
| Fix Version: | 1.1-current (SVN: v5251) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | ianmacarthur
04:49 Jun 22, 2006 |
| I've been seeing a problem with the labels of my windows disappearing when the windows are hidden then re-shown. Seems to afflict windows who's label is set using copy_label().
If the window is hidden using it's minimise button, the label survives intact, if I hide it programmatically, the label is lost. Is this expected? I'd think not...
This is with fltk-1.1.7 on win32 compiled with mingw. Demo program attached. (Can't try on linux or OSX right now... Don't know if they also show this "feature".) | |
| |
| #2 | fabien
05:20 Jun 22, 2006 |
| Ian,
I switch your STR to 1.1.7 as is an fltk1 problem not a 2.0 feature. | |
| |
| #3 | ianmacarthur
10:28 Jun 22, 2006 |
| All,
Just got a chance to test this on OSX 10.4.6 and linux (fc5) and they both manifest the same behaviour. It looks (at least on the linux box, sometimes on the win32 version) as if the label is filled with random data, not the "copied lable", after a hide/show sequence.
I'm guessing the hide is destroying the label or some such - just off to look at the code!
--
Ian | |
| |
| #4 | ianmacarthur
12:03 Jun 22, 2006 |
| There seems to be some sort of interaction with the COPIED_LABEL flag and the way Fl_Widget::label(...) is called in Fl_Window::draw()...
That is to say, in Fl_Window::draw(), Fl_Widget::label(a) is called twice.
Now, the first time it is called with :
Fl_Widget::label(0);
to null the label, having "stored" the original label in savelabel.
The second time is is called, is to restore the label (using savelabel).
Fl_Widget::label(savelabel);
However, after that first call to Fl_Widget::label(0), savelabel is also rendered empty (I guess the pointer gets emptied "elsewhere" in the redraw label sequence) so the subsequent call to
Fl_Widget::label(savelabel) does not restore the label, since it has nothing to restore...
Now, adding the line :
clear_flag(COPIED_LABEL);
Before the first call to :
Fl_Widget::label(0);
Appears to resolve the problem... I do not care to speculate on what else it may break as a consequence.... Anybody?
--
Ian | |
| |
| #5 | matt
03:26 Jun 28, 2006 |
| Fixed in Subversion repository.
Widget flags were saved in an uchar during redraw, effectively losing 24 of the 32 bit in flags_. Clearing the COPIED_LABEL flag before clearing the label field now keeps Fl_Widget from deleting the text. | |
[ Return to Bugs & Features ]
|
| |
