Fire Windows
Fire Windows
This chapter describes how windows are created and managed within the Fire language.
Windows are the basic means by which Fire communicates with the operator. Windows are rectangular in shape and comprise a data area, often referred to as thewindow contents, surrounded by a frame supplied by the window manager.
When Fire is deployed in 3rd party situations, e.g. within a browser or ActiveX container, typically no outer frame is supplied by the third party application.
The contents of a window are determined by its use within the Fire language and can be one of several different types including: graphic, alpha, display, panel, table, tree, web, each having different attributes and behavior.
In stand-alone situations, the frame surrounding a window is supplied by the window manager and has the same appearance irrespective of the window’s contents. It can contain a title and various buttons and controls with which the operator can move, resize, minimize, maximize or delete the window. The visual graphics of the frame surround are determined by the type of window manager, which is outside the scope of this user guide, but commonly-used window managers are Windows (Microsoft) and Motif for Unix systems.
Below are 2 examples of a Fire alpha window within window manager frames.
Microsoft Windows |
Unix (Motif) |
 |
 |
We shall see later how we can customize the window surround.
This chapter is restricted to a discussion on the general aspects of Fire windows. Aspects relating to particular window contents (graphic, alpha, panel etc.) is left to later chapters.
In every Fire session a maximum of 255 user-defined windows can be created, of which 32 can be graphic windows. Consequently there are 255 window slots available. These slots can be referenced within the language by the predefined system window identifiers win1 through win255.
Initially all 255 window slots are unallocated, i.e. they have not yet had their contents defined, e.g. graphic, alpha, panel etc. They are known as free windows.
To allocate a window, a window creation command is used. There is one allocation command corresponding to each of the different types of Fire window:
walpha a window with text contents
wcomponent a window with third party object contents
wdisplay a window with raster image contents
wgraphic a window with vector graphic contents
wpanel a window with gui contents
wtab a window with property sheet contents
wtable a window with tabular gui contents
wtree a window with tree hierarchy contents
wweb a window with browser contents
When a window is allocated, it becomes visible (realized), although this visibility can be deferred as we shall see in a later section.
To use an example, the command wgraphic will "create" a window with graphic contents.
Although we describe it as "window creation" this is a bit of a misnomer. It should really be referred to as "window allocation" since the 255 windows are always in the system, they just have not all been allocated yet. Only allocated windows can be visible on the screen.
Each of the above-listed allocation commands when used without an assignment, like wgraphic in our example, grabs the first unallocated slot from the 255 available and allocates it. This may be slot 2 if slot 1 is in use, with the result that the system window identifier win2 may then be used to reference the new graphic window and its attributes.
A window is de-allocated by the wdelete command. This has the effect of removing it from view if necessary and freeing the appropriate window slot, e.g. wdelete win2.
If the window in question has not yet been allocated, the wdelete command has no effect. Window de-allocation is often referred to as "window deletion".
We have seen how there are 255 system window identifiers. User identifiers may also be created to reference a window but like the system identifiers they are just references to the 255 window slots. In fact a new window identifier created without an assignment will not even reference one of the slots, it is initially undefined, i.e. null. e.g.
window mywin tell mywin
This will display the value "null". There is a also a system identifier win0 which has the same meaning as null.
A user-defined window identifier is the usual way of referencing a window since an application does not always know which slot has been grabbed when a new window is allocated. Unless the application does not want to allocate a window immediately (this is unusual), the creation of a window identifier is usually combined with an assignment:
window mywin = win4
although this type of assignment is a bit dangerous because win4 may have already been allocated for another purpose.
Instead, it is common for a new window identifier to be initialized to the next unallocated window slot. This is achieved by referencing a system window identifier free_window which acts as a function by searching the window slots for a free one:
window mywin = free_window
The window should then be allocated immediately to ensure that it is not grabbed by another application or command:
window mywin = free_window mywin = wgraphic
Although this looks like a normal window assignment, when the right-hand side of a window assignment is a window allocation command, it has the effect of allocating the contents of the window slot indicated by the left-hand side of the assignment (in this case mywin).
In fact the last example may be abbreviated to:
window mywin = wgraphic
because if an attempt is made to allocate a window identifier with a null value, an implicit assignment to free_window is first made.
An good understanding of the relationship between window identifiers, window slots and window allocation is crucial during application development.
Remember that creating a window identifier does not create a physical window, but just creates a reference to one of the 255 slots. Two or more window identifiers may reference the same window slot and therefore the same physical window.
Allocating a window via an assignment will not always grab a free window slot. It will allocate the slot indicated by the left-hand side of the assignment. Only if this has a null value will a new slot be grabbed. If the left-hand side of the assignment is not null, i.e. if it already references one of the 255 slots, then that slot will be allocated, which may automatically invoke a window deletion (de-allocation) if the slot is already allocated.
De-allocating a window automatically zeroizes all window identifiers pointing to it, e.g.
window mywin = wgraphic wdelete mywin
After this, mywin will have a null value.
Window identifiers may be used within logical expressions (if, while, etc.), e.g.
if (mywin == yourwin) { !They point to the same window }
and when used in isolation a window identifier will return a true value if it references a window slot, or false if its value is null:
window mywin
# At this stage mywin is null
mywin = wgraphic
# At this stage mywin will point to a slot (e.g. win4)
# or may be still be null if the allocation failed
# perhaps because all 255 slots were busy.
unless (mywin) {
!Window allocation failed
}
A Fire window is a system structure with a large number (80+) of elements, sometimes called attributes or properties. They enable you to examine and modify window characteristics.
These elements are usually classified into generic and type-dependent elements. Generic elements reference attributes common to all types of window. Such elements may be referenced by the language before and/or after window allocation, and include such attributes as window size, position, title, icon information and visibility.
Some generic elements may be set prior to window allocation, others can only be set after. Some are maintained by the system and are read-only to the language. Type-dependent elements are available only after window allocation.
The element window.id, a numeric value, records the window slot number (1 through 255) occupied by a window. The element window.style, records the window type in the form of a text string. Both these elements are system-maintained.
Different window types (graphic, alpha etc.) have different type-dependent attributes, e.g. graphic windows have an element window.view which records the current view of the graphic database visible in the window, which is meaningless for an alpha window which merely displays text.
We shall meet the other elements during the next sections. For a full list, consult the relevant windows section in the Fire Reference Manual.
The frame added to a window by the window manager at allocation time has controls which identify the window to the operator and permit the window to be reconfigured. Such reconfiguration is not always desirable, so Fire permits certain aspects of the frame to be controlled.
The frame has a move-bar containing a text title. This title can be set at window allocation time by the following:
window mywin = wgraphic -tit='Hello World'
This would produce the following window with frame:
The above graphic window includes a menu-bar in its contents which is automatically added to graphic windows. Menu-bars can be included or suppressed on a per-window basis and are discussed later.
If no title is provided, Fire will use a default, which describes the type of window being created.
By default, the title is preceded by the window slot number. This prefix can be suppressed by setting a system numeric identifier window_numbers to 0, but the behavior will then apply to all windows created in the Fire session. As an alternative, the window numbering can be suppressed on a per-window basis by use of the -no_num switch on the window allocation command:
window mywin = wgraphic -tit='Hello World',-no_num
The element window.title_numbered records whether a window’s title contains the slot number. The element window.title enables the title to be perused or changed post-creation.
The default window manager frame (seen above) includes controls for changing the size of a window interactively. Often a window should be restricted to a fixed size and the window manager can be told to suppress the resize controls by adding the -fix switch to the window allocation command:
window mywin = wgraphic -tit='Hello World',-fix
After window allocation, the resize controls can be added and removed (on Unix systems only) by means of the window.resizable element. Setting this to 0 will remove resize controls, setting it to 1 will add them.
Much of the window manager frame can be suppressed totally if required by use of a "decoration" switch on the allocation command:
window mywin = wgraphic -no_dec
As can be seen, this suppresses the move-bar (with title) and other buttons from the frame but leaves the outer frame with resize controls, although these too can be suppressed:
window mywin = wgraphic -no_dec,-fix
For finer grain control, you can suppress various buttons and capabilities from windows with the -dec switch. Consult the Reference Manual for details.
Fire permits windows within windows. Such sub-windows have a minimal border around them but are not known to the window manager, who is only bothered with top-level windows. Consequently they have no decoration. The -no_dec switch may be used to suppress their minimal border if required.
Influence over window manager policy is not always permitted. Although the commands discussed so far function correctly with Windows and Unix/Motif, there is no guarantee that other window managers will always be as cooperative. For example not all window managers permit the suppression of resize controls or even the title bar. Some window managers do not even have the concept of variable decoration configuration.
Once allocated, a visible window is in one of two states: normal, sometimes referred to as open, or iconized/minimized, sometimes referred to as closed.
A window in its normal state is shown in full, that is its contents and window manager frame surround are fully visible. In addition, some window managers permit a window to be resized to full-screen (aka maximized).
A window in an iconized (or minimized) state is displayed in a reduced form somewhere along the edge of the workstation screen. The position of the icon on the desktop is determined by the window manager:
Microsoft Windows displays icons in the bottom left. This is the default behavior. If you wish the icon for a window to appear in the Windows taskbar, the window creation switch -tb is available. Use of this switch also ensures that the taskbar icon is visible irrespective of the window state (open or closed). Without this switch, the icon is visible on the desktop only when the window is closed (minimized).
Unix window managers usually display icons down the left edge of the desktop.
Examples:
MS Windows (desktop):
MS Windows (taskbar):
Unix:
By default Fire chooses an icon title and icon image appropriate for the particular window type.
Each window when minimized has its own icon. However a window can be marked as a master window by a -mas switch on its allocation command. When a master window is minimized Fire minimizes all windows into one icon (on Unix) or onto the taskbar (on Microsoft Windows). This facility enables one window to encapsulate an application. It is then equivalent to clicking the File/Minimize All option in the monitor window.
By default, newly allocated windows are opened in normal form. To indicate that a newly allocated window be shown in an iconized form, the -ic switch is used, e.g.
window mywin = wgraphic -ic
After window allocation, the window.open element monitors the current iconic state of the window. Changing the value of this element will change the state of the window accordingly. The commands wopen and wclose are also available and perform the same functions. The following command lines are therefore equivalent:
mywin.open = 1 wopen mywin
and similarly
mywin.open = 0 wclose mywin
The window manager usually provides ways to iconize and de-iconize interactively via appropriate button controls in a window’s frame surround. The iconize / mimimize button is usually in the top-right corner of the frame on the title bar, as shown in the illustration at the beginning of this chapter.
The attributes associated with a window’s icon are usually customizable, although some window managers put restrictions on what you can change.
An icon’s position on the desktop is determined by the value of the element window.icon_rect . This is a numeric array providing the x,y coordinates of the top-left and bottom-right corners of where the icon is to be located. Not all window managers take notice of icon positioning since they like to maintain control, and most do not allow the size to vary. For those window managers which do take heed, the position could be specified by a command such as,
mywin.icon_rect = <0,200>
which would position the icon along the left edge of the desktop.
The default position of an icon is purely down to the policy of the window manager.
The text displayed alongside (or below) an icon is determined by the value of the element window.icon_name. Typically you would supply a name describing the window’s function.
The default icon name for a window depends on the window’s type, and is constructed by a mnemonic of the window type and its window slot number.
The image displayed in an icon is determined by the value of the element window.icon. This is a string value with the name of an image file.
On Microsoft Windows, any image is permitted and the window manager will scale it down to its standard icon size, typically 16 x 16 pixels. This image is also displayed in the top corner of the window when displayed in its normal state.
On Unix systems, the image must be a monochrome image and will be clipped if it is larger than the standard size, typically 64 x 64 pixels.
Consider the following customization:
mywin.icon_name = 'mywin' mywin.icon = 'globtel.ico'
which would produce the following desktop icon on a Windows system:
The Master Icon is displayed when all windows are minimized at once, either by clicking the File/Minimize All option in the monitor window, or by minimizing a window which was declared as a master window via the -mas switch.
On Unix systems, the Master Icon looks like any other icon, but on Microsoft Windows, the Master Icon is displayed in the taskbar and will look like this:
Customization of this icon is possible by setting the values of 2 system string identifiers, icontray_title and icontray_image, e.g.
icontray_title = 'Mapping App' icontray_image = 'globtel.ico'
would change the Master Icon into:
On Windows systems the Master Icon by default is not displayed in the taskbar unless Fire is minimized. This behavior can be changed by setting the icontray_display identifier to 1, which will always display the Master Icon irrespective of minimization.
A typical Fire application does not require all windows to be active at all times. By active we mean available for a user to select from.
A window can be inactive if it is invisible. This is the most drastic, and obvious, case of inactivity. Alternatively it can remain visible, but unavailable to selection by the mouse. This state is known as ghosted, where buttons and labels in the window are visible but shown in a faded form. Trying to press a ghosted button has no effect.
Similar to the way a window can be created in iconic form, a window can be made invisible at allocation time, by using the "invisible" switch (-inv) on the allocation command:
window mywin = wgraphic -inv
Once allocated, an invisible window can be made visible (or vice-versa) by changing the value of its window.visibility element, e.g.
mywin.visibility = 1
By default newly allocated windows are always visible.
Ghosting is very similar; the -gh switch being available at allocation time, and the window.ghosted element being available for subsequent ghosting or unghosting of the window. New windows are initially unghosted, i.e. window.ghosted = 0.
A window can be both invisible (and/or ghosted) and iconised at allocation time if this is a requirement of the application. When made visible, it will appear in iconic form.
Even if a window is logically visible, it may not be actually visible if it lies behind another window on the screen. It may be totally obscured or just partially obscured. There are 2 commands: wexpose and whide, which adjust a window’s stacking order on the screen:
wexpose will pop a window, i.e. bring it to the top of the window stack so that it is no longer obscured by other windows.
whide will push a window to the bottom of the window stack, thus popping any other windows which were previously obscured by it.
On Microsoft Windows systems, another method of controlling a window's position in the stack is via its Z order. With this element, window.z_order, the window manager can be told to keep the window always on top (value 1), always on the bottom (value -1), or don't care (value 0). New windows have a Z order of 0.
If multiple windows have a Z order of 1, i.e.always on top, it is at the window manager's discretion which of these is actually the topmost. This is beyond the control of Fire.
Although its language is procedural in concept, Fire is very much an event-driven system whereby applications are written to react to events raised by the user, e.g. the pressing of a window button or the interactive resizing of a window.
Interaction with Fire windows, i.e. the handling of window events, is achieved through procedures known as callbacks. In other languages, the terminology often used is event handlers. When a window event occurs, the callback is executed.
The events common to all window types which can have associated callbacks are as follows:
callback
event
when one of a window's menubar buttons is clicked
when a window' state changes from iconic to a normal
when a window is deleted
when a window's Help menubar button is clicked
when a window's state changes from normal to iconic state (gets minimized)
when a window's position changes
when a window's width and/or height changes
There are other type-dependent window events. These are discussed in later chapters.
Newly allocated windows do not have callbacks defined, with the result that no action is taken when an event occurs.To register a callback on a window, a callback must be supplied after window allocation, e.g. to handle window deletion,
window mywin = wgraphic
mywin.delete = {
args w=window
ifyes 'Delete this Window' { wdelete w }
}
When the system invokes a window callback, at least one parameter, the window value, is passed to the procedure. This is always the first parameter. As can be seen from the previous ’delete’ example, this can then be used within the procedure. This also enables more than one window to use the same callback:
window myhelpwin = walpha helplist myhelpwin.delete = mywin.delete
While executing a window callback, the callback is temporarily de-registered to prevent recursion, and later re-registered when an exit is made from the callback. For most window callbacks, the window identifier is the only parameter passed to a window callback, although other information is passed to the buttons, resize and move callbacks.
Window callbacks may be invoked programmatically in one of two ways, either:
mywin.help()
where the system automatically passes the window as the first parameter for you, or
window.help(mywin)
where the window identifier is specifically passed. The automatic invocation of window events usually uses the second method. An important exception to this rule is the window.delete callback. It must not be invoked by one of the above methods. This is discussed in the next section.
In a previous section we discussed window state (normal or iconic). The callbacks window.iconify and window.deiconify get invoked whenever the state changes, e.g. when the operator uses the appropriate window manager function, when the value of window.open changes, or when the wopen / wclose commands are executed.
It is often useful to perform some housekeeping in these callbacks when a window’s state changes, e.g. a flag variable could be set when a window becomes iconized to suppress unnecessary window painting due to the window contents being invisible while in a minimized state.
A window can get deleted by programmatic execution of the wdelete command, by the user selecting a "window close" option from a window manager menu, or (on Microsoft Windows) by clicking the X symbol in the window's top right corner. In all cases, it will be deleted immediately unless a window.delete callback has been registered for the particular window.
If a window.delete callback has been registered, it is called on immediate receipt of the "request to delete". As was seen in the example in the previous section, the deletion can be stopped if necessary. When specifying the window.delete callback be sure to include a wdelete command within the callback. If it is omitted the window will not be deleted, because the wdelete command when used within the callback is a signal to continue the window removal process.
To remove a window programmatically , the only method is via wdelete. You must not use one of the other methods (e.g. mywin.delete or window.delete(mywin)) because this can cause Fire to loop indefinitely in the delete callback.
If you wish to delete a window but by-pass the callback you must nullify the callback before calling wdelete:
mywin.delete = null wdelete mywin
You must not redefine a window callback procedure during its execution. We remind you here that any identifiers pointing to a window being deleted will be nullified, so that you can subsequently safely test for the existence of the window:
window ~mytable.mywin = wgraphic
mywin.delete = {
args w=window
ifyes 'Are you sure' { wdelete w }
if (w) !Window not deleted
}
All windows have the option of a customizable menubar. This is an area with a horizontal row of buttons at the top of the window contents. The menubar is customizable because each button can be given an associated procedure (or callback) to be executed when the button is pressed.
The above window (a Unix example) was allocated by the following command sequence (we shall see the code which defined the menubar buttons later):
# Get a directory listing into a file dir -of=/tmp/listing.dat # Display the listing in an alpha window window mywin = walpha /tmp/listing.dat,-tit='Directory Listing',-mb
Some types of window, e.g. graphic windows, have a menubar present by default. Other window types have the menubar omitted by default. The presence or absence of a menubar must be known at window allocation time. It cannot be added after allocation.
Note: only top-level windows can have menubars, subwindows cannot have them.
To tell Fire that a window, whose default is "no menubar", is to be allocated with a menubar, you must include the -mb switch on the allocation command (as in the above example). To suppress the presence of a menubar, use the -no_mb switch.
Once we have our window, we can define the contents of the menubar. All windows have a maximum of 16 buttons available. Not all buttons have to be defined. A button becomes defined by setting its callback, i.e. by telling Fire what to do when the button is clicked. Only buttons with assigned callbacks are visible.
Each button also has an associated text attribute, known as its label,
which provides the user with a visual description of what happens when it is
pressed. If the label is not supplied, Fire will just display the button number
instead. The buttons are numbered 1 through 16, and are displayed along the
menubar numerically from left to right, and can be referenced in a
via 2 window elements:
window.buttons[n], the button callback procedure, and
window.button_labels[n], the button label, a string value.
Perversely, button 1 is a special button and if registered (i.e. has its callback set), is always shown on the right of the menubar. It is known as the Help button and its callback may be referenced either as window.buttons[1] or window.help. Its label can be referenced as expected by window.button_labels[1], although the default label for button 1 is "Help" and is typically not changed since an application usually uses this button only for supplying the operator with on-line help information. On Microsoft Windows, the Help button is shown to the right of the others, on Unix systems it is shown alongside the right edge of the window. This is window manager convention.
So, armed with this knowledge, we can register buttons for the window shown in our example with the following commands:
# Get a directory listing into a file
dir -of=/tmp/listing.dat
# Display the listing in an alpha window
window mywin = walpha /tmp/listing.dat,-tit='Directory Listing',-mb
# Add buttons to the menubar
mywin.help = {
exec $MYDIR/help
}
mywin.button_labels[2] = 'List'
mywin.buttons[2] = {
exec $MYDIR/list
}
mywin.button_labels[3] = 'Delete'
mywin.buttons[3] = {
exec $MYDIR/delete
}
Here you cannot see what the button callbacks actually do because they just call external macros, which will contain the logic to perform the button functionality. We are only discussing menubars at the moment.
Some buttons are reserved for special use, e.g. the Redraw button in a graphic window. They have predefined labels and are documented in later sections.
Typically, menubar buttons have associated pulldown menus to facilitate multi-option selection. A common configuration is the familiar ’File Edit View’ sequence of buttons seen in many software packages, all of which usually have associated pulldown menus. Pulldown menus can be made to cascade to a bewildering depth if necessary.
To give a simple example of a single pulldown, we can add a pulldown menu to our alpha window example as follows:
mywin.buttons[2] = {
pulldown {
0: 'Destination'
1: 'Printer' { exec $MYDIR/print_list}
2: 'Another Window' {exec $MYDIR/print_win}
3: 'X-Terminal' { exec $MYDIR/print_xterm}
}
}When the List button is pressed, activating the pulldown menu, the window would take the following appearance:
One restriction when using pulldowns in menubars is that the pulldown must be defined within the code of the callback. It cannot be defined in a lower command frame, e.g. in a macro or function called by the callback.
When a button callback is invoked, the window is passed to the callback as parameter 1, like all window procedures, and the button number is passed as a second parameter. This enables the same callback to be used for more than one button.
An example of a button callback which references its button number might be:
mywin.buttons[3] = {
args w=window, button=numeric
exec $MYDIR/do_op(button)
}Menubars are in fact instances of a language identifier known as a menupane. A menupane is a general structure used to permit the creation and access of different types of menu of which a menubar is just one. We shall the others (pulldown and popup) later.
The referencing of the window elements buttons and button_labels are shorthand for reference to structure members of the menupane. A menupane identifier has many elements and when more complicated manipulation of a menubar is required, such manipulation must be done on the menupane identifier.
Some windows permit scrollbars to be present. Scrollbars permit the operator to use the window as a viewport on a larger area of data.
When scrollbars are required, the -sc switch should be added to the allocation command. Some windows, e.g. graphic windows, add scrollbars by default when required, so this switch is redundant in such cases. Other window types need to have scrollbars requested specifically. Use the -no_sc switch if you specifically do not want scrollbars.
You can test whether or not a particular window has scrollbars by examining the element window.scrollbars, but this cannot be changed once the window has been allocated.
Control over a window’s position and size can be exercised on the window allocation command. User-supplied dimensions usually refer to the full window, including window manager frame, but some windows also allow for the definition of canvas dimensions, i.e. the size of their inner contents.
The dimensions of menubars and buttons are computed by Fire. They are computed from font size, widget decoration size etc. and are not directly configurable within the language.
There are two window structure elements which monitor the current dimensions of a window: window.outrect and window.inrect. Both are 4-element numeric arrays and record a window’s position in screen (desktop) coordinates.
window.outrect records the top-left and bottom-right corners of the window’s outer rectangle, i.e. the window manager frame, as an x,y, x,y sequence of values. Remember that y screen coordinates run from top to bottom, unlike most Cartesian coordinate systems, so that (0,0) is the top-left corner of the display.
In similar fashion window.inrect records the corners of the window canvas. The canvas is the display area of the window and is not the full internal contents. It does not include the menubar or scrollbars. On window creation, a window’s size can be set with the -geom switch on the allocation command:
window mywin = wgraphic -geom=<50,50,400,400>
When an application is not particularly bothered about a window’s size, or when the window is of a type where its size is determined solely by its contents, e.g. a panel window, you can specify just its position by the -pos switch:
window mywin = wgraphic -pos=<100,100>
For some window types, the dimensions (width and height) may be specified with the -dim switch:
window mywin = wgraphic -pos=<100,100>,-dim=<350,400>
Unfortunately the specification of window geometry is treated by window managers as a "preferred" size and position. There is no guarantee that a window manager will cooperate with the request, although most do. For example if the requested size is too big to fit on the screen, the window manager may truncate the size so it does fit.
Once a window has been allocated and has appeared on the screen, its position may be changed by the wmove command, or by operator interaction using the move bar in the window manager frame.
Similarly both its position and dimensions may be changed by the wsize command, by using the resize bars on the window manager frame (if present), or by directly changing the values of the window.outrect array.
Whenever the size or position of a window canvas changes, the window’s window.resize and window.move callbacks are invoked, if they had been registered.
This can happen under the following circumstances:
when the user chooses the "resize" option from a window manager menu.,
when the user changes the window size via the window’s resize bars,
when the wmove or wsize command is issued programmatically, or
as a result of changing the elements window.inrect or window.outrect.
Unlike other window callbacks, extra parameters are passed to window.resize and window.move in addition to the window itself. These parameters enable the new geometry to be compared to the old, and appropriate action taken. Note: the callbacks are invoked after the event has happened. There is no way of pre-empting the event and denying it.
The move callback is passed the old position and the new, e.g.
mywin.move = {
args w=window, oldpos=numeric[], newpos=numeric[]
tell <'Old position',oldpos[1],oldpos[2]>
tell <'New position',newpos[1],newpos[2]>
}
The resize callback is passed the old dimensions and the new, e.g.
mywin.resize = {
args w=window, olddims=numeric[], newdims=numeric[]
tell <'Old width,height:',olddims[1],olddims[2]>
tell <'New width,height:',newdims[1],newdims[2]>
}
The resize and /or move callbacks are invoked immediately after the window 's geometry has changed, but before any repainting of the window contents. Unfortunately it is not possible, unlike the delete event, to deny these events. In addition there should be no attempt to resize the window again while within a resize callback. If resizing a window is to be forbidden to the operator, the window should be created "fixed size" using the -fix switch, which then omits the resize bars from the window manager frame surrounding the window.
There are many colors associated with a window, but only three are definable by the language at window allocation time. They are:
The background color of the window canvas, known as the canvas background.
A color used for painting any gui areas of the window contents, e.g. menubar, scrollbars and other widgets. This is known as the frame color.
A color used for painting other aspects of widgets, e.g. text color. This is known as the other color. Good name eh ?
All other colors are defined once the window is up and running. Different window types have various window colorizable elements in addition to the 3 above.
The canvas background color is defined at window allocation time by a -bc switch, and can be referenced thereafter by the element window.background. If omitted at allocation time, a suitable default is chosen, typically white.
The canvas background only has meaning for window types: graphic, alpha and display, e.g.
window mywin = wgraphic -bc=yellow
After allocation, a window’s background can be changed merely by re-assigning the value of window.background.
For alpha windows, this color provides the background color to the text.
For display windows, it provides the background color when displaying transparent images.
The second of our 3 colors (often referred to as the frame color) for the window is used to color any gui areas of the window contents, with the exception of the canvas area. These areas include widgets and controls which the window may contain, and (for Unix systems only) any menu-bar, scrollbars and inner frame surround which the window may have. Note: On Microsoft Windows, these latter components are controlled by the window manager and are not configurable from Fire.
Although this color is referred to as the frame color, do not confuse it with the outer frame which the window manager adds. The color of this outer frame is totally controlled by the window manager and is beyond Fire's sphere of influence.
The frame color is defined at allocation time by the -col switch. As an example, consider a panel window (on MS Windows), created by the wpanel command:
wpanel -col=khaki { button 'I am a Button, Hit Me' }
Therafter it may be referenced by the element window.color, but cannot be changed.
The third color (known as the other color for want of a better name) provides the color of widget text and other miscellaneous aspects of widgets and controls.
It can be set at allocation time by the -ocol switch. To illustrate, we will extend and re-color the last panel window.
wpanel -col=khaki,-ocol=blue { button 'I am a Button, Hit Me' check_button 'A Check Box' }
Therafter it may be referenced by the element window.other_color, but cannot be changed.
For shadowing effects on widgets and controls, Fire derives suitable colors usually mid-hue between the frame and other colors.
On Unix systems, if the frame and/or other colors are omitted at allocation time, defaults are taken from the X Resources file. Definition of these resources is discussed in a later section.
In a similar fashion to colors, the fonts for use in are definable by the language at window allocation time. There are 2 switches for this purposes -font and -mfont.
Each takes a font identifier for its value, e.g.
walpha -font=panel_font wgraphic -mfont=nt_oem
The -font switch provides the font for all gui text within a window, excluding the menubar. The -mfont switch provides the font for text on the menubar. Unfortunately, the menubar font is not configurable on Microsoft Windows, but is controlled by the window manager.
Fire can use 2 types of font: system fonts and graphic fonts.
system fonts are fonts freely available within the Operating System for use within gui components, e.g. buttons, menus etc. On Microsoft Windows, system fonts are TrueType fonts. On Unix, system fonts are X-Windows fonts.
graphic fonts are scalable and rotatable fonts, for use within graphic windows to annotate drawings.
Only system fonts may be used as window fonts.
Let us create a panel window (on Microsoft Windows) similar to one we did earlier, but with a change of font:
# Define a system font (from a TrueType font) font myfont,'Monotype Corsiva 12p w400 c0 italic',-sys # Create a window using this font wpanel -col=khaki,-ocol=blue,-font=myfont { button 'I am a Button, Hit Me' check_button 'A Check Box' }
Panel windows, among others, permit an additional level of font control, enabling you to set the fonts for individual gui components (buttons, list boxes etc.). This will be discussed later.
Consider another example to customize the menubar font (on a Unix system):
# Define a system font (from an X-Windows font) font myfont,'-adobe-courier-bold-o-normal--14-140-75-75-m-90-iso8859-1',-sys # Create a window using this font within the menubar wgraphic -mfont=myfont
You may be wondering how system fonts are chosen. Fire has an in-built function choosefont which lets you select from those provided by the Operating System.
On Unix systems, default fonts are taken from the X Resources file. Definition of these resources is discussed in a later section. On Microsoft Windows, default fonts are chosen by the window manager.
