I believe there's a misunderstanding about STR 2696: File fltk_wrap.cpp (whose content I ignore) seems to contain (not to call) an fl_xid() function. To program such a function, access to the Fl_X structure is needed, and FL_INTERNALS should be defined for that.
But a normal API-using program does not reprogram fl_xid() (because it's in the library) but just calls it. For that, there's no need to define FL_INTERNALS. So, I believe the doc should not say that FL_INTERNALS must be defined to call function fl_xid(). Also, fl_xid() was part of the API and declared in x.H already in 1.1, without need for any extra symbol definition. > 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 _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
