On 09/02/11 07:32, Manolo Gouy wrote:
> Greg: I don't think FL_INTERNALS should be defined before
> function fl_xid() is called, as implied in your r.9025 doc change.
>
> In files x.H and win32.H, fl_xid() is declared twice according
> to whether FL_INTERNALS is defined or not. In mac.H, it is defined
> outside of the #if defined(FL_INTERNALS)/#endif block.
>
> The system-specific return type of this funtion is defined
> by including x.H, as specified in the OS-issues doc.
It's weird, because the errors refer to Fl_X being
undefined, and the osissues doc for that say to
#define FL_INTERNALS, eg:
--- snipped quote
Note:
Access to the Fl_X hidden class requires to #define FL_INTERNALS before
compilation.
--- snipped quote
> Do you agree ?
Thanks Manolo; it's good this is getting scrutiny.
Perhaps the use of FL_INTERNALS is no longer the recommended
solution? (It has been recommended in the past)
I have no opinion on this, just trying to make sure the docs
reflect the correct use, so when the question comes up, we can
refer to docs.
So the question is:
Is #include <FL/x.H> the recommended way to access fl_xid()?
If so, I can update the fl_xid() docs to mention that.
FWIW, the following little app calls fl_xid(), and compiles OK
on linux/win/mac without FL_INTERNALS, so perhaps that's correct?
--- snip
#include <FL/x.H> // <--
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/fl_ask.H>
int main() {
Fl_Window *win = new Fl_Window(200,200);
win->show();
fl_alert("XID=%p\n", (void*)fl_xid(win)); // <--
return(Fl::run());
}
--- snip
If so, has this always been the case, or is it 1.3.0 specific?
(docs should probably mention if it's the latter case)
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
