A single WNDCLASSEX called "FLTK" is created. All Fl_Windows are of this class. This window class is created the first time Fl_Window::show() is called.
You can probably combine fltk with other libraries that make their
own MSWindows window classes. The easiest way is to call Fl::wait(), it
will call DispatchMessage for all messages to the other windows. If
necessary you can let the other library take over (as long as it calls
DispatchMessage()), but you will have to arrange for the function
Fl::flush() to be called regularily (otherwise widgets will not
update), and timeouts and the idle function will not work.
Return the Fl_Window that corresponds to the given window handle,
or null if not found. This uses a cache so it is slightly faster than
iterating through the windows yourself.
When the virtual function Fl_Widget::draw() is called, fltk has
stashed in some global variables all the silly extra arguments you
need to make a proper GDI call. These are:
It may also be useful to refer to To not produce a "console" window when you run your program add the
following secret incantation to the Micro$oft linker:
Unfortunately this seems to completely disable stdin/stdout, even
if you run the program from a console. So don't do this until you
have debugged your program!
I use capital C as the extension for c++ source code, for instace
for Fluid output. Unfortunately there is no way to convince VC++ to
use this except to tell it to compile *everything* using C++ by
putting the switch "/TP" in the options. This makes it impossible to
combine old C code and fltk code.
If program is deactivated, Fl::wait() does not return until it is
activated again, even though many events are delivered to the program.
This can cause idle background processes to stop unexpectedly. This
also happens while the user is dragging or resizing windows or
otherwise holding the mouse down. I was forced to remove most of the
efficiency fltk uses for redrawing in order to get windows to update
while being moved. This is a design error in MSWindows and probably
impossible to get around.
Fl_Gl_Window::can_do_overlay() returns true until the first time it
attempts to draw an overlay, and then correctly returns whether or not
there is overlay hardware.
Cut text contains ^J rather than ^M^J to break lines. This is a
feature, not a bug.
I can't seem to get SetCapture (used by Fl::grab()) to work, and I
can't find a way to stop the main window title from turning gray while
menus are popped up.
glpuzzle program does not animate unless you resize it first. Unknown why.
Fl_Window::fullscreen() not implemented (should take over the screen
without a title bar). Currently does maximize instead.
Import .bmp files into fluid. Wonko has the specs.
Can't set icon of windows.
extern MSG fl_msg;
The most recent message read by GetMessage (which is called by
Fl::wait(). This may not be the most recent
message sent to an fltk window, because silly MSWindows calls the
handle procedures directly for some events (sigh).
void Fl::add_handler(int (*f)(int));
Install a function to parse unrecognized messages sent to fltk
windows. If fltk cannot figure out what to do with a message, it
calls each of these functions (most recent first) until one of them
returns non-zero. The argument passed to the fuctions is zero. If
all the handlers return zero then fltk calls DefWindowProc(...).
HWND fl_xid(const Fl_Window*);
Returns the window handle for a Fl_Window, or zero if not shown().
Fl_Window* fl_find(HWND xid)
Drawing things using the MSWindows GDI
extern HINSTANCE fl_display;
extern HWND fl_window;
extern HDC fl_gc;
COLORREF fl_RGB();
HPEN fl_pen();
HBRUSH fl_brush();
These global variables are set before draw() is called, or by Fl_Window::make_current() You can
refer to them when needed to produce GDI calls. Don't attempt to
change them. The functions return GDI objects for the current color
set by fl_color(), these are created as needed and cached. A typical
GDI drawing call is written like this:
DrawSomething(fl_gc, ..., fl_brush());Fl_Window::current()
to get the window's size or position.
How to not get a MSDOS console window
MSWindows has a really stupid mode switch stored in the executables that
controls whether or not to make a console window (hint to Mr Gates:
why not leave it hidden until the program prints something?).
/SUBSYSTEM:WINDOWS /ENTRY:mainCRTStartup
Other hints
Known bugs