The unused function was commented out about 6 months ago, see
svn r 10123. No changes other than comments and white space.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@10265 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
that blocked a user of the Fl_Browser widget (see "fl_draw MAXBUF limit" in fltk.coredev).
Also, removed a useless computation in string expansion that checked for valid UTF-8 sequences:
the point is that a valid UTF-8 sequence for a non-ascii char contains no ascii char,
thus no tab, space, control, & or @ we want to process differently.
Also, invalid UTF-8 sequences are copied unchanged by this procedure.
Therefore, checking for tab, space, control, & or @, and copying the byte otherwise, is enough.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@10123 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This fix to fl_height(int,int) solves the "digital drit"
problem in Fl_Text_Editor, where doing insert/delete
operations was leaving a trail of dead pixels.
Also fixes problem with font display problem in fluid's
code editor. See the STR for screenshots of the problem.
NOTE: THIS IS A WORKAROUND FOR A DEEPER PROBLEM.
Somewhere during the port of UTF8, the actual pixel size
of the displayed font is a little off, causing FLTK to
miscalculate line height, causing 'digital drit'.
It used to be that when you specified a font size,
the font's actual displayed pixel size matched the
font size value.
This fix makes the fl_height(int,int) function more robust,
actually inquiring the font system for its font size, instead
of assuming the font size is the same as the 'size' argument.
Since Fl_Text_Editor makes use of this function, it helps
that widget calculate font sizes correctly.
The real fix will be restoring FLTK's old behavior where the
font size specified is the actual pixel size of the displayed font.
Then this function can be reverted to just returning the 'size' argument.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6845 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
most of the function names used as indented paragraph titles
are now recognised properly and are shown as links. However,
I was forced to "downgrade" many function() references in the
text so that the unwary user isn't unexpectedly teleported off
the tutorial pages. It reduces the link spaghetti a lot,
tweaked Enumerations.H and fl_draw.cxx to get doxygen to recognise
more function names used in drawing.dox. only fl_scroll(...)
and the offscreen drawing functions still needed for drawing.dox
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6735 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
This one was really tough to track, understand:
In fact,
the problem was comming from the misplacement of the menu window,
which itself came from invalid measurement,
which itself came from invalid fl_witdh() measurement,
but only when fl_gc is not valid because fl_width() relies on Win32 on the call
of GetTextExtentPoint32W which can't succeed if the HDC(here fl_gc) is not valid !
Now the fix:
A best-effort algorithm has been furthered to supply a valid fltk hdc if we can have one or a screen hdc if no fltk window is found by fl::first_window().
Note that when fl_gc is NULL inside fl_width() call, it can happen that Fl_Window::current() is not null but invalid (already deleted).
Finally, in the case of the buggy menu window observed here, this fl_gc was set to NULL just after an Fl_Menu_Window deletion and re-creation in Fl_Menu_Item::pulldown().
Also added a comment to describe the new fl_width() behavior.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6540 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
- Fixed recent documentation update problems in fl_draw.cxx : \ and @ char must be doubled otherwise interpreted as doxygen keywords
- Fixed some doxygenized parameters problems in Fl_Preferences.cxx
- Added the treeview mode, now featuring a vertical left tree browser in html doc
- Splitted html configuration file from pdf configuration file, now a new Doxybook config file permits to customize independtly both html and pdf modes without risking side effects and also without assuming an fltk user will have the Tex tools installed to generate the html doc. Now only pdf generation will need LaTex tools.
- Updated the doxygen based documentation to revison 9 and added new significant contributors to index.dox in alphabetical order.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3@6539 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
- made the Tooltip hide code a little bit smarter
- Added subwindow test case to Fl_Tabs
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@5378 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
src/fl_draw.cxx:
- fl_measure(): use "h" instead of "min(w,h)", since "w" is
usually 0.
src/Fl_Menu.cxx:
- Revert previous "fix" in Fl_Menu_Item::measure()
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@4070 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
and strncat() in almost all places (there are still a few strncpy's
that need to be used...)
Added configure check for strlcat() and strlcpy().
Added emulation code for strlcat() and strlcpy().
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@2239 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
methods/constants to support Fl_Output as a special case of Fl_Input
(you can do everything but change the text in Fl_Output...)
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.1@2073 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
