HelpDialog.fl, cxx, and h
The fluid file doesn't match its output files. Both are part of a broken
help system, apparently but its broken for other reasons -- I don't think
the html parser (very cool) is looking for the </HTML> tag, for starters.
More on this in a bit. First...
Sources of sources.
In order for the fluid file to output the .cxx file...
In HelpDialog.fl at line 172 change
// callback {find_pos_ = view_->find(find_->value(), find_pos_);}
callback {find_pos_ = view_->find(find_->text(), find_pos_);}
In HelpDialog.fl at line 172 change
// /*fl_register_images();*/}
fltk::register_images();
} // <- the close brace is part of the code
And in order for the fluid file to output the .h file change
In HelpDialog.fl at line 41 change
// class FL_API HelpDialog {open
class FL_IMAGES_API HelpDialog {open
Note: FL_IMAGES_API is defined in FL_API.h and has the identical definition
but these changes bring the fluid source into sync with its alleged output.
:-)
If value() and text() aren't synonyms in this context, they
probably should be, but again, this doesn't seem to be my bug.
--------------
filename_*.c* files.
This is great for static libs but for dynamic ones the penalty for loading
them all at once is zero.
// in filename_absolute.cxx
FL_API int filename_absolute(char *to, int tolen, const char *from,
const char* cwd=0);
FL_API int filename_relative(char *to, int tolen, const char *from,
const char* cwd=0);
// in filename_name.cxx
FL_API const char *filename_name(const char *);
inline char* filename_name(char* a) {return
(char*)(filename_name((const char*)a));}
FL_API const char *filename_ext(const char *);
inline char* filename_ext(char* a) {return (char*)(filename_ext((const
char*)a));}
// in filename_match.cxx
FL_API bool filename_match(const char *, const char *pattern); // glob
match
// in filename_isdir.cxx
FL_API bool filename_exist(const char*);
FL_API bool filename_isdir(const char*);
FL_API FL_FILESIZE_T filename_size(const char *); // return size of file
FL_API long int filename_mtime(const char *); // return modification time
typedef int (File_Sort_F)(const dirent*const*, const dirent*const*);
// in scandir.c
FL_API int alphasort(const dirent*const*, const dirent*const*);
// in filename_list.cxx
FL_API int casealphasort(const dirent*const*, const dirent*const*);
// in numericsort.cxx
FL_API int casenumericsort(const dirent*const*, const dirent*const*);
FL_API int numericsort(const dirent*const*, const dirent*const*);
FL_API int filename_list(const char *d, dirent ***list); // uses
numericsort
// in filename_list.cxx
FL_API int filename_list(const char *d, dirent ***list, File_Sort_F
*sort);
Alphashort and casealphasort aren't even in the same cxx file.
Let me go check the sizes of the object files (stripped) just
for reference and I'll include the results here for in case
you're interested.
File: `scandir.o'
Size: 440
File: `filename_name.o'
Size: 524
File: `filename_match.o'
Size: 1904
File: `filename_list.o'
Size: 1112
File: `filename_isdir.o'
Size: 1760
File: `filename_ext.o'
Size: 544
File: `filename_absolute.o'
Size: 2396
[Uninitialized data which is allocated at link-time won't
be included in the file size.]
I am dynamic linked (at this time) but I may in fact static
link certain apps later. I'm just thinking about this.
These are great little utilities, by the way. Thanks!
-----------
Ready? What's wrong with HelpView...
The reason the HelpView doesn't work MAY be because it isn't able to
ignore ignore unknown HTML keywords. It should probably count opens
and closes and issue errors if they aren't balanced.
Here's why I think so. If you can, test this.
Change the link in the docs index.html from "html/index.html" to
"preface.html". This will avoid the Doxygen generated docs.
Dunno about you, but for starters I copied my documentation folder to
~/usr32/share/doc/fltk for this test so that the link matched my
customized FLTK_DOCDIR etc. Whatever.
Then fire up fluid and look at the help->manual.
Guess what. No prob.
So the issue is in parsing the Doxygen stuff. No wonder nobody
debugged that thing!! That's as far as I have gotten on this so
far myself. Beautiful parser, by the way. :-)
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
