FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  ]

class Fl_Window

Class Hierarchy

Include Files

    #include <FL/Fl_Window.H>


This widget produces an actual window. This can either be a main window, with a border and title and all the window management controls, or a "subwindow" inside a window. This is controlled by whether or not the window has a parent().

Once you create a window, you usually add children Fl_Widget 's to it by using window->add(child) for each new widget. See Fl_Group for more information on how to add and remove children.

There are several subclasses of Fl_Window that provide double-buffering, overlay, menu, and OpenGL support.

The window's callback is done if the user tries to close a window using the window manager and Fl::modal() is zero or equal to the window. Fl_Window has a default callback that calls Fl_Window::hide().


Fl_Window::Fl_Window(int w, int h, const char *title = 0)
Fl_Window::Fl_Window(int x, int y, int w, int h, const char *title = 0)

Creates a new window. If Fl_Group::current() is not NULL, the window is created as a subwindow of the parent window.

The first form of the constructor creates a top-level window and asks the window manager to position the window. The second form of the constructor either creates a subwindow or a top-level window at the specified location, subject to window manager configuration. If you do not specify the position of the window, the window manager will pick a place to show the window or allow the user to pick a location. Use position(x,y) or hotspot() before calling show() to request a position on the screen. See Fl_Window::resize() for some more details on positioning windows.

Top-level windows initially have visible() set to 0 and parent() set to NULL. Subwindows initially have visible() set to 1 and parent() set to the parent window pointer.

Fl_Widget::box() defaults to FL_FLAT_BOX. If you plan to completely fill the window with children widgets you should change this to FL_NO_BOX. If you turn the window border off you may want to change this to FL_UP_BOX.

virtual Fl_Window::~Fl_Window()

The destructor also deletes all the children. This allows a whole tree to be deleted at once, without having to keep a pointer to all the children in the user code. A kludge has been done so the Fl_Window and all of its children can be automatic (local) variables, but you must declare the Fl_Window first so that it is destroyed last.

void Fl_Window::size_range(int minw, int minh, int maxw=0, int maxh=0, int dw=0, int dh=0, int aspect=0)

Set the allowable range the user can resize this window to. This only works for top-level windows.
  • minw and minh are the smallest the window can be. Either value must be greater than 0.
  • maxw and maxh are the largest the window can be. If either is equal to the minimum then you cannot resize in that direction. If either is zero then FLTK picks a maximum size in that direction such that the window will fill the screen.
  • dw and dh are size increments. The window will be constrained to widths of minw + N * dw, where N is any non-negative integer. If these are less or equal to 1 they are ignored. (this is ignored on WIN32)
  • aspect is a flag that indicates that the window should preserve its aspect ratio. This only works if both the maximum and minimum have the same aspect ratio. (ignored on WIN32 and by many X window managers)
If this function is not called, FLTK tries to figure out the range from the setting of resizable():
  • If resizable() is NULL (this is the default) then the window cannot be resized and the resize border and max-size control will not be displayed for the window.
  • If either dimension of resizable() is less than 100, then that is considered the minimum size. Otherwise the resizable() has a minimum size of 100.
  • If either dimension of resizable() is zero, then that is also the maximum size (so the window cannot resize in that direction).
It is undefined what happens if the current size does not fit in the constraints passed to size_range().

virtual void Fl_Window::show()
void Fl_Window::show(int argc, char **argv)

Put the window on the screen. Usually this has the side effect of opening the display. The second form is used for top-level windows and allows standard arguments to be parsed from the command-line.

If the window is already shown then it is restored and raised to the top. This is really convenient because your program can call show() at any time, even if the window is already up. It also means that show() serves the purpose of raise() in other toolkits.

virtual void Fl_Window::hide()

Remove the window from the screen. If the window is already hidden or has not been shown then this does nothing and is harmless.

int Fl_Window::shown() const

Returns non-zero if show() has been called (but not hide() ). You can tell if a window is iconified with (w->shown() && !w->visible()).

void Fl_Window::iconize()

Iconifies the window. If you call this when shown() is false it will show() it as an icon. If the window is already iconified this does nothing.

