On Thu, Mar 24, 2011 at 7:39 PM, Greg Ercolano <[email protected]> wrote:
> Evan Laforge wrote:
>>> #include <FL/names.H>
>>
>> BTW, fl_eventnames appears to be undefined. I see it in commented-out
>> debug prints, but can't find a definition anywhere.
>
> It's in the FL/names.h file. When you include it, that
> variable becomes a global.
>
> (in my previous post, the ".H" should be ".h")
Oh, I see it, I missed it because I did grep *.H.
>> Here's mine:
>
> We should probably add some of those 'bonus' ones you've made.
Go for it. I don't have commit, but I'm happy to declare all the code
under the fltk license. Here's another thing that's been handy:
// RAII style clipping
struct ClipArea {
ClipArea(IRect r) { fl_push_clip(r.x, r.y, r.w, r.h); }
~ClipArea() { fl_pop_clip(); }
};
I use Rect and Point types instead of fltk's separated integers, but
that's irrelevant to the main idea.
> The nice thing about putting these in the include file is they
> don't affect code size (doesn't bloat the library), and only takes
> up space if you include them in your app. (kinda like xpms)
I hadn't thought of that. I'm personally happy to trade a few K for
safety, but I know some people use fltk in low memory situations. If
we stick 'inline' on the functions or put them entirely into the
header, will it have the same effect?
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
