WIN32

#include <fltk/x.h>

The <fltk/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 fltk::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 fltk::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 fltk::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 fltk::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 fltk::msg

The most recent message read by GetMessage (which is called by fltk::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 fltk::xid(const fltk::Window*)

Returns the window handle for a fltk::Window, or zero if not shown().

fltk::Window* fltk::find(HWND xid)

Return the fltk::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 fltk::display;

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

extern HDC fltk::gc;

This is set before draw() is called, or by fltk::Window::make_current(), and can be used as an argument to GDI32 calls.

You may also want the position and size of the window, these can be found by looking at fltk::Window::current(), which returns a pointer to the fltk::Window being drawn.

COLORREF fltk::wincolor(fltk::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 fltk::colorref;
extern HPEN fltk::pen;
extern HBRUSH fltk::brush;

These are set by fltk::color() and by fltk::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 fltk::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!

HRGN fltk::clip_region();

Return the current clip region, or NULL if we are currently clipping to the entire window. Notice that this will be destroyed by the next change to the clipping, copy it if you want to keep it.

void fltk::clip_region(HRGN);

Replace the current clip region with this one, or make there be no clipping if NULL is passed. The old clip region is destroyed.

void fltk::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(fltk::display, MAKEINTRESOURCE(IDI_ICON)));

This only works if called before it is shown using the fltk::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 fltk::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, fltk::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.