> On 11/09/11 14:06, David wrote:
> > DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK 
> > BELOW.
> > Link: http://www.fltk.org/str.php?L2766
> > Version: 1.3-feature
> >
> > This change allows someone to configure FLTK to use 0x0F as the symbol
> > prefix character instead of @.  This allows the use of @ without special
> > handling which can be troublesome since internal widgets use @ for things
> > like arrows and special characters.  To enable support for the new prefix
> > you'd run ./configure with the --enable-newprefix option (you may have to
> > remake the configure first, "make clean" seems to do that for you).
>
>       I like the idea of being able to change or disable the symbol prefix 
> char,
>       I don't think it works as a config option. (For instance, this would 
> break
>       in a dll environment, where the user's system would have stock fltk 
> dlls)
>
>       I'd offer this alternative suggestion: to retain back compatibility
>       with old apps, but allow new apps to still use/change/disable symbols,
>       I could see creating two new api calls; Fl::symbol_char() and 
> Fl::symbol_str():
>
> Fl::symbol_char(0);                           // disables symbols throughout 
> FLTK app
> Fl::symbol_char('@');                         // sets the symbol char 
> (default)
> Fl::symbol_char(0x0f);                                // sets symbol char to 
> 0x0f
> char c = Fl::symbol_char();                   // gets the current symbol char
> std::string rightarrow = Fl::symbol_str("->");        // get an FLTK symbol 
> string
>
>       This way if the symbol char is default (@), Fl::symbol_str("->")
>       would return "@->", but if the symbol char were 0, Fl::symbol_str("->")
>       would return "".

I was going to do variables but wanted to do at compile time to use string 
concatenation to keep things as close to the same as possible and not have to 
deal with building and managing strings since without the new always copy label 
option enabled, or using copy_label, the strings returned have to be persist. A 
varaible method may be good for something in 3.0?
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev

Reply via email to