On 05/08/12 20:25, Fabien Costantini wrote:
>> On 05/08/12 19:47, Fabien Costantini wrote:
>>> Now, at initialization the item label color is an 'undefined' value
>>> (let say 0xffffffff ?). Note that value would be stored in the prefs
>>> as well if user did not specify a custom color.
>>
>> Ah, OK, I was going to use a bitflag to keep track of this,
>> and a special 'reset' method to control the flag, but overloading
>> the color ff/ff/ff/ff is better.
OK, try r9478.
It defaults the item_labelbgcolor() to 0xffffffff.
The interpretation of this is entirely in the draw() code;
the set/get methods are consistent in how that value is returned.
This way the user can test for that value to see if 'transparent mode'
is enabled. Also, if the user changes it to a 'normal' color, they
can set it back again to 'transparent' mode.
The docs cover this behavior, and it should be backwards compatible
in that the tree's behavior should be consistent with previous versions.
I've enhanced the test/tree application to test for this;
click on the "Test Suggestions" button at the lower right to see how
to test this new color behavior (under the 'Color' section).
_______________________________________________
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
