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().
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
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.
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.
Set the allowable range the user can resize this window to. This only
works for top-level windows.
If this function is not called, FLTK tries to figure out the range
from the setting of resizable():
- 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
It is undefined what happens if the current size does not fit in the
constraints passed to size_range().
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
- 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).
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.
Remove the window from the screen. If the window is already hidden or
has not been shown then this does nothing and is harmless.
Returns non-zero if show() has been called (but not hide()
). You can tell if a window is iconified with (w->shown()
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.
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
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.
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.
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).
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.
Turns off any side effects of fullscreen() and does
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.
clear_border() is a fast inline function to turn the border
off. It only works before show() is called.
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
Returns true if this window is 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.
Returns true if this window is modal or non-modal.
Gets or sets the window title bar label.
Gets or sets the icon label.
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.
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
Returns the last window that was made current.
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
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.
From Guillaume, 15: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, 01: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 );
// 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
[ Reply ]
From mike, 07: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, 22:22 Jan 11, 2003 (score=3)
Child windows should be remove()ed from their parten before you delete the object.
[ Reply ]
From cdeepakroy, 15: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, 02: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://news.easysw.com
[ Reply ]
From Ben, 07: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 ]