STR #1332

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.1 ]

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:

Receive EMails Don't Receive EMails

Trouble Report Files:


Name/Time/Date Filename/Size top right image
 
#1 ianmacarthur
04:49 Jun 22, 2006
lost_label.cxx
2k
 
bottom left image   bottom right image

Trouble Report Comments:


Name/Time/Date Text top right image
 
#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.
 
bottom left image   bottom right image

Return to Bugs & Features ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.