H - WIN32-Specific Interface

#include <FL/x.H>

The <FL/x.H> header file defines the interface to FLTK's WIN32-specific functions. Be warned that some of the structures and calls in it are subject to change in future version of FLTK. Try to avoid doing this so your code is portable.

This is the same file that the X-specific interface uses, a #ifdef WIN32 in it causes the win32 header portion to be used. Because many of the system-specific calls have the same names (just different argument) you can write interesting "portable" system specific code.

Fltk creates a single WNDCLASSEX called "FLTK". 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, the idle function, and file descriptor callbacks will not work in this case.

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().

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 our fun-loving friends at MicroSoft decided that calling the handle procedures directly would be a good idea sometimes...)

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.

extern HINSTANCE fl_display;

This is set on program initialization to GetModuleHandle(0) and can be used to identify this application.

extern HWND fl_window;
extern HDC fl_gc;

These are set before draw() is called, or by Fl_Window::make_current(), and can be used as arguments to GDI32 calls.

Notice that fl_window is the window handle. Other information such as the position or size of the window can be found by looking at Fl_Window::current(), which returns a pointer to the Fl_Window being drawn.

COLORREF fl_wincolor(Fl_Color i);

Returns the COLORREF fltk will use for the given fltk color, typically this is RGB(r,g,b) of the color, or PALETTEINDEX(RGB(r,g,b)) if there is a palette.

extern COLORREF fl_colorref;
extern HPEN fl_pen;
extern HBRUSH fl_brush;

These are set by fl_color() and by fl_line_style(), by using these in your drawing calls you can provide the illusion that GDI has a color in it's graphics state.

extern HPALETTE fl_palette;

If non-zero this is the palette alloced by fltk on an 8-bit screen. Hopefully you can ignore this, they managed to find a way to make it more ugly than the X system, which is truly a triumph of software engineering!

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:

This only works if called before it is shown using the Fl_Window::show() method.

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 create a console application (the "/SUBSYSTEM:CONSOLE" option for the linker). This works fine but there is no way to stop Windows from popping up a terminal if you run the program from the GUI.

For a GUI-only application create a WIN32 application (the "/SUBSYSTEM:WINDOWS" option for the linker). FLTK provides a WinMain() function can be overridden by an application and is provided for compatibility with programs written for other operating systems that conform to the ANSI standard entry point main(). This will allow you to build a WIN32 Application without having to change your source files.

Because of problems with the Microsoft Visual C++ header files and/or compiler, you cannot have a WinMain function in a DLL. I don't know why. Thus, this nifty feature is only available if you link to the static library. You may want to compile the souce file fl_call_main.c to a .obj and link it with your program when using the DLL version of fltk.

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. We are not sure why, but we do question the sanity of the software engineers there sometimes. If FLTK is compiled with -DDEBUG then the WinMain will create a console window for your application so you can put printf() statements for debugging or informational purposes.

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.

Cut text contains ^J rather than ^M^J to break lines. This is a feature, not a bug.

The WinMain is a horrid mess and always breaking. This is due to a concentrated effort by MicroSoft to make it impossible to make portable programs without #ifdef statements.