Call show() to restore the window.

When a window is iconified/restored (either by these calls or by the user) the handle() method is called with FL_HIDE and FL_SHOW events and visible() is turned on and off.

There is no way to control what is drawn in the icon except with the string passed to Fl_Window::xclass(). You should not rely on window managers displaying the icons.

void Fl_Window::resize(int,int,int,int)

Change the size and position of the window. If shown() is true, these changes are communicated to the window server (which may refuse that size and cause a further resize). If shown() is false, the size and position are used when show() is called. See Fl_Group for the effect of resizing on the child widgets.

You can also call the Fl_Widget methods size(x,y) and position(w,h), which are inline wrappers for this virtual function.

A top-level window can not force, but merely suggest a position and size to the operating system. The window manager may not be willing or able to display a window at the desired position or with the given dimensions. It is up to the application developer to verify window parameters after the resize request.

void Fl_Window::free_position()

Undoes the effect of a previous resize() or show() so that the next time show() is called the window manager is free to position the window.

void Fl_Window::hotspot(int x, int y, int offscreen = 0)
void Fl_Window::hotspot(const Fl_Widget*, int offscreen = 0)
void Fl_Window::hotspot(const Fl_Widget&, int offscreen = 0)

position() the window so that the mouse is pointing at the given position, or at the center of the given widget, which may be the window itself. If the optional offscreen parameter is non-zero, then the window is allowed to extend off the screen (this does not work with some X window managers).

void Fl_Window::fullscreen()

Makes the window completely fill the screen, without any window manager border visible. You must use fullscreen_off() to undo this. This may not work with all window managers.

int Fl_Window::fullscreen_off(int x, int y, int w, int h)

Turns off any side effects of fullscreen() and does resize(x,y,w,h).

int Fl_Window::border(int)
uchar Fl_Window::border() const

Gets or sets whether or not the window manager border is around the window. The default value is true. border(n) can be used to turn the border on and off, and returns non-zero if the value has been changed. Under most X window managers this does not work after show() has been called, although SGI's 4DWM does work.

void Fl_Window::clear_border()

clear_border() is a fast inline function to turn the border off. It only works before show() is called.

void Fl_Window::set_modal()

A "modal" window, when shown(), will prevent any events from being delivered to other windows in the same program, and will also remain on top of the other windows (if the X window manager supports the "transient for" property). Several modal windows may be shown at once, in which case only the last one shown gets events. You can see which window (if any) is modal by calling Fl::modal().

uchar Fl_Window::modal() const

Returns true if this window is modal.

void Fl_Window::set_non_modal()

A "non-modal" window (terminology borrowed from Microsoft Windows) acts like a modal() one in that it remains on top, but it has no effect on event delivery. There are three states for a window: modal, non-modal, and normal.

uchar Fl_Window::non_modal() const

Returns true if this window is modal or non-modal.

void Fl_Window::label(const char*)
const char* Fl_Window::label() const

Gets or sets the window title bar label.

void Fl_Window::iconlabel(const char*)
const char* Fl_Window::iconlabel() const

Gets or sets the icon label.

void Fl_Window::xclass(const char*)
const char* Fl_Window::xclass() const

A string used to tell the system what type of window this is. Mostly this identifies the picture to draw in the icon. Under X, this is turned into a XA_WM_CLASS pair by truncating at the first non-alphanumeric character and capitalizing the first character, and the second one if the first is 'x'. Thus "foo" turns into "foo, Foo", and "xprog.1" turns into "xprog, XProg". This only works if called before calling show().

Under Microsoft Windows this string is used as the name of the WNDCLASS structure, though it is not clear if this can have any visible effect. The passed pointer is stored unchanged. The string is not copied.

void Fl_Window::make_current()

make_current() sets things up so that the drawing functions in <FL/fl_draw.H> will go into this window. This is useful for incremental update of windows, such as in an idle callback, which will make your program behave much better if it draws a slow graphic. Danger: incremental update is very hard to debug and maintain!

This method only works for the Fl_Window and Fl_Gl_Window classes.

