WIN32-Specific Interface

Handling Other WIN32 Messages

By default a single WNDCLASSEX called "FLTK" is created. All Fl_Windows are of this class unless you use Fl_Window::xclass(). The window class is created the first time Fl_Window::show() is called.

You can probably combine FLTK with other libraries that make their own WIN32 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 so that widgets are updated, timeouts are handled, and the idle functions are called.

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 WIN32 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)

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.

Drawing Things Using the WIN32 GDI

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:

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() and are created as needed and cached. A typical GDI drawing call is written like this:

DrawSomething(fl_gc, ..., fl_brush());

It may also be useful to refer to Fl_Window::current() to get the window's size or position.

Setting the Icon of a Window

FLTK currently supports setting a window's icon *before* it is shown using the Fl_Window::icon() method.

void Fl_Window::icon(char *)

Sets the icon for the window to the passed pointer. You will need to cast the HICON handle to a char * when calling this method. To set the icon using an icon resource compiled with your application use:

window->icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(IDI_ICON)));

How to Not Get a MSDOS Console Window

WIN32 has a really stupid mode switch stored in the executables that controls whether or not to make a console window.

To always get a console window you simply create a console application (the "/SUBSYSTEM:CONSOLE" option for the linker). For a GUI-only application create a WIN32 application (the "/SUBSYSTEM:WINDOWS" option for the linker).

FLTK includes a WinMain() function that calls the ANSI standard main() entry point for you. This function creates a console window when you use the debug version of the library.

WIN32 applications without a console cannot write to stdout or stderr, even if they are run from a console window. Any output is silently thrown away.

Known Bugs

If a 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 WIN32 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.

SetCapture (used by Fl::grab()) doesn't work, and the main window title bar turns gray while menus are popped up.

FLUID does not support BMP files yet.