On 12/09/11 12:05, Bill Spitzak wrote:
> I would not do this, as it will make it impossible to link unrelated
> fltk-using code together as this would have to be a static value. Or we
> have to waste space to put the value on every widget.
>
> The user should be able to turn on the "don't interpret @" flag on the
> widgets they need it for.
>
> If they actually want @-commands to work with their strings, it seems
> they must be modifying them to add these commands. They should be able
> to double the @ signs in the original string at the same time.
I've run into this need myself quite often, and it is
troublesome to manage.
Would be nice if the @ char could be set to NULL to "disable" it
globally, as it's more often then not an @ can sneak into the app
via user supplied input, config files, etc.
Creating wrappers for all widgets that add/remove @'s for set/get
label methods is a major undertaking. (What I've done in other apps)
Also, doubling up @'s makes it really hard for apps to read back
label()s and get expected results; such as doing searches by label()
name involves adding the extra @'s to the search string so that it
properly matches the label()'s return value. And reading back
label() values and use them in other parts of the app (to save
to files) involves /stripping/ the extra @'s.
For the many apps that don't want @'s to be parsed at all,
it would really be helpful to be able to disable globally.
I think a static should be OK for this, shouldn't it?
And an Fl::xxx() function to set/get. Wouldn't involve
any conditionals to the code I think. Just have to make sure
setting it to NULL doesn't bungle up string parsing.
The only alternative I can think of is new methods to set/get
labels that add/remove the @'s automatically, eg:
label_nosym(const char*) would automatically pre-insert @.,
and const char* label_nosym(void) would return a pointer
that skips over the leading @. This would at least allow
per-widget control I suppose.
Perhaps there are other techniques I'm not thinking of,
but would like some better way to manage this.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