static Fl_Window* Fl_Window::current()

Returns the last window that was made current.

void Fl_Window::cursor(Fl_Cursor, Fl_Color = FL_WHITE, Fl_Color = FL_BLACK)

Change the cursor for this window. This always calls the system, if you are changing the cursor a lot you may want to keep track of how you set it in a static variable and call this only if the new cursor is different.

The type Fl_Cursor is an enumeration defined in <FL/Enumerations.H>. (Under X you can get any XC_cursor value by passing Fl_Cursor((XC_foo/2)+1)). The colors only work on X, they are not implemented on WIN32.

User Comments [ Add Comment ]

From Guillaume, 18:50 Sep 13, 2010 (score=3)

Why do the buttons to minimize, maximize and close a window in the top-right hand corner disappear when set_modal() is called on a Fl_Window? Is it a bug or is it the expected behavior?

I'm on Windows.

Reply ]

From enzo2, 04:25 Sep 09, 2008 (score=3)

How works cursor() ?

I want to use cursor to show a work in progress ( using hourglass shape)

in my callback i set somethink like this:

void MainWindow::callback_InvioMessaggio (Fl_Button * w, void *data )
    MainWindow* win = (MainWindow*) (( structWidgetData * ) data)->mwin;
    fl_cursor( FL_CURSOR_WAIT );
    win->myProc( );
    // fl_cursor( FL_CURSOR_DEFAULT );

I would expected that the cursor_wait will be show before the start of myProcs , to show that the work is in progress.
Instead the cursor shaped is changed only after the end of myProc and this is useless.

How can I change the cursor shape before the start of the routine and restore it at its end ?

BTW I'm using FLTK 1.3.x-r6162 on redhat 7.3 and gcc 3.4.6

regards, Enzo
Reply ]

From mike, 10:31 Sep 09, 2008 (score=3)

Better to post questions like this to the fltk.general forum.

That said, call Fl::flush() or Fl::check() to get the cursor changes to take effect.
Reply ]

From Dejan Lekic, 01:22 Jan 12, 2003 (score=3)

Child windows should be remove()ed from their parten before you delete the object.
Reply ]

From cdeepakroy, 18:14 Nov 24, 2004 (score=1)

i want to know whether FLTK Windows hav any in-built horizontal scrollbar functionality as MFC windows do.

IF in-built scrolling functionality is not present then if you have too many child controls that fit well in a window at a higher resolution( say 1600 x 1200 ) - but when u see the same window at a lower resolution ( say 640 x 480 ) a few controls placed beond the new desktop width and height would be masked and become unaccessible. This can be solved easily and quickly without much hastle if the window has in-build scrolling functionality.

I know that this functionality can be implemented by placing two scrollbars - horizontal and vertical at the right and bottom extremes of the window and probably the window could be displayed accordingly by setting top - left as dictated by the scrollbar position. I also have a doubt whether a window with say [ top = 0 , left = 0 , right = 100 , bottom = 100 ] be displayed as [ top = 50 , left = 50 , right = 100 , bottom = 100 ]. bcos i can implement the window scrolling functionality only if this is possible.

Please let me know if this problem can be solved in a different way.

I would be very happy to know if FLTK windows have in-build scrolling functionality bcos i searched the documentationa  lot for it. the FL_window class does nto seem to support it as appears from the documentation.

Please help me.

Deepak Roy Chittajallu
Reply ]

From greg.ercolano, 05:43 May 10, 2007 (score=3)

Sounds like you'd want to use an Fl_Scroll widget inside the window to manage scrolling of your content.

Best place to ask for help is on the fltk.general newsgroup. Point your news reader to: news://

Reply ]

From Ben, 10:57 Aug 12, 2003 (score=1)

border() on X after the window has been shown can have strange effects. Lots of messages are sent to X, resizing the window and so on. border() is also called from fullscreen_off() - the window may be resized up to four times when this is called!
Reply ]


Comments are owned by the poster. All other content is copyright 1998-2015 by Bill Spitzak and others. This project is hosted by Seriss Corporation. Please report site problems to ''.