A C Graphical User Interface [add on to Allegro] by Christer Sandberg
E-mail: rya.christer@gmail.com
The Manual of CGUI 2.0.4
When you want to compile and link your own program that uses CGUI you need
to know the following
-
To satisfy the compiler you need to #include <cgui.h> in the top of
each file that uses a function from the CGUI library.
-
Before calling any CGUI function you must have initialised CGUI once.
-
To satisfy the linker you need to tell the linker that you want to use
the Allegro library and the CGUI library. You also need to tell if you
want to link dynamic or static, and the choice you do need of course the
corresponding libraries to be installed.
How to tell the linker this, may differ depending on which compiler and
development environment you use. You are supposed to be familiar with
the platform you use. Here are mentioned only some possibilities:
- If you use gcc (or djgpp or mingw32) and link on the command line,
link with '-lcgui -lalleg'. It is in this case important that you
specify the libraries in that order. If you instead want to use
the debug version of the libraray, then link with '-lcguid'
instead of '-lcgui'.
- If you use RHIDE, go to the menu Options/Libraries and fill
in 'cgui'. It is important that 'cgui' is before 'alleg'. Don't
forget to check the box to the left of the library. You have to
replace 'cgui' with 'cguid' to include debugging information.
- If you use MSVC version 6.0 the integrated environment and have
a "Win32 Application" project, the setting may possibly be done
the following way. "Project" menu -> "Settings" opens a
dialogue. Select the "Link" tab. Chose "Category" to "General".
Add the text "alleg.lib cgui.lib" at end of "Object/Library
modules" separated with a space.
-
The dialogues in CGUI may want to save and restore som user settings in
the default allegro.cfg file. If that file is not present the dialoues
will work anyway, only that the changes will never be stored. You don't
need to type any initial data into the config file.
There is a minor allegro.cfg in the examples directory of CGUI. You will
find another one in your installation of Allegro. It is supposed to be
located in the directory of your program executable.
-
To make the keyboard work as you are used with (country specific
keyboard), then you need to have the allegro.cfg present, and you need
to type in it the prefered keyboard. See comments in the file.
-
If you need to use some of the dialogs in CGUI you will find that it uses
the english language. Actually there is a possibilty to chose any other
language. This is also done in the allegro.cfg file. Currently there
are only two choices, swedish and english. If you want to translate to
your favourite language, just contact me for instructions about how to do.
-
The default font used int CGUI may not satisfy the requirements of your
language. If so, just make your own font using Allegro, load it using
Allegro, and tell CGUI to use it (see section Fonts).
-
The steps needed to build a simple dialogue is the following:
- Create a dialogue window (by a call to `MkDialogue'). This is still
not visible.
- Put some objects into that window (e.g. `AddButton', `AddEditBox' etc).
- Make it all visible by calling `DisplayWin'.
- Call `ProcessEvents', which will start scanning keyboard and mouse
for events. If you e.g. have a Close button and the user klicks that
button, you funcation (the one passed to `AddButton') will be called
back. Typically it should call `CloseWin' to close the window, and
`StopProcessEvents' to force `ProcessEvents' to stop (and the
execution will continue at the code line after the call to
`ProcessEvents').
Fundamental in CGUI is the event driven approach. This means that your
program doesn't need to check for certain operator actions like mouse
clicks and key presses. Instead you must write functions that will be
called by CGUI when those events occure. Therefore you must inform CGUI
which function to call. You do that by passing a pointer to your
function when creating any object that needs such a callback.
Your callback function may do whatever it likes, e.g. start a new
dialogue (i.e. put another window above the current) or close the
current window or exit (by calling exit) or call `StopProcessEvents', etc.
A few word to those that are not used with function pointers:
Maybe you find the declaration of functions in CGUI a bit messy because
of the callback parameter, but don't worry - when writing your code for
the actual call you will find it quite ok.
The C-code in the callback may look like the code of any of the functions
you have written before, there are no special requirements except that
the declaration (the function head) must match that of the function
pointer - so there will be a void* pointer involved in most cases.
Example:
...
my_type *my_data;
...
AddButton(DOWNLEFT, "OK", my_okfun, my_data);
...
void my_okfun(void *data)
{
my_type *my_data = data;
/* Do whatever you need */
}
The declaration of the function passed to AddButton must be like above
(i.e. taking a single parameter of type void*). To use the data you need
to copy the pointer to one of a type that is not void* like above. That
type must of course be the one of the last parameter passed to AddButton.
When passing your function pointer and data pointer lika this, e.g.
AddButton(DOWNLEFT, "Label", fptr, dataptr);
You should think like this:
When the button is pressed by the user, the call fptr(dataptr);
will be done, and you must write the code of fptr to match that.
Lots of important functions in CGUI needs function pointer and void*
pointers, and they should all be handled similarly.
There are also several examples in the directory "cgui/examples" which
can be useful to look at.
int InitCgui(int w, int h, int color_depth);
This function initializes CGUI. This includes setting a graphic mode
as specified by the parameters. CGUI will also take over the keyboard
and mouse, and this is done by the initialization function. A desktop
will be created automatically.
There are some alternative initialization functions: InitCguiLoadMode,
InitCguiFullscreenMode, InitCguiWindowedMode and InitCguiKeepCurrent
that differs only in how the graphics is initialized. Se the sections
for these if you want to know details.
Parameters:
- w,h: The size of the desktop. In case of full screen mode this is also
the screen resolution, else the (inner) size of the window.
- color_depth: The colour depth to be used, expressed in bits, see
Allegro's `set_color_depth' for info about color dephts. 8 bits color
depth implies palette mode. If you don't know about palettes you should
avoid choosing 8 bit mode. If you do know about it please help yourself
in sorting out how to use it. CGUI does not support it in any way - it
will use makecol() to find the color indecies that best fits the color
specified in the config file. The standard palette on a PC will most
likely not be suitable for the default one.
Simple initialisation: just call the initialization function at
program start (i.e. without initializing any part of Allegro, CGUI will
do that for you).
Whenever CGUI fails to set a graphics mode (this applies also to the
alternative initialization functions) it will do the following:
The first attempt is to try another colour depth. If the requested colour
depth was
- 8 no more try
- 15 it will try 16
- 16 it will try 15
- 24 it will try in order 32, 16, 15
- 32 it will try in order 24, 16, 15
If the above fails, it will try with a lower pixel resolution and the
same sequence as above including the requested colour depth. This will be
repeared until an accepted screen mode was found or there are only modes
using 8 bits colour depth left (in which case it will try all resolutions
from 640x480 and less in 8 bpp, and if still no one is accepted it will
terminate the program by a call to exit).
You can do subsequent calls to `InitCgui' to change the the screen
mode (resolution and/or colour depth). Some CGUI-objects needs to be
notified about the change, so to handle a screen mode change properly
you should use this method instead of setting it directly with Allegro's
set_gfx_mode() (if you still prefere the latter way you should call
InitCgui afterwards).
Returns always non-0 (does never fail).
See also:
CguiUseUTF8,
InitCguiLoadMode,
InitCguiFullscreenMode,
InitCguiWindowedMode,
InitCguiKeepCurrent,
DeInitCgui.
Will look for a full screen mode setting in the current config file.
[cgui:screen-res]
Width = 1024
Height = 768
Colour_depth = 15
The above numbers are a examples, you can preset these values to whateever
you like. If you make CGUI's screen mode selector available for the user
of your program that dialogue will uppdate the values.
If no settings were found, then 1024x768x32 will be used.
See also:
InitCgui,
DeInitCgui.
Will try to pick the current screen mode from the system and then
use these when trying to set a full screen mode.
See also:
InitCgui,
DeInitCgui.
Will try to keep the current screen mode of a windowed environment and
try to set the CGUI screen to windowed mode, with the same colour depth,
and a window size equal to the next smaller possible resolution.
See also:
InitCgui,
DeInitCgui.
Will no set the grapics mode at all. This requires the graphic to be
initialized before calling InitCguiKeepCurrent (i.e. call set_gfx_mode
first).
In paletted mode CGUI will make no changes to the palette.
See also:
InitCgui,
DeInitCgui.
Closes all windows, removes the event queue and frees all data
allocated by CGUI.
DeInitCgui will be automatically called at exit, so normally you don't
need to call it yourself.
NOTE! It is important that you call DeInitCgui NOT from within any
callback from CGUI, i.e. the call must be after the event processing
has terminated (immediately after the call to ProcessEvents()).
If graphics were initialized before the first call to InitCgui() then the
screen content will be restored to what is was by that time, but the
screen mode will not.
See also:
InitCgui.
By default CGUI assume strings to be in 8 bit ascii. To change this and
force handling UTF-8 encoding of unicode, you can call this function.
You should call it before calling CguiInit().
int cgui_ver, cgui_rev, cgui_minor_rev, cgui_release_date;
int HookExit(int id, void (*ExitFun)(void *data), void *data);
This function installs the callback function `ExitFun'. This is a pointer
to a function written by you. It will be called by CGUI when the object
`id' is destroyed, and it will be passed the pointer `data'.
If `id' refers to an object that has an "action-callback", like e.g.
a button that has a call-back that will be called when the button is
clicked, and such a function destroys the object `id' then `ExitFun'
will be called when the "action-callback" is finished. To be more precise,
`ExitFun' will be pushed on to the event queue.
Installing an `ExitFun' may be useful if you want to free some memory
allocated for e.g. a dialog, and wants a somple way to catch all
possibilities of its closing.
Returns 1 if id referes to an existing object, otherwise 0.
See also:
InitCgui,
DeInitCgui,
CloseWin,
Remove,
Destroy.
Windows are areas that are visible on the screen and they serve as
containers for objects.
Windows will be placed at a position decided by the windowing system
itself - it will try to centre them around the current cursor position.
Windows can by default be moved with the mouse (by gripping the window
header).
There is always one window that is "in focus" i.e. that receives mouse
commands and keyboard commands. If the same hot key is defined in several
windows, the event of pressing that key will go to the focused window.
So hot keys defined only in windows that are not in focus will be ignored.
Hot keys may however be defined globally, and these will be handled even
no matter which window is in focus. By default windows works like a
stack: opening a new window makes that one be the active one displayed
on top of the others. Closing a window lets the previous one be the
active (top) window. There are several ways to override this, see
MkDialogue for details.
About requesters: This is a special type of windows, that wait until the
user answers, i.e. you can use it without the "event driven" style
of the code, but rather like the classical linear programming like
when using scanf, getchar etc.
You should however know that the event processing is still running while
your function is waiting for the requester to return. So if other events
like serial port, time-events etc. occur, these will be put into the
event queue and will be processed in proper order while the requester
is up. Processing these events can, if needed, open new windows and
requesters without any problem.
See also:
Objects,
Containers,
Menus,
Listboxes,
Tabwindows.
int MkDialogue(int width, int height, const char *title, int options);
Creates a new window. The window is however not completed (and not
visible) until you call `DisplayWin'. In between you should add some
objects to make it meaningful.
Windows can be closed by `CloseWin'.
The created window will be the child of the window that is in focus when
calling `MkDialogue'. The new window will automatically be set in focus
when it is created. It will also be set to be the "operating window"
(i.e. the one into which objects will be put when created).
In case you need to create multiple windows there are some window
behaviour that needs to be discussed:
- How a window is displayed relative to other windows (which
properties and states forces a window to be displayed on top of
other).
- Window "focus". Which properties and states makes it possible for
the user to alter the window beeing in focus. (Focus means that the
window receives keyboard and mouse events. The focus is normally
indicated to the user with some kind of highlighting).
- The life of a window. Since the meaning of one window may depend on
another window's existance, there may also be need for
"navel-strings" between windows (child - parent relation).
In CGUI windows are arranged in a tree relation, where there is a virtual
root and the the desktop (created by `InitCgui') is tha child of that.
So if the first window you create has default settings it will be the
child of the desktop.
- The existense of at least one modal (non-floating) child, implies
that a window can not get the focus.
- A child is unconditionally displayed on top of its parent. This
means that even if the parent is in focus, the child will be on top.
- A floating window being in focus will be displayed on top of all
its floating sisters (and all siblings of these).
- A non-floating window beeing in focus will be displayed on top of
all its non-floating sisters (and all siblings of these).
- A floating window will at any time be displayed on top of all
its non-floating sisters (and all siblings of these).
- A child will always die when its parent dies.
The properties that acomplishes the above behavior in CGUI are controlled
by some optional flags listed below.
When using which?
- The simple (and probably most common) usage is the
deafault (i.e. a modal child), requireing that the user closes the
latest created window and thereafter finds the focus being on the
parent.
- The "floating" property of a child may be useful e.g. if you want to
create tool-palette window(s). The main window will be accessed at
any time (i.e. the user can make it in focus by a mouse click),
giving the ability to alter between picking tools from the
tool-palette and work with stuff in the main window (including
creating other palettes).
- The "sister" property may be useful e.g. to
- create a "globally floating" window to display the progress
or state of some work in the background. It may also be useful
for some kind of tool-palettes that one want to be available in
all windows. This can be achieved by making it a sister to the
desktop (floating or non-floating) or as the sister to the
first "main" window (floating).
- create a group of non-floating windows, the focus possible to
alter between them but can not move to the parent.
By default the window will be a child and a child is by default "modal",
(non-floating).
Parameters:
- width, height: specifies the dimensions of the window. These
values may be replaced by the ADAPTIVE command which will
make the window adapt its size to be large enough to show all its
objects. It may also be replaced by the FILLSCREEN command which
simply sets the size to the current desktop size. If the desktop size
is later on changed because the screen mode is changed by ScrMode,
then all windows will automatically be redrawn, and a FILLSCREEN
window will again take its size from the desktop dimensions.
- title: this is any text that will be displayed in the top bar of
the window, e.g. to explain the purpose of the window to the user.
- options: if you don't need any of the options listed below, then
just pass 0. Currently available options are listed below and can
be combined with logical or.
- W_FLOATING: The opened window will be a floating window. This means
that it will
- W_SIBLING: The opened window will be the sister of the currently
focused one. W_FLOATING and W_SIBLING can be combined. To mix
non-floating and floating sisters is allowed but not always
meaningful. The behaviour will be as stated above.
- W_NOMOVE: By default, windows allows the user to drag and drop
them on the screen. This behaviour will be disabled by the
flag W_NOMOVE.
- W_TOP: The vertical position will be at the top of the screen.
- W_BOTTOM: The vertical position will be at the bottom of the screen.
- W_LEFT: The horizontal position will be at the left side of the
screen.
- W_RIGHT: The horizontal position will be at the right side of the
screen.
- W_CENTRE_H: The horizontal position will be in the centre of the
screen.
- W_CENTRE_V: The vertical position will be in the centre of the
screen.
- W_CENTRE: The horizontal and vertical position will be in the centre
of the screen.
If no position option is specified the window will be positioned
centered around the current mouse position.
If only one of the vertical and horizontal positions is specified by
the above option flags then the other will be set to 0.
In addition to the above special position options, a window can be
placed at an arbitrary position, see `SetWindowPosition'.
Return value: an id (in the same domain as objects).
See also:
DisplayWin,
CloseWin,
ScrMode,
SetFocusOn,
Req,
SetWindowPosition.
`DisplayWin' must be called to complete a window and to make it visible.
When adding various object into an opened window, these objects can not
be completed immediately (e.g. their sizes and positions can in general
not be computed until all of them are there).
`DisplayWin' will do this completion, and also draw the objects onto the
screen.
`DisplayWin' may also be called later on to make all its object
refreshed. Such a repeated call will also re-build the window, which
is necessary if you remove or add objects to the window after the first
call to `DisplayWin'.
The window that will be affected is the one in focus.
See also:
MkDialogue,
Refresh,
SetFocusOn.
Closes an open window. The parameter will not be used, it's there just
to conform to the standard event-handler form - just pass a
NULL-pointer.
The window that will be affected is the one in focus.
See also:
MkDialogue,
DisplayWin,
SetFocusOn.
By default a window will be opened at a position that is assumed to be
convenient for the user (se `MkDialogue' for details). This automatic
behaviour can be overridden by calling `SetWindowPosition' with the
desired position (upper x,y is the upper left corner of the window) after
`MkDialogue' but before `DisplayWin'.
See also:
GetWinInfo,
MkDialogue,
DisplayWin.
Sets the desktop image (the screen background).
If bmp refers to the screen, then a copy of it will created. (This
memory will be properly released when CGUI terminates.) If bmp is a
memory bitmap, this function will just take a copy of the pointer, so it
is your responsibility to keep it as long as CGUI is alive, and then do
destroy_bitmap(bmp).
If the size of the bitmap doesn't fit to the current size of the screen,
then the following will be done:
- If bitmap is larger: it will be scaled to the size of screen.
- If bitmap is smaller: it will be repeatedly blitted to fill screen
allowing you to draw patterns.
The desktop is not updated until `Refresh' is called. Use ID_DESKTOP
for `id' when calling `Refresh'.
int Request(const char *title, int options, int width, const char *format, ...)
Opens a requester window of the same type as 'Req', but here you can specify
the width of the text and also pass a format string of 'printf' type together
with the necessary variable arguments.
Parameters:
- title: as for `Req'.
- options: the position codes as described under MkDialogue
- width: The width of the requester. A value of 0 will give the default
size (the same as for `Req')
- format: as for `Req' but in addition it can contain format info like
in the format string to the `*printf' functions.
- ...: Additional parameters corresponding to the format specifiaction
(i.e. like the `*printf' functions).
Return value: as for `Req'.
See also:
Req,
MkDialogue.
int Req(const char *title, const char *format);
A window for prompting the user for a simple question or givin some brief
information in a simple way.
Parameters:
- title: The text that will be displayed in the title bar of the requester
window. If you don't need a title, then pass the empty string ("").
- format: This is a string containing some special info to create the
buttons and their layout.
- Any info-text you want to be displayed, followed by:
- At least one push-button label. Each label must be separated from
the previous one (or the info-text) with the '|'-character. Each
button label may optionally contain any optional characters that a
labels in general can contain.
In opposit to other windows functions, this one will wait until the user
has clicked one of the buttons. Before it returns it will close itself,
so don't do that.
Example of simple usage:
switch (Req("Operation request",
"Do you really want to do this?|~Yes|~No|Confirm_each ste~p")){
case 0:
do_it();
break;
case 1:
return;
case 2:
confirm();
}
Return value: The push-button number that the user selected. 0 is the
first button in format string, 1 is the next etc.
See also:
Request,
Labels.
Redraws the entire screen. All windows that are at least partly visible
on the screen will be redrawn.
void GetWinInfo(int id, int *x, int *y, int *width, int *height);
Returns the coordinates and size of the specified window. The results
will be given in screen coordiantes (with (0, 0) in upper left corner).
See also:
SetWindowPosition.
Returns the id number for the current operating window.
See also:
SetOperatingWindow,
SelectContainer.
Sets a new window to be the the "operating window". Most functions
that operates on objects require an id-key for reference. For your
conveniance that is not necessary when creating new objects, they will
be put into the most recently created container in the most recently
created window. That is the "operating window".
Normally the operating window is the same as the one in focus.
Occasionally you may later on want to add some objects to a window that
is not in focus. Then you must use `SetOperatingWindow' (and maybe also
SelectContainer) before adding the objects. Just use the id-key returned
when the window was created, and pass it to SetOperatingWindow.
See also:
CurrentWindow,
SelectContainer.
A simple progress-bar window containing a progress bar and a status
field.
Parameters:
- wlabel - A pointer to a string which will be used as informational
text in the window header. Pass an empty string if not needed.
- blabel - A pointer to a string which will be used as the label
on a button that gives the user the opportunity to close the window.
Pass an empty string if you don't want the button to be there.
- w - The width of the progress-bar.
Return value is the id of the window. This can be used to update
the current value by calling UpdateProgressValue'.
See also:
UpdateProgressValue,
AddProgressBar.
Window objects may be of different types. Below is a list of the "simple"
types. You can find contaners and menus in other sections.
A window object is an object that is in a window. It is assigned a
rectangular area within this window, and it has the full responsibility
for that area. This responsibility includes:
- Drawing on it - if it does not draw anything, the content of that
area is undefined.
- Receiving messages from the mouse.
- Receiving messages from the keyboard.
These tasks are performed automatically - you don't need to bother about
_how_ to do it, but maybe you need to know that it works in this
way (in fact an object also has some more tasks that we don't talk about
for the moment).
As a consequence of the above, there will be problems if simple objects
like push buttons etc., overlap each other (which of them should draw and
which of them should receive mouse messages?). To make it easy for you
to avoid overlapping, you can use direction commands rather than
specify the coordinates of the object; see the
"Direction commands for object positioning" section.
How do you know the width and height of an object? In fact you normally
don't need to bother about this in CGUI - the objects will adapt their
size to be large enough. For example:
- A text labelled check box will be as wide as is needed to show its
label and check mark. The height will be the height necessary for the
text.
- A push-button with an image and a text label will be large enough to
show both the label and image.
Some types of objects need explicit coordinates (e.g. the width field
of edit boxes), see the specific object type for more information.
Also note that to create a nice interface you may use the container
facility to create subgroups of objects. Containers are discribed in
another section.
See also:
Containers,
Windows,
Menus,
Listboxes,
Tabwindows.
int AddButton(int x, int y, const char *label,
void (*CallBack) (void *data),
void *data);
This function creates the standard type of push button.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- label: the label text that will be displayed on top of the button,
see general text label info for details. The text labels for buttons
may contain one additional command, with the syntax "#name;" where
`name' is the name of a registered image (see `CguiLoadImage' for
details). The meaning of this is that the
image `name' will be drawn on top of the button instead of a text.
If there is both a text label and an image specified, then the label
will be drawn below the image.
The label text may also contain an underscore. This will be
recognised as as a "newline" command and the label will be drawn
in two partitions. The '_' will not be drawn.
The text will be centred.
- CallBack: A pointer to a function written by you, which will be
called when the user clicks the button.
- data: A pointer to any data you want, which will be passed along
to `CallBack' (You should of course not use local variables for
this, since they will not exist when you exit the calling function).
The default behaviour is to ignore right mouse button clicks.
Return value: an identification key to the object.
See also:
CguiLoadImage,
AddIcon,
Direction commands for object positioning,
Labels.
int AddCheck(int x, int y, const char *label, int *sel);
This is a check box which toggles between being on and being off when the
user clicks it. `sel' points to an integer, which is 1 for on and 0 for
off.
Return value: an identification key to the object.
See also:
AddRadioButton,
AddDropDown,
AddCheck,
Direction commands for object positioning,
Labels.
int AddFlip(int x, int y, const char *label,
const char *const*strs, int *sel);
This is like a check box, but displayed differently: `strs' is an array
of two strings, the first of which will be displayed when `sel=0' and the
second when `sel=1'.
Return value: an identification key to the object.
See also:
AddRadioButton,
AddDropDown,
AddCheck,
Direction commands for object positioning,
Labels.
To create a group of radio buttons, call first this function, then add
the radio buttons using `AddRadioButton', and finally call
`EndRadioContainer' to finish.
Return value: an identification key to the container.
Prameters:
- x,y: The position of the object (or you can use "direction commands").
- var: Points to an integer describing which radio button is selected.
The first button that you add is number 0, the second is 1, etc.
- direction: Specifies whether the sequence of buttons shall be placed
vertically or horizontally. Use macros R_HORIZONTAL and R_VERTICAL.
In case of R_HORIZONTAL it also recognises the optionally EQUALWIDTH.
Return value: an identification key to the container.
See also:
EndRadioContainer,
AddRadioButton,
AddFlip,
AddCheck,
AddDropDown,
Direction commands for object positioning.
Adds a radio button to a radio button sequence. The first button added
will get number 0, next 1 and so on. To start a radio button sequence,
call `MkRadioContainer'.
Return value: The id number of the button.
Parameter:
- label: The label to be displayed on the button, following the
same specification as for buttons.
Return value: an identification key to the object.
See also:
MkRadioContainer,
EndRadioContainer,
AddButton,
AddHandler,
MkMenuRadio,
Labels.
Terminates a sequence of radio buttons. If you don't terminate it,
subsequent objects will go into the same container and your window will
not look very nice.
See also:
AddRadioButton,
MkRadioContainer.
int AddIcon(int id, int x, int y, const char *iconname,
void (CallBack)(void*), void *data);
This function adds an icon object to the specified node. An icon object
is a movable bitmap (i.e. the user can "drag and drop" it with right
mouse button). The image is specified in the label text, just like with
buttons.
Currently you can only place icons on the desktop, so pass ID_DESKTOP
for id.
You can obtain the current position of the icon by calling
`GetObjectPosition' (this can be useful e.g. if you want the program to
arrange the icons in the same way next time you start it).
Return value: The id number of the icon.
Parmeters:
- id: The node to put the icon into - in current version of CGUI
this should always be ID_DESKTOP (the desktop).
- x,y: The position of the icon.
- label: The syntax and meaning of the string is the same as for
`AddButton'.
- CallBack: A pointer to your function. It will be called when the
user made a successful click on the icon.
- data: A pointer to any data. It will be passed to your function when
called.
Return value: an identification key to the object.
See also:
AddButton,
GetObjectPosition,
Labels,
CguiLoadImage.
Gives the current position (top left corner) of an object.
Parameters:
- id: The object asked for
- x, y: The coordinates (relative to the container it exists in).
- wx, wy: The coordinates related to window it exists in.
Return value: 1 if ok 0 if error (i.e. invalid id).
See also:
AddIcon,
GetWinInfo.
int AddDropDown(int x, int y, int width, const char *label, int *sel,
const void *data, int n,
void (*CallBack) (const void *data, int i, char *s));
Drop down boxes can be used for the same purpose as radio buttons, i.e.
let the user make a selection from several alternatives. The selection
will be reflected in the program as one of the values in the range
[0..n-1] The DropDownBox uses another way for presentation of the
alternatives. The DropDownBox requires less space in the dialogue window
than the radio-buttons. On the ohter hand it is required one extra
command to make the different alternatives visible (dropped down).
If there are lots of alternatives or if there are lots of controls in the
dialogue window, the DropDownBox is to prefer.
To achieve the result of a selection - just examine your value pointed to
by sel. This can typically be done when the dialogue window is closed.
Optionally this may be done by an additional call-back function, which
will be called after each selection made by the user. See AddHandler
If the DropDownBox shall be used just to display a certain state or
setting, rather than to provide a control to the user: use `DeActivate'
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- width: the width in pixels of the display field (the width of the
label is not included). If width is set to 0, a width enough to
display any of the alternatives without clipping, will be
calculated.
- label: an optional text-label for the box
- sel: a pointer to the variable that controls the selection (and that
will be updated when a new selection is made by user).
- data: pointer to any of your data to create the list of text
alternatives from
- n: the number of alternatives
- CallBack: a pointer to a function that you must write. This function
will always be passed "data" as its first parameter when called. The
second parameter will be a number in [0..n-1]. The function shall
use the two first parameters to create a string "s", which after
return will be the text associated with number i.
Return value: an identification key to the object.
See also:
AddDropDownS,
Activate,
DeActivate,
AddHandler,
Direction commands for object positioning,
Labels.
int AddSlider(int x, int y, int length, int *ctrl, int start, int end,
int option, int id);
int AddSliderFloat(int x, int y, int length, float *ctrl, float start,
float end, int ndecimals, int option, int id);
The default direction of a slider is horizontal.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- length: the length of the slider (this is the actual sliding length,
the size of the entire object may be larger than this).
- ctrl: a pointer to some variable of your program which value
controls the position of the slider handle, and that is affected by
the user actions.
- start: the min-value of `ctrl'
- end: the max-value of `ctrl'
- ndecimals (for the flot version of the function): the number of
decimals to be printed in the labels of the slider in case the
option SL_LABEL is passed.
- option: either of:
SL_SCALE - A scale will be drawn. The slider will use `length' and
(end - start) to decide how to draw the scale.
SL_LABEL - Numbers (start and end points) will label the scale of
the slider, valid only if SL_SCALE is set.
SL_STYLE1 - The slider will be drawn in an alternative style (diamond)
SL_STYLE2 - The slider will be drawn in an alternative style (slide-rule)
SL_STYLE3 - The slider direction will be vertical (the specified
`length' will be the height rather than the width of the sliding).
- id: an optional reference to some other object, that will be
updated during sliding. This can be used to display the exact value
in e.g. an editbox.
Return value: an identification key to the object.
int AddDropDownS(int x, int y, int width, const char *label,
int *sel, const char * const *strs, int n);
This is a simplified version of AddDropDown. I can be used only if your
text-alternatives happens to be an array of pointers to strings.
In other respects it is equivalent to AddDropDown.
Return value: an identification key to the object.
See also:
AddDropDown,
Direction commands for object positioning.
int MkCanvas(int x, int y, int width, int height,
void (*CallBack)(BITMAP *bmp, int x, int y, void *data),
void *data);
This function will create a canvas on which your function `CallBack' may
draw whatever it want. It will be called each time the mouse generates an
event, i.e. when the position or button state has changed. The current
co-ordinates will be passed to the call-back together with
the private data. If you will also examine all key-presses, you can
install a new KeyBoard handler.
Parmeters:
- x,y: The position of the object (or you can use "direction commands").
- width, height: the size of the canvas
- CallBack: A pointer to your function. It will be called each time
there is some change in the mouse state or position. It will also be
called when a refresh is requested (initially by DisplayWin and any
call to Refresh with id or with the id of any predecessors of `id').
`CallBack' can get the mouse-button state from the Allegro variable
mouse_b.
If `CallBack' make som drawing on bmp, these will not be visible on
the screen until Refresh has been called.
Parameters to `CallBack':
- x,y: the current position of the mouse in local co-ordinates of
the bitmap `bmp'. When called because of initialisation the
function will be passed -1 as value for `y'. The first call is
guaranteed to come before any mouse event. Your function must be
prepared to receive an initialisation call also later (CGUI may
need to do this whenever the window or any container containing
the canvas are re-built).
Subsequent calls because of a `Refresh'-call will pass -1 as
`x'-value.
- data: the pointer data is passed
- data: A pointer to any data. It will be passed to your acll-backi
function when called.
Return value: an identification key to the object.
See also:
InstallKBHandler,
Direction commands for object positioning,
SetBlitLimit,
cgui_use_vsync.
This function may be used to reduce the area of an object that CGUI blits
to screen. It must be called prior to the call to Refresh, and has effect
only during that call (you must call it each time). The coordinates shall
be related to the object and are inclusive. The function is only
meaningful to call for canvas object blitting.
The call to SetBlitLimit is not identical to a call to set_clip.
A global variable that may be used to switch off vsync in CGUI (it is
set to 1 by default). CGUI uses vsync when Refresh or DisplayWin is
called directly or when these functions are indirectly called.
int AddTag(int x, int y, const char *tag);
Tag is simple text object with the default grey background and it
doesn't handle any events, and it is not outlined in any way.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- tag: the text to display
Return value: an identification key to the object.
See also:
AddStatusField,
AddTextBox,
Direction commands for object positioning.
int AddEditBox(int x, int y, int width, const char *label, int conversion_code,
int string_buffer_size, void *data);
This function creates an edit box, which lets the user edit the text
"data", and is formatted according to "format".
Return value: id number of the edit box.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- width: The width of the edit field of the edit box (not counting
the label)
- label: A text label placed to the left of the edit-field
- conversion_code: A code specifying how the edit box shall convert data
to text and the reverse. This can be either of:
- FBYTE - An unsigned integer number. Size of *data is sizeof(char).
- FSHORT - A signed integer number. Size of *data is sizeof(short).
- FINT - A signed integer number. Size of *data is sizeof(int).
- FLONG - A signed integer number. Size of *data is sizeof(long).
- FSTRING - A string. Size of the buffer pointed to by `data' is
given by `string_buffer_size'.
- FPTRSTR - A string. `data' points to a pointer pointing to
dynamically allocated memory, or `data' points to a pointer
that is NULL. Size of data is unlimited. The pointer pointed
to by `data' will be update due to reallocation of the string
memory if needed.
- FPOINTS - A signed integer number eventually followed by a
half-character. Size of *data is sizeof(int). The value pointed
to is interpreted as its integer value divided by 2.
- FBPOINTS - A signed integer number eventually followed by a
half-character. Size of *data is sizeof(char). The value pointed
to is interpreted as its integer value divided by 2.
- FFLOAT - A floating point number. Size of *data is sizeof(float).
- FHEX1 - A hexadecimal number. Size of data is sizeof(char).
- FHEX2 - A hexadecimal number. Size of data is sizeof(short).
- FHEX4 - A hexadecimal number. Size of data is sizeof(long).
- FOCT1 - A, octal number. Size of data is sizeof(int).
- FOCT2 - A, octal number. Size of data is sizeof(int).
- FOCT3 - A, octal number. Size of data is sizeof(int).
- FOCT4 - A, octal number. Size of data is sizeof(int).
In addition to these codes the following can be used combined with
these (ored together), to specify optional formatting.
-
- FNAME - Is only valid when combined with FSTRING or FPTRSTR. The
leading letter of each word will be converted to upper case if
is not already, and the rest of the words will be converted to
lower case, like names use to be written. The formatting is made
instantly when the user is typing.
- FBLANK0 - Shows a blank edit box if the value i 0. Only valid when
combined with FBYTE, FSHORT, FINT, FLONG, FPOINTS or FBPOINTS.
- FUNDEF - Shows a question mark if the value pointed to by `data'
is undefined. Only valid when combined with FBYTE, FSHORT, FINT,
FLONG, FPOINTS or FBPOINTS. The representation of an undefined
value depends on which of the conversion codes that is used.
- B_UNDEF_VAL - for FBYTE
- S_UNDEF_VAL - for FSHORT
- I_UNDEF_VAL - for FINT
- L_UNDEF_VAL - for FLONG
- P_UNDEF_VAL - for FPOINTS
- BP_UNDEF_VAL - for FBPOINTS
The values of these macros can be found in cgui.h. Note that
if the "undefined value" may occur as a value of your variable
it may confuse the user if you use FUNDEF.
- string_buffer_size: This is only valid if `format' is FSTRING, and
in that case it is the size of the string buffer pointed to by `data'.
- data: The data to be edited, e.g. a char* in case of FSTRING format,
int* in case of FINT format etc.
Return value: an identification code to the object.
See also:
AddHandler,
GetEditData,
SetEditData,
TabOnCR,
SetFocusOn,
AddStatusField,
AddTextBox,
Direction commands for object positioning,
Labels.
Makes the carriage returns work like tabs in an edit-box, i.e. focus
moves to next object in the tab-chain. Useful if you have a number of
edit-boxes in a dialogue window, and the user are supposed to enter a
large amout of data.
Returns 0 if it fails (i.e. id is invalid) else non-0.
See also:
AddEditBox.
If you adds an optional callback to an edit-box (with a call to
AddHandler) you may be interested in the current keypress, or maybe of
the current position in the string. Maybe you are also interested in
changing these values. Use GetEditData and SetEditData functions for
this.
Parameters:
- scan,ascii: the memory location pointed to by scan/ascii will be
updated with the current key-press. NOTE! if editing is in progress
and the user terminates the editing by some action that forces the
editing to be terminated, the ascii value will be as for "enter",
i.e. '\r' but the scan value will be set to TERMINATE_EDIT
- offset: a pointer to the position within the string.
See also:
AddEditBox,
SetEditData,
AddHandler.
If you adds an optional callback to an edit-box (with a call to
AddHandler) you may be interested in the current keypress, or maybe of
the current position in the string. Maybe you are also interested in
changing these values. Use GetEditData and SetEditData functions for
this. Note! You are only allowed to call these function from within the
callback function. If not, the calls will be ignored.
Parameters:
- scan,ascii: the previously pressed keys will be replaced with the
passed values, and the current position will be updated to curpos
(before processing the keys)
- offset: a new print position within the string.
See also:
AddEditBox,
GetEditData,
AddHandler.
If `mode' is 1 then the current selection in edit boxes will be replaced with
the letter corresponding to the pressed key or with the clipboard text in
an paste operation. If `mode' is 0 the current selection will remain
unchanged. The default is 0. The setting is global.
See also:
AddEditBox.
int AddStatusField(int x, int y, int width,
void (*FormatFunc)(void *data, char *string),
void *data);
This function creates an object in which a single row-text may be
displayed. The field reserved for text is of fixed width and height (the
height is enough to display one row of text) and is outlined by a frame.
The text will be right aligned and clipped if necessary.
The text will be produced by the function `FormatFunc', which is a
function that you must write. `data' is a pointer to any of your data,
and it will be passed to `FormatFunc' whenever called.
The difference to `AddTag' is that the status-field may change the text
from time to time. A typical use is to display some value or text that
will change from time to time.
Save the id-number and when, for some reason data changes, just call
Refresh(id);
The status field will be put into the current node. It may be a good idea
to create a specific container using `StartContainer' e.g. at the bottom
of a window, for this purpose.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- width: the width of the text-field
- FormatFunc: a call-back function called when text is to be drawn
- data: a pointer to some data
Return value: an identification key to the object.
See also:
AddTextBox,
AddEditBox,
AddTag,
Refresh,
StartContainer,
Direction commands for object positioning.
Adds a progress bar. The current value can be updated by a call to
`UpdateProgressValue'.
Return value: an identification key to the object.
See also:
UpdateProgressValue,
MkProgressWindow.
Updates the value of the progress bar `id'. The bar will updated on the
screen
Returns 1 on sucess, 0 if `id' does not exist or does not refer
to a progress object.
See also:
AddProgressBar,
MkProgressWindow.
int AddTextBox(int x, int y, const char *string, int width, int nrows,
int options);
Creates a simple multi-row text-box. This can be used for various
purposes, typically:
- To display a brief info-text in a dialogue, where you always want
the entire text to be shown and don't want to fiddle with the
height needed.
- To display a not too long info-text (or a text which exact length is
not known at compile time, but known to be not to long) in a
dialogue, where you always want the entire text to be shown and
don't want to fiddle with the height needed. The box is able to
adapt its size to the contained text.
- To display a text which length you know nothing about. You can then
put a limit on the hight of the box (e.g. so that it doesn't get
a size much larger then the screen), in which case it automatically
gets a browsing object.
The default behaviour (if `nrows' and `options' are set to 0) is to
automatically control the line-feeds. The text will be broken into rows
to fit the specified width. Sequences of more than one whitespace will be
displayed as one single space. The line-feeds will be inserted at
whitespace positions (if possible). The height of the box will be the
height that is required to display the text. This behaviour can be
overridden, see details below
A copy of the text pointed to by `string' is used.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- string: the text to display
- width: the text width in pixels (the frame will occupy some more
pixels).
- nrows: If non-zero forces a browsing object to be attached to the
text-box, and the box will be of the fixed height that is required
to contain `nrows' number of rows using the current font. If the
text is longer than `nrows' the browsing object will
be active. A combination with the `TB_PREFORMAT' option usually
makes it more useful.
- options: Just pass 0 if you need none of them, or:
- TB_FRAMERAISE will outline the text with a raised frame.
- TB_FRAMESINK will outline the text with a sunked frame.
- TB_PREFORMAT will handle each whitespace character
individually. Line-feed characters will force newlines
whenever they occure. Multiple spaces in sequence will be
drawn as they are defined in the font in use. The default tab
width is 8. If you want some other setting, just att that number
to the option flags. Lines that are too long to fit into the
current width of the text-box, will be truncated.
- TB_LINEFEED_ If you don't use the option `TB_PREFORMAT', i.e.
let the box do automatic line feeds to fit the text into the
specified width, you may still want to force new lines. You can
do that useing this option. Use the character '_' (underscore)
to indicate where to force line fieeds. (The '_' conforms to the
`mktext' utility, see the tools directory of CGUI). If you need
to draw an '_' just use two in sequence so to insert multiple
linefeeds in sequence, you have to put a space between
the underscores, like "_ _". This option can not be combined
with `TB_PREFORMAT'.
- TB_FIXFONT will use CGUI's built-in fix-font.
- TB_WHITE will set the text background to white instead of the
default grey.
- TB_TEXTFILE The `string' parameter will be used as the name
of a file. That file will be loaded and the contents of it will
be displayed.
- TB_FOCUS_END This has only meaning if the textbox has fixed
height (i.e. nerows is non-zero), and the effect will be that the
last line of text to disply will be shown (if more than one
page to view than the top part will be scrolled out). If you
change the content of the box it will be browsed to the end again.
Use `UpdateTextBoxText' if you need to change the displayed text.
Return value: an identification key to the object.
See also:
AddStatusField,
AddTag,
AddEditBox,
Direction commands for object positioning,
MakeStretchable,
UpdateTextBoxText.
Makes a certain row in a textbox highlighted. This row does not follow the
text if scrolled. It is a fixed row w.r.t. the textbox widget.
Parameters:
- id: An id to a textbox.
- bgcolor: The background to be used to highlight a row.
- textcolor: if this is not -1 the text on the highlighted row will be
drawn with it.
- row_index: The index to the row that will stay highlighted.
Returns a pointer to a string with the text of the row that is highlighted.
The memory of string belongs to the textbox.
Parameters:
Scrolls the text down one line. This will have no effect if the textbox has no
scrollbar.
Parameters:
Changes the current text of the textbox `id' to the string pointed to
by `string'. A copy of the text is made.
Returns 1 on sucess, 0 if `id' is not valid or does not refer
to a text object.
See also:
AddTextBox.
int HookSpinButtons(int id, int *var, int delta1, int delta2,
int minv, int maxv);
Creates a pair of spin-buttons. These let the user change the value of
the integer variable pointed to by `var'. The value will be increased
by a mouse-press on the up-arrow, and decreased by a press on the down-
arrow.
Return value is the id of the conainer that will be created for the
spin-buttons.
Parameters:
- id: The spin-buttons will be put immediately to the right of the
object refered to by `id'. After a user click and during a "scroll"
the object `id' will be refreshed in order to maintain a correct
displayed value. Typically `id' may refer to an edit-box, but in
some cases a status-field will be better (rarely a drop-down would
be prefered). There are no restrictions on the type of object of
`id'.
- var: A pointer to the variable which value will be uppdated by
the spin-buttons. The memory must of course be allocated while
processing.
- delta1: the steps of increment/decrement at low value of `var'
- delta2: the steps of increment/decrement at high value of `var', use
same value as for delta1 if you want it to be constant for the
entire interval. If delta1 and delta2 differs the currently used
delta will change linear over the value-interval.
- minv: the lower limit of the value of the variabel pointed to by
`var'
- maxv: the upper limit of the value of the variabel pointed to by
`var'
Return value: an identification key to the object.
See also:
AddEditBox,
AddStatusField.
Redraws a specific win-object. If the object contains (recursively) other
object these will also be refreshed.
This function activates an inactive object. An object must be active to
take notice about events like mouse-clicks and hot-keys. Some object
types reflects their `active state' by the colour of its text label.
To make a change visible it is necessary to call Refresh(id);
The default state of an object after its creation is active.
See also:
Refresh,
DeActivate.
The function makes an object inactive, i.e. the object will not take
notice about events like mouse-clicks and hot-keys. Some object
types reflects their `active state' by the colour of its text label.
To make a change visible it is necessary to call Refresh(id);
An inactive object may be re-activated by a call to the function
`Activate'.
See also:
Refresh,
Activate.
void SetObjectGrippable(int id,
void *(*Grip)(void *src, int id, int reason),
int flags, int buttons, void *data);
Set the specified object as grip-able, which means that the user may grip
the object by use of mouse-button (with the intention to later on drop it
somewhere else).
NOTE! An object can't be both "slidable" and "grippable".
This means that objects that by default has the slidable propery
set, will loose that when beeing set to "grippable". For the moment this
will probably only affect edit-boxes, which may loose the ability to get
text marked by use of the mouse if they are set "grippable" with use of
left mouse button (i.e. mouse down and moving will be interpreted as a
drag-drop in stead of as marking text in that case, since there are
obviously no way to ditinguish between the two operations).
You must be aware that the drag-drop mechanism can be used very
dynamically, and carefully handle your pointers. Several disjunct or
overlapping drag-drop channels may be used in parallel (use the flags to
distinguish the data objects dropped). The hot-key handler is in work
during the drag-drop operation, so the user can e.g. close
the window from where the object was gripped, implying that the object
returned by grip must not rely on its window being open.
Parameters:
See also:
SetObjectDroppable,
SetObjectSlidable,
SetListDroppable,
RegisterDragFlag,
UnRegisterDragFlag.
void SetObjectDroppable(int id,
int (*Drop)(void *dest, int id, void *src, int reason, int flags),
int flags, void *data);
Set the specified object as drop-able by installing the call-back
function `Drop'. "Drop-able" means that the user may drop an object
(previously gripped by use of the mouse) on it.
`Drop' will always be called by CGUI at least 3 times for each
drag-and-drop action that is completed by the user. The parameter reason
in the call-back informs which type of call that is concerned. The
`Drop'-function will only be invoked if the following conditions are
fulfilled:
- The destination is active (this is the default state which may be
changed by Activate/DeActivate).
- The destination has at least one drop-flag that matches the source
(i.e. AND-ing them results in non-zero).
- Some gripped object is either:
- over the destination or
- is not over the destination now, but was previously
The interpretation of the reason parameter at call-back:
- DD_OVER_DROP tells that some object has been gripped, and is being
dragged over `dest' object and that the flags of the source and
the destination object is matching
- DD_END_OVER_DROP tells that there is no longer an object over
The DD_OVER_DROP and DD_END_OVER_DROP calls may of course be
repeated any number of times depending on the actions by the user.
If one object has received DD_OVER_DROP and the cursor moves
directly to another object, the DD_END_OVER_DROP will come to the
first one before DD_OVER_DROP comes to the new one.
NB! A pair of DD_OVER_DROP and DROP_OVER_END doesn't indicate a
successful drop. These calls are only intended to give your
call-back function the opportunity to e.g. highlight the
destination object to indicate for the user that it is drop-able.
- DD_SUCCESS tells that the source object has been dropped on the
destination object. This call will be issued after the
DD_SUCCESS-call to the Grip-function of the gripped object.
Parameters to `SetObjectDroppable':
- id: the id-key of the object concerned
- Drop: a call-back function written by you.
Parameters of the call-back function "Drop":
- dest: the address of the actual object (the parameter object in
the call to SetObjectDroppable is transparently transmitted)
- id: the id of the drop-object
- src: the address of the actual source object that is gripped (the
parameter object in the call to SetObjectGrippable is
transparently transmitted).
- reason:any of the DD_* flags listed above
- flags: resulting value of the flags of the gripped object and the
object dropped on. If no special Drop-handling is required, Drop
may be set to NULL.
- flags: function of flags see SetObjectGrippable. The drop-flags will
be stored separately from the grip-flags, they don't need to be the
same for a certain object.
- data: Any data transparently passed to Drop in all calls.
See also:
Activate,
DeActivate,
SetObjectGrippable,
SetObjectSlidable,
SetListDroppable.
void SetObjectSlidable(int id,
int (*Slider)(int x, int y, void *data, int id, int reason),
int buttons, void *data);
This function is used by CGUI internally and is exported just for
completeness, for the moment I can't see any use for it in an application
program.
NOTE! An object can't be both "slidable" and "grippable".
`SetObjectSlidable' set the specified object as slidable, which means
that the user may grip the "hot" area of the object by use of
mouse-button (with the intention to slide the hot area (or maybe a part
of it like a handle) to another part of the object, within the visible
area).
Parameters to SetObjectSlidable:
- id: the id-key of the object concerned
- Slider: a call-back-function defined in your program that will be
called by CGUI, first when gripped, then for each movement.
Parameters to `Slider':
- x,y: the current coordinates (within object)
- data: a pointer to some data
- id: the id of the object
- reason: the reason why Slider was called, this may be either of:
- SL_OVER mouse cursor is over
- SL_OVER_END mouse cursor is not over but was previously
- SL_STARTED dragging did just start (mouse button is now down)
- SL_PROGRESS dragging is in progress
- SL_STOPPED mouse button released
- buttons: The mouse buttons for which "sliding" shall be allowed. The
slide event-type can not co-exist with the "grip" event-type.
If you e.g. assign "slide" to the left button it will be impossible
to grip the object with the left button, but click and double-click
will be OK.
- data: pointer to the data that later on (when the events occurs)
will be passed to "Slider"
See also:
SetObjectDroppable,
SetObjectGrippable.
void SetObjectDouble(int id, void (*DoubleCall)(void *),
void *data, int button);
Makes an object being double-clickable. "DoubleCall" will be called after
a successful double-click.
Assigning double-click e.g. to the left button allows the left button
to be used for single clicks to on the same object (the single click is
not issued until the "doubleclick" delay has expired). In addition the
same object may be either possible to slide or to grip with the same
button (the click and double-click events will not be launched until
"slidedelay" or "gripdelay" respectively time has expired)
Parameters:
- id: the id-key of the object concerned
- DoubleCall: The call-back function. It will be passed the "data"
pointer.
- data: the data to be passed to "DoubleCall"
- buttons: The double-click event can co-exist with all other event
types
Applies the text `text' to the object `id' to be used as a tool-tip text.
If `text' contains `_' characters these will be interpreted as new lines.
About tool tips: These are messages popping up to the user when moving
the cursor over an object. This can be needed for 2 purposes
- The object has only an icon, and maybe the user don't understand
what command it represents.
- The object has a text label, with or without an icon, but there are
needed som more information that will not fit into a label.
Return value: 1 on sucess else 0 (i.e. `id' is not valid).
Specifies how the object `id' will be viewed. If you switch any of the
two first flags you need to call `DisplayWin' ance again if that has
already been done.
Also the tool tip viewing can be controlled by 'SetView'.
Parameters:
- id: The id-key of the object concerned.
- flags: Any of the following option may be used in any combination:
- SV_HIDE_LABEL: If `id' has both an icon and a label then only the
icon will be shown.
- SV_HIDE_ICON: If `id' has both an icon and a label then only the
label will be shown.
- SV_NO_TOOLTIP: Deactivates the drawing of tool tips.
- SV_PREFERE_BRIEF: Ignored if `SV_NO_TOOLTIP' is set. If the
object has both a tool tip text and a label text then the label
text will be viewed as tool tip. Viewing tool tips will
be skipped either if none of texts are present or if there is
only a label text and it is already visible as label.
I.e. briefly: "show tool tips when possible without repeating
info, prefere brief info if there is a choice".
- SV_PREFERE_LONG: Ignored if `SV_NO_TOOLTIP' is set. If the
object has both a tool tip text and a label text then the tool
tip text will be viewed as tool tip.
I.e. briefly: "show tool tips when possible without repeating
info, prefere long info if there is a choice".
- SV_ONLY_BRIEF: Ignored if `SV_NO_TOOLTIP' is set. If the
object has a label text then the label text will be viewed as
tool tip if it is not already used as label.
I.e. briefly: "show tool tips when possible without repeating
info and there exists a brief text".
- SV_ONLY_LONG: Ignored if `SV_NO_TOOLTIP' is set. Only if the
object has a tool tip text there pop up a tool tip.
If an object has both a label and an icon and none of the flags
SV_HIDE_LABEL and SV_HIDE_ICON are specified (the default case) then
both of them will be drawn as a part of the object.
Only one of the flags SV_PREFERE_BRIEF, SV_PREFERE_LONG, SV_ONLY_BRIEF
and SV_ONLY_LONG can be specified. The default setting is SV_PREFERE_LONG.
If `id' is some container rather than a simple object this command will
affect also all the descendants of `id'.
Return value: 1 on sucess else 0 (i.e. `id' is not valid).
This function sets a start delay that cgui will wait until a tooltip is
displayed. The setting is global. The default value is 0.
This function sets tool tip animation. The tool tip will slide in from
left moving `step' pixels with `delay' milliseconds between each move.
A step of 0 disables the animation of tooltips. The setting is global.
The default value is 0 for both step and delay.
This function will call `Destroy' but it will also clean up the screen
from the object(s), i.e. the background of the containing node will be
drawn on the area of the former object. The containing node will however
not be rebuild, i.e. all the remaining objects will keep their
positions.
You don't need to call `Destroy' when you want to close a window,
`CloseWin' will take care of all objects in it.
In general the userinterface will be better if you avoid to remove
single objects. If your program goes into a state such that some
object(s) will be redundat or constitue illegal selecteion(s), then it
is better to deactivate them.
See also:
Destroy,
CloseWin,
DeActivate,
Activate.
This function frees all memory associated with the specified object `id'.
If the object contains other objects, like e.g. containers and
tab-windows do, all the sub-objects will be removed too (recursively).
The screen will remain unchanged.
See also:
Remove,
DisplayWin.
Returns the mouse button (left or right) that was latest pressed on the
specified win-object.
Return value: 1 on sucess else 0 (i.e. `id' is not valid).
Places the mouse pointer above the object.
Modifies the window-header text with the text of "newlabel". An
additional call to refresh is necessary to make the changes visible.
int AddHandler(int id, void (*Handler)(void *data), void *data);
Installs the application call-back function "Handler" and "data" into a
window object.
Objects like check-boxes, radio-buttons etc. normally doesn't need any
call-back, so when creating these you don't need to specify any call-back
function. In some cases it may however be convenient to get a call-back
for user events to these object types. E.g. if your program needs to
activate/deactivate other objects directly when the state of an check-box
is changed. In these case "AddHandler" may be used for installing such an
optional handler.
Not all type of objects support this facility. Return value 0 tells that
the installation failed. Currently the following object types supports
the optional Callback to be installed: edit-boxes, radio-buttons,
check-boxes, drop-down boxes, sliders and flip-objects.
In case of an edit-box, you are probably interested in getting some
information about the editing that is in progress (maybe you want to
distinguish between a letter-key-press and a carriage-return key-press).
Call for GetEditData to get available info. For edit-boxes your call-back
will be invoked before handling the event (the pressed key), in case of
other object types the event will be processed first.
Parameters:
- id: the id-key of the object concerned
- Handler: a pointer to a function written by you. It will be called
in case of user event, and the pointer data will be transparently
passed
- data: a pointer to any of your data
Return value: 1 on sucess else 0 (i.e. `id' is not valid).
See also:
GetEditData.
Mouse button alternatives: LEFT_MOUSE, RIGHT_MOUSE
Thid function changes the specified objects sensibility for clicks to
the specified mouse button(s). (default is the left mouse button)
Return value: 1 on sucess else 0 (i.e. `id' is not valid).
This is for the "drag-and-drop" facility. Some part of your application
may use some flag(s) for some object(s). If there is a risk that the same
flags may used for different purposes (e.g. the printer-monitoring
function uses bit 31), you should register the flags before using them.
Return value: 0 if none of the bits was already registered, else the
occupied bits.
Use the return value to determine if it is safe to activate the
drag-and-drop.
NOTE! Dropping of unexpected objects will _in best case!!_ crash your
program!
Parameter:
- flag: The integer containing the bit(s) (not the bit-number). The
bit(s) will be registered unconditionally.
This function unregister the flag(s).
Return value: 0 if none of the bits was already registered, else the
occupied bits.
Parameter:
- flag: The integer containing the bit(s) (not the bit-number). The
bit(s) will be unregistered unconditionally.
void RegisterRefresh(int id,
void (*AppUpd)(int id, void *regdata, void *calldata, int reason),
void *regdata);
Will register a callback-function for the widget `id'. This function
will be called, whenever your program calls `ConditionalRefresh'
Since the registration is associated with a widget it there will be
an automatic unregistration when that widget is removed.
The name indicates that the purpose of the call-back is to make some kind
of screen update, which was also the original purpose. However, the
functionality may be used for arbitrary purposes.
If you register several "refreshers" and not all of them needs to be
involved each time, you can let the function calling `ConditionalRefresh'
make a directed "message" by passing different `reason' parameters and
let the AppUpd functions examine it when called.
If several AppUpd functions will call `Refresh' for different or maybe
even the same object, that would have lead to a sequence of blits to
screen. However during the `ConditionalRefresh' call the blitting is
temporary tyrned off, and a final blit is issued at end of the call (a
minimal area will then be blitted)
Parameters:
- id: The id to the widget to register this call-back function for.
- AppUpd: A pointer to a callback function written by you.
Parameters to AppUpd:
- id: The id of object registered for.
- regdata: The registered data.
- calldata: A pointer to the data specific for the call, passed by
you when calling `ConditionalRefresh.
- reason: Some value. Passed via `ConditionalRefresh'
- regdata: A pointer to some data that will be passed to `AppUpd' when
called. This will be registered together with `AppUpd' in the widget.
See also:
Refresh,
ConditionalRefresh.
Will call all `AppUpd' functions registered by `RegisterRefresh'. The calls
will be performed in a top-down manner over the widget tree, starting at
the root window. If an `AppUpd' function removes the widget that it is
registered for, the refresh will stop.
Even if several of the called `AppUpd' calls `Refresh' for one or several
widgets, there will be a single screen update at the end.
Parameters:
- calldata: A pointer to some data that will be passed to all `AppUpd'
- reason: Any value. This will be passed to all `AppUpd', and can be
used by these functions to filter out the desired calls.
See also:
Refresh,
RegisterRefresh.
This function simulates a single mouse click (left) on the object `id'
int MakeStretchable(int id, void (*Notify)(void*), void *data,
int options);
This function creates a "handle" on the right and bottom edges of the
object, and a "handle" at the right bottom corner of it.
This makes it possible for the user to adjust the width and height of the
object. The handle in the corner makes it possible to stretch both width
and height at the same time.
The "handles" are invisible, but the mouse cursor will change its shape
when moving it over them.
All objects are allowed to be stretchable, but not all will notify the
stretching, e.g. a container that have an ADAPTIVE size, will after the
re-sizing operation immediately return to its previous size calculated as
the minimum to show all its contents (i.e. ADAPTIVE overrides
stretching).
Parameters:
- listid: the id of the list to be stretchable
- Notify: an optional call-back function that will be notified when
the the size of the object has been changed. The new size
(difference from the size initially calculated by CGUI) may be
achieved by a call to GetSizeOffset, and may later be stored by
your program to make it possible to start the program next time
with the size of the object that the user likes. Pass NULL if you
don't need the call-back.
- data: a pointer to some data that will be passed to `Notify' when
called by the object. Pass NULL if not used.
- options: may be used to inhibit bottom or right side handle (and
only want it to be stretchable in one direction). Macros:
NO_HORIZONTAL and NO_VERTICAL
Return value: 1 on sucess else 0.
See also:
GetSizeOffset,
SetSizeOffset,
continous_update_resize.
This function may be used to get the changes in size of an object. A
change of the size may only occur if it is stretchable (or if the size
has been adjusted with SetSizeOffset).
Return value: 1 on sucess else 0 (i.e. `id' is not valid).
See also:
SetSizeOffset,
MakeStretchable.
This function may be used to adjust the size of an object. A default size
of an object is always calculated at creation time (normally this is the
size enough to carry its label or icon). This size may be changed by this
function. Typically it is used in conjunction with GetSizeOffset to
restore the size of objects modified by user after a window has been
closed and re-opened.
Note: If justification commands like FILLSPACE are used in conjunction
with the relative positioning of an object (like DOWNLEFT etc) this may
override the offset setting.
The function must be called before the call to 'DisplayWin' to have
effect.
Return value: 1 on sucess else 0 (i.e. `id' is not valid).
See also:
DisplayWin,
GetSizeOffset,
MakeStretchable.
Moves the "logical insertion point" where new objects will be added
to after the `id' object. Any new objects that you add after calling
this function will be positioned as if they were added right after
`id' was added.
This can sometimes be meaningful when you make changes in a container
that already has object positioned with "direction commands".
The new "logical insertion point" is local to the container where `id'
lives.
Changes that are made in a window after it has been made visible (by
a call to `DisplayWin') will not be visible until `Refresh' is called
for appropriate part of the window. If "direction commands" are used,
the appropriate parts, which is normallay the entire window, of the
window also needs to be re-built (by a call to `ReBuildContainer') before
the refresh. Both will be done for the entire window if you call
`DisplyWin' again.
Returns 1 if id referes to an existing object, otherwise 0.
See also:
Objects,
SetOperatingWindow,
SelectContainer,
Direction commands for object positioning.
int MkVerticalBrowser(int x, int y,
void (*CallBack) (void *data), void *data, int *viewpos);
Creates a vertical "browsing object" consisting of one bar with a slider
handle for browsing and scrolling, and two scroll buttons.
The usage is quite staight forward, and the easiest way to unserstand is
to look into the browse example in the `examples' directory of CGUI.
For a detailed description the following naming convention is
introduced:
- "browsing object" - this object (the user can use it to browse and
scroll in another object, the "browsed object").
- "browsed object" - this can be any other object which displays
something that possibly is to large to be shown all at once.
- "view port" - is the area on the screen where the user can see
(possibly a part of) the "scrolled area". The "view port" may be
the same as the area of the "scrolled object", but also less (if
the "scrolled object" e.g. has some kind of frame).
- "scolled area" - the area to show in the "view port"
(if longer than the "view port" the user will be able to scroll or
browse it to be able to see other parts of it).
- "scrolling resolution" - for certain useges is quite enough for the
user if the "scrolling area" jumps ahead more than one pixel at a
time. A lower resolution (more pixels of jump) will speed up the
scrolling. The least scrolling resolution is 1.
The "browsing object" performs all calculations needed and call a
function of yours (see below) when the user interacts with the "browsing
object".
At some point your program may want "scrolled area" to move within
the "view port". It can then inform the "browsing object" about the new
state, see `NotifyBrowser'.
The size of the "scrolled area" may for some reason change during the
program execution. This will be the case e.g. if the thing to display is
an image and you provide the user with a tool to zoom the image or to
change to some (different sized) image. Also in such cases you need to use
`NotifyBrowser' to tell the "browsing object" about the new size.
During program execution the size of the "view port" may change (as
well as the prefered size of the "browsing object") in which case you
can use `SetBrowserSize' to inform the "browsing object" about it. (A
change of the "view port" size typically can occure if the "browsed
object" is possible to re-size by the user.
Parameters:
- x,y: The position of the "browsing object" (you can use "direction
commands" as well as numeric coordinates). Probably you want this
to be to the RIGHT of the "browsed object".
- CallBack: A function written by you. It will be called any time when
the user has used any of the scroll buttons or the slider handle.
The main purpose of this function is to update the area within
"view port".
Parameters:
- data: The data pointer you passed to `MkBrowser'.
- data: A pointer to any data that you want to be passed to `CallBack'.
- viewpos: A pointer to a variable of yours that specifies the start
position of the "scrolled area" in the "view port" (number of
pixels). The browser will both read and update the value of that
variable.
If the current "scrolled area" is smaller than the size of
the "view port" (set by `SetBrowserSize') then the "browsing object" will
deactivate itself.
The sliding handle will change its length as expected if the the
"scrolled area", "view port" or "browsing object" changes its size.
Return value: 1 on sucess else 0.
See also:
NotifyBrowser,
SetBrowserSize,
Direction commands for object positioning.
int MkHorizontalBrowser(int x, int y,
void (*CallBack) (void *data), void *data, int *viewpos);
Creates a horizontal "browsing object". See `MkVerticalBrowser' for
details.
See also:
MkVerticalBrowser.
Forces the "browsing object" `id' to update its status according to the
parameters. NOTE! You also need to call `NotifyBrowser' if you change the
value of the variable pointed to by `viewpos' (see `MkVerticalBrowser')
so the "browsing object" can make necessary re-calculations according to
the new position.
Parameters:
- id: The id of the "browsing object".
- step: The "scrolling resolution" in pixels.
- scrolled_area_length: The length of the "scrolled area" in pixels.
- viewpos: The start position of the "scrolled area" that currently
is to be viewed in the "view port" (in pixels).
Return value: 1 on sucess else 0.
This function makes no update of the screen.
See also:
MkVerticalBrowser,
SetBrowserSize.
int SetBrowserSize(int id, int view_port_length, int browsing_length);
Specifies the dimensions for a browsing object.
Parameters:
- id: The id of the "browsing object".
- view_port_length: The length of the "view port" ("length" means
either width or height depending on if it is a horisontal or
vertical browser).
- browsing_length: The desired length of the "browsing object" itself.
("length" means either width or height depending on if it is a
horisontal or vertical browser).
Returns 1 if sucess else 0.
This function makes no update of the screen. It can be useful if the
browsed object is re-sized (see `MakeStretchable').
See also:
MkVerticalBrowser,
NotifyBrowser,
MakeStretchable.
This is a global variable that controls the updating behaviour of an
object when stretched by the user.
If continous_update_resize is set to 0 (default), then the object that is
stretched by the user will not show its new size until the user releases
the mouse button that gripped the stretch-handle.
If continous_update_resize is set to 1, then the object that is
stretched by the user will continously show the current size.
See also:
MakeStretchable.
In CGUI you can specify the position of object using co-ordinates
explicitly, like
AddButton(13, 132, "Cancel", my_func, my_dataptr);
However, you will probably re-design your window a number of times during
development, and each time you will probably need to re-calculate the
position of the "Cancel".
In order to make the development process more convenient for you, CGUI
provides the "Direction command" facility. This means that you
just need to tell the direction of the object related to the recent ones.
The call will instead look like e.g.:
AddButton(DOWNLEFT, "Cancel", my_func, my_dataptr);
The position fo the "Cancel" button will be calculated in run-time and it
will adapt to the contents above as well as the run-time calculated size
of other objects. It's highly recommended that you use the "direction
commands" instead of explicit co-ordinates. It's also highly recommended
that you combine this with the 'ADAPTIVE' feature of windows and
containers to make your life easier.
The following 3 "direction commands" are the most "easy to use" ones,
when using them think of adding object like when typing text (from left
to right, from top to bottom):
- TOPLEFT will put the object in the top left corner of the container
(or window).
- RIGHT will put the object on the right side of the previously
created object, and the top edges of the two will be aligned.
- DOWNLEFT will put the object at the beginning of a "new row", i.e.
at the left edge of the container (or window) and below the bottom
edge of the prevous "object row".
The below ones are used by CGUI itself, and may occasionally be useful
for other purposes.
- DOWN puts the object below the previous one (aligned left edges).
- LEFT will put the object on the left side of the previous object,
withe aligned top edges. (i.e. it is meaningful to issue a 'LEFT'
object only after a RIGHT|ALIGNRIGHT or DOWN)
The following additional fill flags may be combined with a direction
command. The main point is create rows or columns with nice looking
object groups. Normally you should set the same flag to all objects in
such an "object row" or "object column".
- FILLSPACE: The objects in the "object row" or "object column" will
fill all available space in the container (or window), or to be more
precise:
All space found between a "sequence of n objects", before the
left one and after the right one will first be summed. The space
needed for the current distance will be subtracted from that.
The rest will be divided into n equal sized pieces. Each object will
the get its auto calculated size extended with that amount of pixels.
The "sequence of objects" is defined as some consecutive objects
with identical "additional commands" and the same top co-ordinates.
By default the space-filling will be horizontally. If you want
vertical filling the add the VERTICAL flag.
Optionally you may also specify both VERTICAL and HORIZINTAL to make
it fill up in both directions.
- EQUALHEIGHT: All objects in an "object row" will get the same
height as the one that requries the biggest height.
- EQUALWIDTH: All objects in an "object column" will get the same
width as the one that reqiures the biggest width.
- VERTICAL: This will only be notified as an specification to
FILLSPACE.
You are allowed to use the flags above to fill the space around any
sequence of objects, including other sub containers. However the result
will not always be as expected if their sizes are 'ADAPTIVE' since the
size of such containers are calculated after the positions of the entire
object tree has been calculated.
The "align"-flags will align the object to an edge of the container (or
window).
Both flags may be applied to the same object.
If you use ALIGNRIGHT for more than one object on the same "object row",
these will overlap (there is an analogous problem with
ALIGNBOTTOM).
- ALIGNRIGHT This flag will align the object to the right of a
container (or window).
- ALIGNBOTTOM This flag will align the object to the bottom of a
container (or window).
- ALIGNCENTRE This flag will centre in x-direction. Other object on the
same y-level will make objects messed up. May be combined with
ALIGNBOTTOM.
The "insertion point" of a new object will normally be after the
previously added one in the same container. You can modify the insertion
point using the function `InsertPoint'.
Functions that creates visible objects returns an id-number. This number
is unique.
For simple usage of the GUI you don't need this id. For advanced usage
there may sometimes be necessary to later on (when the window creation
has already been finished by a DisplayWin-call) refer to an object. In
these cases you have to save the id-number returned by the
object-creating function, and make use of it when you are about to call
the CGUI-function that reqiures the id-number.
Typical CGUI-functions that needs the id-number are Activate, DeActivate,
Refresh, Remove, Destroy.
Since the id-number is unique for the entire application you can as well
access objects in an "old" window (not the top one). Specially the
`Refresh' may be useful in this case.
Some of the CGUI-functions will apply to an entire group of objects if
you refer to a node object like a container, a list, a window etc.
If the specified id-number is not found the operation is ignored.
Note! Removing a single object will not give you any problem (i.e. CGUI
will not give you any), but it is not intuitive for the user -
deactivation is better than removing. Adding objects to an already
existing ADAPTIVE window may raise the problem for your program to
determine where it may be free space in the window to avoid overlapping
(remember that the direction command will refer to the "previous object"
object).
Some objects are of "container type". That is an object that contains
other objects. Examples of containers:
- Container
- Tab-window
- List-box
- Radio-group
- The menu-bar
The functions that create containers will also return an id-number.
A menu bar has to be "opened" first. The menu bar serves as a container
for the different menus. It is required one call for each menu. Each of
them will establish a call-back function. It is necessary to terminate
the sequence of created menus by "closing" the container.
Each menu is connected to a call-back function which is a part of the
application. This call-back function will be activated when the user
wants to drop down the menu. The only thing it shall do is to create the
items in the dropped down menu. Each of these are in the same manner
connected to a call-back function, which may either drop yet another
(sub-)menu or perform a direct action.
See also:
Objects,
Containers,
Windows,
Listboxes,
Tabwindows.
Creates a container specially designed for entering menus-items in a
window. The point is to issue subsequent calls to MkMenuBarItem.
NB! The sequence of calls to MkMenuBarItem must be terminated by a call
to EndMenuBar. If you forget this other objects will be placed together with
the menu-items, and it will all look junky.
MakeMenuBar returns an id-number.
See also:
EndMenuBar,
MkMenuBarItem.
Closes a container opened by MakeMenuBar.
See also:
MkMenuBarItem,
MakeMenuBar.
int MkMenuBarItem(const char *text, void (*CallBack) (void *), void *data);
Creates one menu-item within an opened menu bar (opened by MakeMenuBar).
Return value: the id of the menu item (non-zero)
Parameters:
- text: the menu text to display
- CallBack: a pointer to a function written by you. This function will
be called by CGUI when the user wants the menu to be dropped down.
Prior to the call, CGUI has prepared for receiving calls from
your `CallBack' in order to create menu-items (i.e. calls to
MkMenu*). There is no restriction on the object types that may be
created by `CallBack', but the menu may appear crazy if you put
other than the special menu-item-objects there (the menu and the
menu items co-operate in the event processing to make mouse events
and key-presses to work as expected). `CallBack' is supposed to NOT
open or close any window, since a window build is in progress when
it is called. The parameter passed to CallBack is the "data"-pointer
that you pass as last argument.
- data: a pointer to any data that you want your call-back function to
receive.
See also:
MakeMenuBar,
MkMenuItem,
MkMenuRadio,
MkMenuCheck.
`MkScratchMenu' will immediately drop down a menu and invoke `CallBack'.
The position of the menu will be at the mouse cursor position.
Return value: the id of the drop-menu (non-zero)
Parameters:
- id: typically you want a scratch-menu dropped down if the user
clicked on a certian object. If you prefere that the menu shall be
placed at the edge of this object rather than above it, then pass
the is of that object.
- CallBack: a pointer to a function written by you. This function will
be called by CGUI when the user wants the menu to be dropped down.
Prior to the call, CGUI has prepared for receiving calls from
your `CallBack' in order to create menu-items (i.e. calls to
MkMenu*). There is no restriction on the object types that may be
created by `CallBack', but the menu may appear crazy if you put
other than the special menu-item-objects there (the menu and the
menu items co-operate in the event processing to make mouse events
and key-presses to work as expected). `CallBack' is supposed to NOT
open or close any window, since a window build is in progress when
it is called. The parameter passed to CallBack is the "data"-pointer
that you pass as last argument.
- data: a pointer to any data that you want your call-back function to
receive.
See also:
MkMenuBarItem,
MkMenuItem,
MkSingleMenu.
int MkSingleMenu(int x, int y, char *label, void (*CallBack) (void *),
void *data);
`MkSingleMenu' does the same work as `MakeMenuBar' + `MkMenuBarItem' +
`EndMenuBar' with one call to `MkMenuBarItem'. I.e. it creates amenu-bar containing
one menu-item. It looks slightly different (it is indicated that it is a
menu by a "down-arrow".
Return value: the id of the menu (non-zero)
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- label: the label text that will be displayed on the menu
- CallBack: a pointer to a function written by you. This function will
be called by CGUI when the user wants the menu to be dropped down.
Prior to the call, CGUI has prepared for receiving calls from
your `CallBack' in order to create menu-items (i.e. calls to
MkMenu*). There is no restriction on the object types that may be
created by `CallBack', but the menu may appear crazy if you put
other than the special menu-item-objects there (the menu and the
menu items co-operate in the event processing to make mouse events
and key-presses to work as expected). `CallBack' is supposed to NOT
open or close any window, since a window build is in progress when
it is called. The parameter passed to CallBack is the "data"-pointer
that you pass as last argument.
- data: a pointer to any data that you want your call-back function to
receive.
See also:
MkMenuBarItem,
MkMenuItem,
MkScratchMenu,
Direction commands for object positioning,
Labels.
int MkMenuItem(int sub, const char *text, const char *shortcut,
void (*CallBack) (void *), void *data);
Creates one menu-item within a dropped down menu. There is actually
two different types that can be created by this function: (1) A menu-item
that is the selection point for a sub-menu, and (2)a menu-item that is
just a simple selection (that closes all menus).
Return value: the id of the menu item (non-zero)
Parameters:
- sub: A flag indicating if this menu-item will open another sub-menu
or if it is just a direct selection.
- label: The text to label the menu-item. See section `Labels' for
details about commands embedded in the label-string.
- shortcut: another (optional) text. This text is right-aligned. It is
intended to be used to inform about a shortcut. Just pass the empty
string ,"", if you have no need for it. (There is no check for this
short-cut, it's up to you to tell the truth to the user).
- CallBack: A pointer to a function written by you.
Case (1), `sub' was non-zero: This function will
be called by CGUI when the user wants the menu to be dropped down.
Prior to the call, CGUI has prepared for receiving calls from
your `CallBack' in order to create menu-items (i.e. calls to
MkMenu*). There is no restriction on the object types that may be
created by `CallBack', but the menu may appear crazy if you put
other than the special menu-item-objects there (the menu and the
menu items co-operate in the event processing to make mouse events
and key-presses to work as expected). `CallBack' is supposed to NOT
open or close any window, since a window build is in progress when
it is called.
Case (2), `sub' was zero : This function will be called when the user
selects this item. The menu(s) will be closed before the call. There
is no restriction on what the CallBack can do (actually a typical
task is probably to open or close some window).
The parameter passed to CallBack is the "data"-pointer that you pass
as last argument.
- data: A pointer passed to "CallBack".
See also:
MkMenuBarItem,
MkMenuRadio,
MkMenuCheck,
MkGroove,
Labels.
Works similar to AddRadioButton, but is intended only for menus.
Return value: the id of the menu item (non-zero)
Parameters:
- selvar: the variable which value is controlled by the radio-buttons
(and which value contols the initial display of them).
- n: the number of radio-buttons connected to "selvar". The first one
representing value 0, next value 1 etc.
- ...: This must be (NOTE IMPORTANT!)exactly n text-strings, each
one telling the text label to put on the corresponding radio-button
selector
See also:
AddRadioButton,
MkMenuCheck,
MkMenuItem.
Works similar to AddCheck-button, but is intended only for menus.
Return value: the id of the menu item (non-zero)
Parameters:
- checkvar: the variable which value is controlled by the check-button
(and which value cont rols the initial display of it).
- text: the label of the selection
See also:
MkMenuRadio,
MkMenuItem,
AddCheck.
This function installs CloseHook. This is a pointer to a function written
by you. It will be called when the menu is closed.
HookMenuClose will do nothing if it is not called from a "menu drop-down"
-function like the call-back passed to `MkMenuItem'. Actually it will do
the same thing as `HookExit', with the difference that you don't need
to now the id-number (which you normally don't know).
The benefit of installing the CloseHook may be e.g. to get the chance to
free memory allocated by the drop-down function. If the menu is closed
because the user made a selection of an item (or some item in a sub-menu)
the call-back of that item will be called prior to CloseHook.
Returns non-zero on sucess.
See also:
MkMenuItem.
A horizontal groove will be put into any node as a delimiter. The purpose
is to visually group objects into logical groups. This may be specially
useful in menus.
Return value: the id of the groove
See also:
Menus,
Objects.
About Container objects:
"Container" is a recursive (or "nested") construct. This means that a
container may contain an arbitrary number of objects that themselves
may be containers or "simple" objects like push-buttons etc.
The nesting may be done in arbitrary number of levels.
A container is just a rectangular fraction of its parent window (or
container), normally used to group together some objects to make
the window more attractive for the user.
Sometimes you may want it simply for grouping objects without seeing the
container itself. Another time it may be used to make a more distinct
group of objects with a frame and a label informing user about its
content. Yet another time it may be used just to force a sequence of
objects to be of the same size.
See also:
Objects,
Windows,
Menus,
Listboxes,
Tabwindows.
int StartContainer(int x, int y, int width, int height, char *label,
int options);
The objects in a window may be grouped into containers. Objects created
between StartContainer and EndContainer will refer to the co-ordinates
of the container. This also applies to direction commands (like TOPLEFT,
DOWNLEFT, RIGHT..) as well as explicit x,y-co-ordinates. The objects will
"belong" to the container. This means that if the container later on is
deleted (by a call to `Destroy') all the objects in the container will
also be destroyed. After `EndContainer' has been
called, all subsequently added objects will be put into the same window
or sub-window as where the container is (it works like "closing" the
container for input).
Return value is the id of the container.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- width,heght: size of the container. If width,heght is replaced by
the ADAPTIVE command the container will be large enough to show all
its content.
- label: an optional text to be displayed as a label of the container.
If omitted (i.e. empty string), then no space is reserved for it in
on the screen.
- options: CT_BORDER and/or CT_OBJECT_TABLE
- CT_BORDER outlines the container with a border line. If a label
is passed the line will be broken to make place for the label.
- CT_OBJECT_TABLE which simply joins the container to the
"tab-chain" as a node. To work correctly it requires that you
put the objects in a tabular form. It is only possible to make
a CT_OBJECT_TABLE in one level of nesting.
See also:
EndContainer,
JoinTabChain,
Direction commands for object positioning,
Containers.
Closes a contaioner created by `StartContainer'.
See also:
StartContainer.
This function will select the container (node) `id' as input for
subsequently created objects. If the node `id' is not in the currently
operating window, the window of `id' will be set to operating.
See also:
StartContainer,
SetOperatingWindow.
This function sets the space used by CGUI when deciding positions for
objects that has been added with the "direction commands" like `RIGHT',
`DOWN' etc. and when deciding the size of a container or window that is
created with the `ADAPTIVE' size.
You can do the same, but specify measurments more detailed, by using
`SetSpacing'.
See also:
SetSpacing.
int SetSpacing(int id, int left, int h, int right, int top, int v, int bottom);
This function sets the space used by CGUI when deciding positions for
objects that has been added with the "direction commands" like `RIGHT',
`DOWN' etc. and when deciding the size of a container or window that is
created with the `ADAPTIVE' size.
The settings will affect the container or window specified by `id'. The
changes will be visible the next time you call `DisplayWin' or
`ReBuildContainer'.
Parameters:
- left: Space between the left edge of a container (or a window client
area) and the leftmost object.
- h: Space between any two objects related with the `RIGHT' or `LEFT'
direction commands.
- rightx: Space between the right edge of a container (or a window client
area) and the rightmost object.
- top: Space between the top edge of a container (or a window client
area) and the upper object.
- v: Space between any two objects related with the `DOWN' or `DOWNLEFT'
direction commands.
- bottom: Space between the bottom of a container (or a window client
area) and the lowest object.
The return value is 1 if `id' is a valid id of a container, else 0.
See also:
MkDialogue,
StartContainer,
Direction commands for object positioning,
ReBuildContainer,
DisplayWin,
SetDistance.
This function will re-build a container. If you add objects into a container
when the window has already been displayed (with a call to DisplayWin) you
can use this function make up the container only. Calling DisplayWin once
again will also work fine, but will update the entire window.
See also:
StartContainer,
DisplayWin,
EmptyContainer.
This function will destroy all objects within the specified container.
The image of the objects will not be removed (the pixels will remain
unchanged in the bitmap of the node). To remove their appearance from
the window you must also re-build the node, e.g. by a call to
DisplayWin();. This is preferably done after inserting new objects into
the node (the need to insert new objects is probably the reason why
'EmptyContainer' was called).
May be useful if minor changes needs to be made to a window (typically
extending or shrinking the window).
See also:
StartContainer,
ReBuildContainer,
DisplayWin.
A list-box is a node that contains a number of row-objects. If necessary
there will be a "browse-handle" and two scroll-buttons beside the listbox
(they will appear when the list contains more objects than there are
rows).
You must write at least 2 functions (normally 3). You must make 2
function calls (e.g. `AddList' and `SetIndexedList').
The functions you have to write is:
- A function that receives a pointer to the entire list-data, and
returns a pointer to a specific object within the list.
- A function that generates the text to be drawn on one row. This
string is made up from the object returned from the above function.
- Normally you want your program to be notified if the user clicks on
a row. You must write a function that is called in such cases.
This maybe sounds more tricky than it really is, here is an example:
int row_text(void *rowdata, char *s)
{
int *row=rowdata;
sprintf(s, "Data is %d", *row);
return 0;
}
void *index_creater(void *listdata, int i)
{
int *arr=listdata;
return &arr[i];
}
void foo(int id, void *rowdata)
{
/* Do something */
}
void make_dialog_with_list(void)
{
/*array and n must be static or dynamic memory, not normal local
variables!*/
static int array[100]={1,2,3,4,5}, n=5, id;
MkDialogue(ADAPTIVE, "Test-window", 0);
/* add more objects here ... */
AddList(TOPLEFT, array, &n, 60, LEFT_MOUSE, row_text, foo, 10);
SetIndexedList(id, index_creater);
/* ...or here if you need */
DisplayWin();
}
The list properties in CGUI is controlled by the following global
variables:
- FONT *CGUI_list_font;
- int CGUI_list_vspace;
- FONT *CGUI_list_row_font;
- int CGUI_list_row_f_color;
- int CGUI_list_row_b_color;
- int CGUI_list_fixfont;
- int cgui_list_fix_digits;
- int cgui_list_no_multiple_row_selection;
It works like this: Each time a list-box is created, CGUI will use the
values of these variables. If you use several list-boxes in your
application and for instance want one of these to use a fix font you
have to set CGUI_list_font to the fix font you have loaded, and then
restore the origin font after the list was created.
The meaning of the variables:
- CGUI_list_font - The font used for the lists. The default
value is CGUI's default font. Lists that are already existing will
not be affected by changes of CGUI_list_font.
- CGUI_list_row_font - The font used for the rows in the list. Changes
will only be notified if set by the list-row drawing function that
you have written. If that function does not assign the
CGUI_list_row_font the default font for the list will be used
instead (i.e. CGUI_list_font).
- CGUI_list_row_f_color - The default text colour of list rows
is black. If you want to change the foreground colour of individual
row you have can do that by assigning a different color to the global
variable CGUI_list_row_f_color. You need to do that in your list-row
drawing function. The setting will be reset by the list-box when the
next row is drawn, so you have to set this for precisely the rows that
you want to have a different color. For a general change of the
background of list boxes rows please see CguiSetColor.
Rows with highlighted background (by default they are blue) because
the user have selected them will not recognise any changes of colour.
- CGUI_list_row_b_color - The default background colour of list rows
is white. If you want to change the background colour of individual
row you have can do that by assigning a different color to the global
variable CGUI_list_row_b_color. You need to do that in your list-row
drawing function. The setting will be reset by the list-box when the
next row is drawn, so you have to set this for precisely the rows that
you want to have a different color. Rows with highlighted
background (by default they are blue) because the user have selected
them will get a color which is a merge between your setting and the
highlight color. There is a heuristic to find a text color that makes
the text easy to read.
- There is a horizontal line delimiting rows in list boxes. This line
has the same color as the list box background by default, making it
invisible. To make the row delimiters visible you have to change
that color before you create the listbox. See CguiSetColor for details.
- CGUI_list_vspace - Determines the height of the total height of the
list rows. The height of a row is the height of the font used + 1
(for the delimiter line) + CGUI_list_vspace. To make a list more
compact you may set a negative value (which may lead to some
characters overlapping). The default value is 0.
- CGUI_list_fixfont - if 0, which is the default value, the text of
the rows in listboxes will be drawn directly by Allegro. If
non-zero, the value is used as the with of each character in the
used font. This may be set individually for each column/row.
This is a workaround to make it possible to draw fix fonts like
'Courier' as fix fonts. The only way to import fonts, as far
as I know, is the ttf2pcx tools program, and it seems to destroy the
fix-width properties of fix-fonts. In some applications fix-fonts
are very necessary.
- cgui_list_fix_digits - This is an alternative to CGUI_list_fixfont.
If non-0 all digits of the string will be drawn with the witdth of
the widest digit within the font and all other characters will be
drawn with their own width. This is useful if you know in advance
that the texts of all rows will contain only digits or digits with
predifined delimiters at certain positions.
This may be set individually for each column/row.
- cgui_list_no_multiple_row_selection - by default the "multiple
rows" property is enabled. If this flag is set this will be disabled
for all lists subsequently created.
CGUI_list_font, CGUI_list_column_delimiter_color and
CGUI_list_rowdelimitercolor will be reset next time calling InitCgui.
See also:
Windows,
Menus,
Containers,
Tabwindows,
Objects,
CguiSetColor.
int AddList(int x, int y, void *listdata, int *n, int width, int mousebt,
int (*RowTextCreater)(void *rowdata, char *s),
void (*Action)(int id, void *rowdata),
int norows);
Creates a list box. NOTE! The list-box is not finished until you have
also called either `SetLinkedList' or `SetIndexedList' (which both
requires a pointer to a function that you have written). To make a
list box work you will need to write a least one more small function
(yet more may be needed, depending on how you configure the list).
This second "small function" is one that calculates which string that
shall be drawn provided some data element.
Parameters:
- x,y: The position of the object (or you can use "direction commands").
- listdata: may be a pointer to any application data, transparently
passed to the xxCreater-function specified by SetLinkedList or
SetIndexedList.
- n: is a pointer to an integer specifying the number of elements that
currently is in the `listdata' (i.e. the number of elements in your
array). This parameter is ignored if you will put the list box into
tree mode. The same applies also if your data to display is in a
linked list, or to be more precise: if you will call `SetIndexedList'.
In such cases you can just pass NULL.
- width: specifies the width in pixels of the list box rows (the frame
and the browsebar will be added to this)
- mousebt: specifies the mousebuttons to be handled when the user
clicks on a row.
- LEFT_MOUSE - Your function `Action' will be called when a row in the list
is clicked by the left mouse button.
- RIGHT_MOUSE - Your function `Action' will be called when a row in the list
is clicked by the right mouse button.
- LEFT_MOUSE+RIGHT_MOUSE - Your function `Action' will be called both when
a row in the list is clicked by the left and the right mouse button.
- 0 - `Action' will never be called.
- RowTextCreater: A call-back function written by you. This will be
called each time a list row has to be drawn. RowTextCreater will be
called with the actual object-pointer `data' (previously created by
the `index' or `next' function) for that row. Its purpose is to
create a the text to be displayed on the row.
Optionally it may also return any of the below attributes (they may
be ored) or return zero if none of them is wanted:
- ROW_STRIKE will generate a line striking trough the text
- ROW_UNDERLINE underlines that row
- ROW_COLUMN_UNDERLINE underlines a particular column of the current
row (only valid in case list box columns are used).
- ROW_CHECK puts a check-mark at the beginning of the row
- ROW_UNCHECK will reserve space at the beginning of the row
Useful to keep a stight column in a list with checked rows
(use ROW_UNCHECK for the unchecked rows).
- COL_RIGHT_ALIGN will align the text to the right edge of the current
column (this attribute is only available in case you have set
columns in the list box).
Parameters to RowTextCreater:
- rowdata: the data created by your `ApplicationDataAtIndex'
or `IterateLinkedListOfApplication' function.
- s: Pointer to an array where `RowTextCreater' is supposed to put
a string to be displayed for the `rowdata'. The string may start
with an image name in which case the image will be diplayed to
the left fo the text. The form of an image name is the same as
for other objects, i.e. #imagename; where `imagename' is the
name of an registered image. See CguiLoadImage for details. There
may be spaces between the '#' and the imagename. To display a
leading '#' on a row you need to put '##' in the string.
- Action: A call-back function that will be called when a row in the
list-box was clicked by the user. If you don't want any action
performed if the user clickes on a row (i.e. if you specifies 0
for the mousebt parameter) then you can pass NULL for Action.
Parameters to Action:
- id: the id of the row-object and may e.g. be used as reference
to obtain information about which of the mouse buttons that
was pressed (in case both are allowed).
- rowdata: the data created by your function `ApplicationDataAtIndex'
or `IterateLinkedListOfApplication' function.
- norows: The number of rows to display at one time (i.e. the height
of the list expressed in rows instead of pixels).
There are lots of options to configure a list box to fit your taste, here
are some global variables that affect the apperance of lists.
- FONT *CGUI_list_font;
- FONT *CGUI_list_row_font;
- int CGUI_list_row_f_color;
- int CGUI_list_row_b_color;
- int CGUI_list_rowdelimitercolor;
- int CGUI_list_vspace;
- int CGUI_list_column_delimiter_color;
Their usage are as follows:
- CGUI_list_font - will be snapped as the default font by the listbox
when it is created.
- CGUI_list_row_font - may be used to change the font for an
individual row. Only `RowTextCreater' can set this, and it will
only be used on that row.
- CGUI_list_row_f_color - may be used to make the text of a single row
to be drawn in a certain colour (default is black)
- CGUI_list_row_b_color - may be used to make the background of a
single row to be drawn in a certain colour (default is white)
- CGUI_list_rowdelimitercolor the color of a pixel line that delimits
the rows in the listbox (default is white)
- CGUI_list_vspace - signed integer specifying a number of extra
vertical pixels int the row height (default value is 0). The base height
of the rows are always the height of the list's default font.
- CGUI_list_column_delimiter_color - this will be the colour of the
column delimiter (only used if SetListColumns has been called, and
the proper flag was passed).
See also the links for functions to configure list boxes.
The return value is the id of the list box.
See also:
ListTreeView,
Refresh,
BrowseTo,
RefreshListRow,
SetIndexedList,
SetListGrippable,
NotifyFocusMove,
SetDeleteHandler,
SetInsertHandler,
HookList,
Listboxes,
SetListColumns,
CguiLoadImage.
int SetIndexedList(int listid, void *(*ApplicationDataAtIndex)(void *listdata, int i));
int SetLinkedList(int listid,
void *(*IterateLinkedListOfApplication)(void *listdata, void *prev));
You have to use one (and only one) of these functions to tell the list box
which function to call when a data item for a row is needed. (this will
happen e.g. when drawing a row or when the user clicks or drags a list
row or some other event that the list box is responsible for).
If the data that you want to display in the list box is organized as a linked
list, then the function `SetLinkedList' is to prefer. If your list-data is an
array then the function `SetIndexedList' might be more convenient for you.
Parameters to these functions:
- listid - the id of a list box (i.e. the value returned from `AddList').
- ApplicationDataAtIndex/IterateLinkedListOfApplication - This should be
a pointer to a function that you have written (an "iterator function").
The work that needs to be done for the creator function is to create a
pointer to some row data object that is understood by your functions
`RowTextCreater', `Action' etc.
Parameters to these functions:
- The input `listdata' will be the pointer that you passed to `AddList'
as the `listdata' parameter.
- prev/i - In case your data is an array (i.e. function
SetIndexedList) then the `i' tells from which index in the array
the datapointer should be returned. In case your data is a linked list
(i.e. function SetLinkedList) then 'prev' tells which is your
previous element, and your function `IterateLinkedListOfApplication'
should return a pointer to the next element (or null if there are no
more elements). If there is no previous element (i.e. the first
element is wanted) then `prev' will be NULL.
A typical function for array data may look something like:
void *my_index_creater(void *listdata, int i)
{
struct MYDATA *d=listdata;
return < d[i];
}
A typical function for linked lists may look something like below.
Note that if prev is set to NULL then the function is supposed
to extract a pointer to the first element using the listdata pointer.
void *my_next_creater(void *listdata, void *prev)
{
/* Here we assume that a pointer to the list head was passed to AddList */
struct MYDATA **m=listdata;
struct MYDATA *p=prev;
if (p==NULL)
return *m;
else
return p->next;
}
Both functions may of course use whatever methods to calculate the data
to return (e.g. the "data" pointer may be a pointer to any structure
which contains a pointer to the head/array, the array may be an array of
pointers etc.). Just another example for linked lists:
void *my_next_creater(void *listdata, void *prev)
{
/* Here we assume that a pointer to the an empty head record was passed to AddList */
struct MYDATA *m=listdata;
struct MYDATA *p=prev;
if (p==NULL)
return m->next;
else
return p->next;
}
And yet a (maybe more practical) example:
void *my_next_creater(void *listdata, void *prev)
{
/* Here we assume that a pointer to some other struct was passed to AddList */
struct MYDATA_MAIN *m=listdata;
struct MYLINK *p=prev;
if (p==NULL)
return m->list_head;
else
return p->next;
}
The return value from SetIndexedList is 1 if a listid is a valid id of a
list, else 0.
See also:
MkDialogue,
DisplayWin,
AddList.
int ListTreeView(int listid, int level_width, int (*IsLeaf)(void *rowobject), int options);
This function will turn a normal list box into a tree viewer. In most
respects it is just an ordinary list, however special list facilites like
list columns and "hooked lists" are not supposed to work.
Your tree implementation may be whatever you like, you can use either an
iterator function for arrays (using `SetIndexedList' to install it) or for
linked lists (using `SetLinkedList' to install it). The return value (if not
NULL) will always turn up later as the first parameter of your iterator
function as the root data of that level in the tree.
Note however, if you use the array style iterator, then it should be
prepared to be called with any size of the 'index' parameter and return
NULL in case the index is too big (the list box will use that to draw some
conclusions about the number of nodes at that level).
Notable is also that the 4:th parameter, 'n', passed to `AddList' (i.e. the
"number of list items") has no meaning for a tree viewer, so it will be fine
if you just pass NULL to AddList.
The tree view section of the list box is a part of the rows in the list
so if you want to let the user expand and collaps nodes in the tree
you need to at least pass LEFT_MOUSE for the 'mousebuttons' parameter
to AddList.
The list box itself will manage the expanding and collapsing of tree nodes.
Your call-back function handling row click will only be called when the row
is clicked, not when the node is expanded or collapsed.
Parameters:
- listid: the id returned from `AddList'.
- level_width: the width each tree level will occupy on the screen.
Suitable value is 10 pixels or above (you should consider the
the width of your icons when choosing a value)
- IsLeaf: a pointer to a callback function that must return non-zero if
'rowobject' is a leaf and 0 if 'rowobject' is an internal node that
shall be possible to expand and collapse.
'rowobject' is the data returned by your 'ApplicationDataAtIndex' or
'IterateLinkedListOfApplication' (installed by SetIndexedList or
SetLinkedList).
- options: at present there is only one option:
- TR_HIDE_ROOT: This flag will cause the outermost tree root not to
be displayed (i.e. the leftmost view is a list of sons of the
tree root).
The return value is 1 if a listid is a valid id of a list, else 0.
See also:
AddList,
ListTreeSetNodesExpandedState.
This function will set the expanded or collapsed state of all nodes
that are not leafs in the tree. To see the change you need to also call
`Refresh'. Normally the expanded/collapsed state is changed by the user.
This function can however be useful in case you want to pre-set some
initial state of the nodes.
Parameters:
- listid: the id returned from `AddList'.
- IsExpanded: a function written by you. This function will be called
by `ListTreeSetNodesExpandedState' once for each node in the tree.
Parameters to IsExpanded:
- data: a pointer to the data object of the node (i.e. the same as
passed to IsLeaf)
If `IsExpanded' returns non-zero the node will be set to expanded
else collapsed.
The return value is 1 if `listid' is valid id of a list, else 0.
See also:
ListTreeView,
AddList,
ListTreeSetNodeExpandedState.
This function will set the expanded or collapsed state of the specific node
that holds the application data `data'. Normally the expanded/collapsed
state is changed by the user. This function will however override the users
choice.
Parameters:
- listid: the id returned from `AddList'.
- new_expanded_state: the expanded state (0=collapsed, 1=expanded)
- data: a pointer to the data object of the node.
The return value is 1 if `listid' is valid id of a list and a node pointing to `data' was found, else 0.
See also:
ListTreeView,
AddList,
ListTreeSetNodesExpandedState.
This function will install the call-back `CallBack' that will be called with
`data' whenever the user clicks below the last current list item (i.e. on an
empty row).
Parameters:
- listid: the id returned from `AddList'.
- CallBack: a pointer to a callback function that will handle the event
of a click on an "empty row".
Parameters to CallBack:
- id: the id of the window object representing the empty row that the
user clicked on.
- data: a pointer the data that you passed to `InstallBelowListEndCallBack'.
- data: a pointer to some data of yours that will be passed to `CallBack' when called.
The return value is 1 if a listid is a valid id of a list, else 0.
See also:
AddList.
This function alters the tool tips viewing mode of a list box.
Tool tips for the list box rows can be useful in listboxes with possibly
long text or if there are several resizeable columns so the text on rows
may be hidden. The text of the tool tips will be the text of all columns
concatenated with double spaces between the columns or just the single text
of the row if there are no columns.
Parameters:
- listid: the id returned from `AddList'.
- mode: If `mode' is 1 this function will configure the listbox `listid'
so that there will be tooltips showed whenever the mouse is over a row.
If `mode' is 0 the above behavior will be turned off.
- options: Pass 0, there is currently no option.
The return value is 1 if a listid is a valid id of a list, else 0.
This function may be useful in case you want to use a list-box to show the
rows like in a bar diagram.
Parameters:
- color: The color of the bar (the first part of the row's background).
- percentage: The lenght of the bar as a fraction of a full rows width
(where 1.0 is a full row).
This function has only affect when called from a list-box row drawing
function, and it will only affect the currently drawn row. If the list-box
uses columns, the function only have effect when the call-back is called
for the first column.
Returns the column that a certain listbox column was clicked on last time,
or -1 in case the information can not be obtained.
Parameters:
- rowid: The id key of the row to get the information about. You get the
id as a parameter to the "row select call-back" function ("Action"
parameter to AddList). Note that this call-back function may also be
called because of the users key-presses, not only because of mouse
clicks. In such cases the column is not well defined.
See also:
CguiListBoxSetColumnSelection,
SetListColumns.
Sets or resets the property "column selection" of a list-box. "Column
selection property" This means that when the user clicks on a row then
only the clicked column will be highlighted. This may be useful in
combination with CguiListBoxRowGetClickedColumn. If state is 0 it is
turned off, else on. By default it is turned off.
See also:
CguiListBoxRowGetClickedColumn,
SetListColumns.
int SetListColumns(int listid,
int (*RowTextCreater)(void *rowdata, char *s, int colnr),
int *widths, int n, int options, char **labels,
void (*CallBack)(void *data, int id, int i),
void *data);
This function partitions the list into `n' columns. Note that this
`RowTextCreater' will replace the one previously passed in the call to
AddList, so you may as well just pass NULL when adding the list to the
window. Texts longer than specified column will be clipped.
Parameters:
- listid: the id-key of the list to be partitioned into columns
- RowTextCreater: Pointer to a callback-function written by you. This
function will be called once per column, and is supposed to produce
the text that are wanted for that column on that row.
RowTextCreater works analogus as the `RowTextCreater' that may be
specified in the call to AddList, but it will also get the column
number. The return value is only inspected for column 0 (see AddList
for details).
Parameters to RowTextCreater:
- rowdata: the data created by you `index' or `linked list'
function specified by IndexCreator.
- s: Pointer to an array where `RowTextCreater' shall put the
text-string.
- colnr: The column number to which the text shall be created
the first column is 0
- widths: An array of column widths. The pointer must point to `n'
integer values that must be in persistent memory (i.e. static or
dynamic).
- n: number of columns
- options: The following options are currently available (pass 0 if you
don't need any option):
- LIST_COLUMNS_ADJUSTABLE: Lets the user change the width of the
columns using the mouse. The values pointed to by `widths' will be
properly updated. The listbox will adapt its width to be at least
the width of all the column.
- LIST_COLUMNS_ADJUSTABLE_KEEP_BOX_WIDTH: Like the above option, but
will not allow the total width of the columns to be more than the
width of list box.
- LIST_COLUMNS_DELIMITER: Tells that there will be drawn vertical
lines as delimiters between the columns (or rather at the right end
of each column).
- labels: an optional array of pointers to strings of labels. Pass
NULL if you don't need them. NOTE! In contradiction to the
convention in CGUI, in this case both the array and the strings
needs to be in persistent memory.
- CallBack: An optional pointer to a function written by you (if you
don't need it you can just pass NULL). This function will be called
when the user clicks on the label-button of a certain column. You
may use this e.g. to let the user sort the objects in the list.
Parameters to `CallBack':
- data: the pointer `data' passed to SetListColumns
- id: the id number of the column label itself. This may be used
e.g. to obtain the mouse-button used.
- colnr: the index of the column (the leftmost is 0).
- data: a pointer to any data (this will be passed to `CallBack' when
it is called)
See also:
AddList.
If you only need to update one row of a list, and know the index of your
data, a call to "RefreshListRow" will do that for you.
UpdateListRow will not update the scroll-buttons or the browse-bar.
Returns 0 if id is not a list reference otherwise 1
Parameters:
- id: a reference to a list, if id doesn't refer to a list, the
request will be ignored
- i: index to the data that shall be updated. If "i" is currently not
in the visible part of the list-box or if it is out of range, then
the request will be ignored.
See also:
Refresh.
The data with the index 'i' will be selected (highlighted) and viewed as
the first (top) row of the list-box.
If 'i' is out of range then either index 0 or the highest possible index
will be chosen instead.
If the list exists returns 1 else returns 0.
If `id' refers to list within a chain of lists, the browsing will
affect all the lists in chain where "listid" exists.
See also:
AddList,
RefreshListRow,
BrowseTo,
BrowseToL,
Refresh.
The data with the index 'i' will be selected (highlighted) and viewed as
the last (bottom) row of the list-box (or as the last row of the list if
the list contains less data items than there are rows in the list).
If 'i' is out of range then either index 0 or the highest possible index
will be chosen instead.
If the list exists returns 1 else returns 0.
If `id' refers to list within a chain of lists, the browsing will
affect all the lists in chain where "listid" exists.
See also:
AddList,
RefreshListRow,
BrowseTo,
BrowseToF,
Refresh.
int BrowseTo(int id, int i, int uncond);
The data with the index 'i' will be selected (highlighted) and the
list will, if necessary, be browsed to make i come in view.
If 'i' was "above the top" of the list-box prior to the call then
it will be the top row after.
If 'i' was "below the bottom" of the list-box prior to the call
then it will be the bottom row after.
If 'i' is already viewed in the list-box, then it will just be focused.
In this case you maybe want the entire list-box to be unconditionally
re-drawn (e.g. to make sure that some of your re-sorting or other updates
are correctly reflected), then set 'uncond' to true.
If the list exists returns 1 else returns 0.
This function may be used not only for browsing, but also for
re-selecting or pre-selecting a specific row in a list that you want to
set focus on. If 'id' refers to list within a chain of lists, the
browsing will affect all the lists in chain where "listid" exists.
See also:
AddList,
BrowseToL,
BrowseToF,
RefreshListRow,
Refresh.
int SetListGrippable(int listid,
int (*Grip)(void *srcobj, int reason, void *srclist, int i),
int flags, int buttons);
Defines the list-rows in a list to be Grippable.
Parameters:
- listid: a reference to a list
- button: specifies which mouse button(s) that are allowed for
gripping
- flags: see: SetObjectGrippable.
- Grip: a call-back function that will be called in the following
cases:
Grip will always be called when the mouse cursor goes over the row,
the "reason" will then be DD_OVER_GRIP. Grip must at this call
determine if it accepts to be gripped, and in that case return
1 otherwise 0. If returned 1 the object may later be gripped
(without notification) and possibly later on also be dropped.
If the "row was gripped" and later on dropped successfully on some
other object (must not necessarily be a list-row), then Grip will
be called a second time and the "reason" will now be DD_SUCCESS.
The return value of Grip will be ignored this time. The recipient
(the object on which was dropped) has already been called when Grip
is called.
The parameter "srcobj" is the object pointer of the gripped row,
i.e. the pointer created by the `ApplicationDataAtIndex' of the
list of the gripped row.
The parameter "srclist" to the call-back function will be the same
address as "list" (the pointer previously passed to the
AddList-function), "i" will be the index of the gripped object in
the "list"-data.
See also:
SetListDroppable,
SetObjectGrippable,
AddList.
int SetListDroppable(int listid,
int (*Drop)(void *destobj, int reason, void *srcobj, void *destlist,
int i, int flags),
int flags);
Defines the list-rows in a list-box to be drop-able.
The "button" parameter specifies if left or right button is allowed for
dropping.
The parameter "flags" see: SetObjectGrippable.
The specified call-back function "Drop" will be called in the following
cases:
Drop will always be called when the mouse cursor goes over the row with
a gripped object, the "reason" will then be DD_OVER_DROP. Drop must at
this call determine if it accepts to be dropped on, and in that case
return 1 otherwise 0. If returned 0 there will be no more call until next
time the mouse goes over the edge of the object.
If the object from the latest grip has been successfully dropped, Drop
will be called a second time and the "reason" will now be
DD_SUCCESS. The return value will be ignored this time. The gripped
object will be notified later on about the successful drop.
The parameter "destlist" passed to Drop will be the same address
as "list" (the pointer previously passed to the list-creation function),
"i" will be the index in the list and reason will be either of DD_SUCCESS
or DD_OVER_DROP.
The parameter "srcobj" is the source (the gripped) object, just
transferred from a Grip-function. This must not necessarily be an object
in another list.
The parameter "flags" passed to Drop is the "and"-ed result of the flags
for the gripped and dropped object. This has already been examined and
will always be non-0, i.e. the drag-drop operation is legal according to
your specification. The flag-variable is only passed as an extra info.
The parameter "destobj" is the object pointer of the dropped row, i.e.
the pointer created by the `ApplicationDataAtIndex' of the list dropped on.
See also:
SetObjectDroppable,
SetListGrippable.
int SetListDoubleClick(int listid,
void (*CallBack)(int id, void *data, int button),
int button);
Sets a list to be double-clickable by installing yet one call back.
This `CallBack' is analogous to the `Action' that you passed to `AddList'
for single click call backs.
See also `SetObjectDouble' for details.
Returns 1 if listid refers to a list, otherwise 0.
Parameters:
- listid: a reference to a list.
- CallBack: a function written by you, it will be called when a row in
the list `listid' is double clicked by the user. Parameters to
`CallBack':
- id: the id of the row object.
- data: the data object of the row item (same as passed to `Action'.
- button: the button that was double clicked.
- button: the mouse button that shall react on double click (i.e.
LEFT_MOUSE or RIGHT_MOUSE or both).
See also:
SetObjectDouble,
AddList.
int HookList(int listid, void *listdata, int *n, int width, int events,
int (*RowTextCreater)(void *data, char *s),
void (*Action)(int,void*));
Lists may be chained together. This means that they are controlled by one
common browse-bar and common scroll-buttons. This is useful when
displaying lists containing records with different items and the
different items need to be individually selectable.
This function hooks a new list to the right of another list. The first
list must be created with a call to AddList.
The creation of list is not finished until a call to either
`IterateLinkedListOfApplication' or `ApplicationDataAtIndex' is done,
see AddList for info about these functions.
Returns the id of the new listbox if listid is valid otherwise 0.
Parameters:
- listid: a reference to a list. If there already exists more than one
list in a chain (i.e. this is second or more call to HookList) then
any of these listid's may be used as reference - the new one will
always be put to the right of the previously rightmost one.
- listdata, width, events, RowTextCreater, Action, label: see AddList
for info about these parameters.
See also:
AddList.
Associates DELETE-key presses to the list "listid". The list will only
recognise the key-press if is active (in focus).
Returns 1 if listid refers to a list, otherwise 0.
Parameters:
- listid: a reference to a list (the return value from AddList shall
be used)
- CallBack: a pointer to a function that must be written by you.
This function will be called when the user wants to delete objects
from the list by pressing the Delete-key while the row is in focus.
The parameter "obj" is the address to the
object to delete (the address calculated by the function
"IterateLinkedListOfApplication/ApplicationDataAtIndex"). If there
were multiple rows marked "CallBack" will be called once for each
marked row. However 'CallBack' can alternatively call 'GetMarkedRows' to
get them all.
The parameter 'id' is a reference to the row object.
See also:
AddList,
GetMarkedRows.
Associates INSERT-key presses to the list "listid". The list will only
recognise the key-press if is active (in focus).
Returns 1 if listid refers to a list, otherwise 0.
Parameters:
- listid: a reference to a list (the return value from AddList shall
be used)
- CallBack: a pointer to a function that must be written by you.
This function will be called when the user wants to insert a new
object into the list. The parameter "list" is the "list"-data item
specified when the list was created. "index" is the focused index
in "list" that currently in focus.
See also:
AddList.
This function returns a pointer to an array of list-object pointer, those
that for the moment are marked (blue).
This may typically be of interest in e.g. a callback installed by
`SetDeleteHandler'. If the user has made a multi-row selection and
wants to have them all removed it may be nicer to give a message like
"Remove all this 17 ...?" rather than 17 requests like
"Remove this..." .
If it fails or if there are no selected items the return value will be
NULL and the value pointed to by `n' will be set to 0.
The returned pointer points to dynamic allocated memory, which the caller
has the responsibility to free when no longer used.
See also:
AddList,
SetDeleteHandler.
This function returns the index of a certain row in a list. 'id' must
refer to an row-object of a list-box (and will be passed to the callback-
function of the list-box).
If id do not refer to a list-row it will fail and return -1
See also:
AddList.
int NotifyFocusMove(int listid,
void (*CallBack)(int id, void *rowobject));
This functions makes an initialisation so that your program will be
notified by a call to `CallBack' when a row in a list gets focus.
Return value: 1 if successful else 0 (no good listid)
Parameters:
- listid: must be a leagal id to a list
- CallBack: the pointer to a function written by you. This function
will be called each time a row gets focus (e.g. because the user
moves the "row-cursor" by use of arrows). Parameters in that call:
id is the id of the row-object. This may be used to e.g. get the
row-index by calling GetRowIndex; parameter 'rowobject' is the
pointer created by your list-index-function.
See also:
AddList.
A tab-window is a node within a regular window.
It consists of the tab-bar (a row of tab-selectors) at the top, and the
rest of the node which will display different sets of object depending on
which tab that is currently selected.
The tab-bar is limited to one row of tabs (or "selectors"). These
actually works similar to radio-buttons, but looks like "tabs". There
must be at least one tab. Each tab has a text-label.
When the user clicks on a tab, your call-back function associated with
that tab will be invoked (see AddTab). The point is that the call-back
function shall create all the objects corresponding to the tab. The
regular functions for creating objects may be used, which implies the
possibility of nested tab-windows.
If there is not space enough for all the tabs the excess ones will be
clipped, which is not as bad as it seems. However: The main point with
tabs-windows is to make quick access to the different controls, and this
is not not fulfilled anyway if you add too many tabs.
See also:
Windows,
Objects,
Menus,
Containers,
Listboxes.
Creates the node object of the entire tab-selector. Returns object-id.
Return value is the identification key for the entire tab-window
(including the tab bar at the top).
Parameters:
- x1, y1: position for the tab-window
- width, height: the size of the tab-window (may also be ADAPTIVE).
status - should point to a variable that contains the index of the
currently selected tab starting with 0 for the leftmost one. May be
used by your program to restart anther time with the same selection
as when closing.
See also:
AddTab.
int AddTab(int id, void (*callback)(void *data, int id), void *data,
const char *label);
Adds one tab into the bar of tabs in a tab-window. The callback, which is
a function you must code, will be called when the tab is clicked by the
user or initially by DisplayWindow(). The callback is not supposed to
open a new window. The only thing it shall bother about is to create the
objects for the tab-subwindow. This has always been cleaned before
callback is invoked (i.e the objects created by a previous selection has
been removed before call). The callback shall not refresh the objects in
the tab-window, this will also be done automatically after return.
All objects created by the callback will be but in the tab-window.
If absolute co-ordinates are used for such objects (x,y) these shall
refer to the upper left corner of the free area in the tab-window.
Like other objects tabs may be added also after the window has been built
with a call to DisplayWin. The same applies to removal of tabs.
Parameters:
- id: The id-code previously returned by CreateTabWindow
- label: This is the label that will be displayed on the tab.
- data: A pointer to any data that you want to be passed to your
callback each time it is called.
- callback: A pointer to a function that you have written. It will
be called by CGUI when needed. That is when the user clicks on the
tab or when CGUI wants to draw the content of the tab for some other
rason. Your function shall create the objects that you want to appear
in this tab window when this tab is clicked. This function is called
in a context that makes it impossible to destroy the dialog of the
tab window.
Parameters to callback:
data: The pointer `data' passed to AddTab
id: The id to the tab itself (not the container with the objects).
This can be used e.g. to remove the tab or to check which of the mouse
button that was used. When a tab is removed the next tab will be
selected. If there is no next tab the previous tab will be selected.
The behaviour when removing the last tab is undefined.
See also:
DisplayWin,
CreateTabWindow.
void HookLeaveTab(void (*callback)(void *data), void *data);
This function registers 'callback' to be a function that will be called
with 'data' when a tab in a tab-window is left. The tab will be left
either because the user selects some other tab in the same tab-window or
because the entire window is closed.
HookLeaveTab must be called when generating the tab-window (i.e. by the
function installed by 'AddTab'), only at this stage the tab-window is
prepared to receive such a call.
The purpose is to give your program the possibility to release memory
that you needed to allocate for the objects in the tab-window.
See also:
AddTab.
A "hot-key" means that a key pressed by the user invokes a function call.
Creating hot-keys may be done in following four ways:
- By marking a single character (by preceding it with the
tilde '~' character) in the label text of a visible object. This
character will then be the hot-key for clicking that object.
- Implicitly when the system automatically generates a hot-key for an
newly created labelled object (DisplayWin does this). These hot-keys
will always be selected from, so far, unused keys.
- Explicitly assigning a hot-key to an object (or extending the object
with yet one). This will be done by use of the "#scan,ascii;"
command in the label string.
- Explicitly creating a "hot key" for any purpose (not associated with
any visible object) by call to SetHotKey.
Hot-keys associated with an existing object will be automatically removed
when the object is removed (which normally will be done when closing the
window).
Hot-keys created with SetHotKey will be removed when the node which it is
associated with, are removed. Such hot-keys may also be removed
selectively by just calling Remove and pass the id received from
`SetHotKey'.
When assigning hot-keys explicitly there is no check if the key is
already used. If the same hot-key is assigned to multiple objects, it is
not defined which one will be selected when the user presses the key.
You may use the function IsHotKey to avoid ambiguous
hot-keys.
The scope of hot-keys is normally a window. An exception from this are
menus which have their own scope...or to be correct: this is no exception
since menus are implemented as windows... Tab windows are not independent
windows, and the objects in "hidden tab-windows" does not exist, so there
will be no conflict if same keys are used in different
tab-windows.
A special hot-key feature is the tab-chain. Any number of objects may be
linked together in the tab-chain. There is one tab-chain in each window
(possibly empty). Selectable objects (i.e. such objects that are used
for user input) will automatically join the tab-chain when they are
created.
The tab and back-tab keys are reserved for the tab-chain. One of the
objects within the chain are pre-set to be in
"tab-focus" when the window is created (by default this will be set to
the first one in the chain). When the user presses the tab or back-tab
key the "tab-focus" will move to the next or previous object in the
chain.
The "tab-focus" means that the object is highlighted, and that it will
catch subsequent ENTER and/or CRTL-ENTER key presses. The ENTER-key
matches left mouse-button and CTRL-ENTER right mouse-button, so the later
requires the object to be pre-set to receive right mouse clicks.
The chain is circular. An object in the tab-chain that is currently
deactivated will not get the tab-focus, it will be by-passed if reached
by a tab key-press.
The order in which the object joins the tab-chain controls their position
in the chain. By default the joining is their creation order.
Containers may also join the tab-chain (optionally). The effect is that
the container itself will take one position in the chain. While the
container is in "tab-focus" any object within it may be in "sub-focus",
which in this case is the real focus notified by the user and sensible for
enter/ctrl-enter. The user can move the sub-focus only by using the
arrow-keys. This requires that the objects within the container are
grouped and positioned in a tabular manner (the sub-focus will go the
object next to left/right/below/above following the x/y-coordinate of
the current sub-focused object. This implies that it will not work
properly if there are containers nested within the one joining the
chain, only one level is possible.
If an object within the tab-chain is selected by use of the mouse (e.g.
if it is clicked), then the focus is moved to it.
There are functions to re-arrange the default order in the tab-chain,
to force the focus to some object and to achieve info about which object
that is currently in focus.
Possible modes: 0 (turn off) or 1 (turn on)
In default mode CGUI will automatically try to generate short-cuts
for text-labelled visual objects. With this function you can alter that
mode. You may need this e.g. when you use text chosen by the user for
labels and the number of labels can be quite large. In such case the
time to calculate which letters that are unique can be quite long, or
in worst case infinite.
When objects like buttons, check-boxes, list-boxes etc are created they
will automatically be linked into a `tab-chain' (strict sequential and
flat in the tree-formed window). The tab-chain defines
which objects that may be set in focus by the user (using the
tab/backtab keys) and it also defines the order between these objects.
The order of the automatic joining will be the order in which the objects
were created.
You can use `JoinTabChain' to add objects that do not join the chain
automatically (e.g. canvas-objects) or to customise the order between
them by re-joining.
Not only simple objects like buttons can join the tab chain, but also
containers (e.g. radio-containers, list-boxes etc.). If the user tabs to
a container the selection of a certain object within the container can be
done by use of the arrow-keys. It is not meaningful to join a container
in which there are more containers (i.e. recursive constructs), since
there is no way for the user to control the focus movement within the
sub-sub-container.
`JoinTabChain' will first remove the object `id' from the chain if it is
already there, and then insert it after the currently focused object.
The focus is not changed.
Returns 1 on success and 0 if it fails. The parameter `id' shall be the
id-key of an object (returned by the creating function).
See also:
SetFocusOn.
When a window is created the first created object within the window that
joins the tab-chain will be in focus. The meaning of "beeing in focus" is
that it will be drawn highlighted in some manner and it is ready for
input. For simple objects like buttons, check-boxes etc. this means that
a subsequent enter key-press will have the same effect as a click. For
edit-boxes it means that it is ready to let the user type in text (the
text-cursor is blinking). For nodes like menu-bars, radio-containers,
list-boxes etc it means that the user may make a sub-selection of an
object with use of the arrow-keys.
This function explicitly sets the focus on the object `id'. It must be
a selectable object (i.e. it must be in the tab-chain).
You can call `SetFocusOn' immediately after you finnished the window
building process by a call to `DisplayWin', or later to e.g. highlight a
newly performed action by the user.
`SetFocusOn' updates the view of both the previus and new focus.
There are some different cases of the object `id':
- `id' is a simple object: The focus is moved to it (and the
previously focused will be unfocused).
- `id' is a node (container) that has joined the chain: The
the main focus is moved to the node (which normally has no special
view) and the simple object within the node that was last in
"sub-focus" will now be highlighed as `focused'.
- `id' is an object within a node (container), and the node itself
is the one that has joined the chain: The
`tab-focus' will be moved to the node and `id' will be highlighted.
- `id' is a window: The window will get the focus in case
there are no modal windows above it (highligted in the header).
Returns 1 on success and 0 if it fails.
The parameter `id' can be the id-key of any type of object (returned by
the creating function).
See also:
JoinTabChain,
BrowseTo.
Returns the id-key of the object that is currently in focus.
If `id' is 0 the id-key of the window currently beeing in focus will be
returned.
If `id' referes to a window then the focused object within the tab-chain
of that window will be returned.
If `id' referes to a container that has joined the tab-chain, the focused
(simple) object within that container will be returned.
See also:
SetFocusOn,
JoinTabChain.
int SetHotKey(int id, void (*CallBack)(void*), void *data, int scan,
int ascii);
Installs an application-specific handler which will be called with "data"
when the user presses the "hot-key".
This "hot-key" will be hooked to any container, and it will be removed when
the container is removed.
Parameters:
- id: the id-key to the container (or window, tab-window, list, container etc)
To get a hot-key that is global (and permanent) for all windows,
just enter 0.
- CallBack: a function written by you. It will be called when a
key-press matches scan, ascii that you specify.
- data: passed to CallBack
- scan, ascii: specifies the hotkey. The case of ascii letters are
is ignored when matching with the actual key press. The format
should be the same as for the value returned by Allegro's
function readkey().
See also:
IsHotKey.
Checks if the specified scan/ascii already has been used in the
operating window.
Returns 0 if not, otherwise 1
See also:
SetHotKey.
This function calls for the system's handler of hot-keys, which is
by default the receiver of keys (if no editbox is in focus), and does not
normally need to be called by the application program.
SimulateHotKeys will have the same effect as if the user pressed the
specified keys. This function may possibly be useful to call in
special cases in some other keyboard-handler (to bypass the let the
key-presses bypass the current keyboard- handler (and all other) and
go directly to the hot-key handler. Another way of doing this is to
call Allegro's `simulate_keypress'. This will however lead to a new
entry in the event queue.
Specifies which characters in the labeltexts that shall be used by the
system when the automatic generation of hot-keys is in progress. Default
is the english alphabet. If you wants national characters or special keys
like %-/ etc to be candidates for hotkeys then use this function. `hkset'
will replace the previous set.
See also:
Labels.
The event processing in CGUI will be started by a call to ProcessEvents
stopped by a call to StopProcessEvents. Typically ProcessEvents is called
at beginning of your program (after InitCgui and after making it possible
for the user to generate some events by e.g. creating a
window).
A typical external event is a mouse event. A mouse event may serve as an
explanation to what actions are taken when an event occures
- the user made something with the mouse (moved, pressed button etc)
- the processor recieved an interrupt
- Allegro captures this and calls CGUI's interrupt handler
- CGUI's interrupt handler will put this mouse event into the queue of
messages together with a reference to CGUI's mouse processor
- CGUI's event processor will later on find the message in the queue
and will launch the call-back found in the message, which in this
case happens to be CGUI's mouse processor
- CGUI's mouse processor will pass the message to the window in focus,
which in turn will pass it to its predecessors: the objects in it.
If the mouse-event matches the conditions for the actions of some
object it will perform the action of the object. Typically a click
on a button will lead to the action of invoking the call-back
function that you passed to the `MkButton'.
It works in a similar manner with hot-keys.
Sometimes you may want things to happen later on. For that purpose you
may explicitly generate an event with some delay (this may be used in
animation). The call GenEvent(foo, bar, 0); is equivalent to the call
foo(bar); at end of the function that calls GenEvent (provided that the
event queue is empty).
Start event processing. This function will not return until
StopProcessEvents has been called.
See also:
StopProcessEvents.
Stop event processing. You shall call this function in the call-back
function where you want CGUI to stop the event handling, e.g.
in the call-back for a button "Exit". In a typical gui-program you don't
need to call for StopProcessEvents, if you prefere you can call exit(),
instead.
See also:
ProcessEvents.
unsigned GenEvent(void (*Handler)(void*),
void *data, unsigned delay, int objid);
Generates an event, i.e. adds one messages to the event queue.
The effect of calling
GenEvent(my_function, mydata, 0, 0);
is
my_function(mydata);
if the event queue happens to be empty. The purpose is to serialize the
work to be done (i.e. let some processing be finished before invoking the
function in concern), or to ensure that some events that may be in the
queue will be processed prior to your function.
Another purpose is to achieve that the function will be called after a
certain amount of time.
Return value: An event id. Event ids are not the same as the ids of
window objects. There can never be two events with the same id, and
there can never be two window objects with the same id, but a window
object may occasionally have the same id as an event id.
Parameters:
- Handler: The call-back function (probably written by you) that you
want to be called.
- data: a pointer to some of your data that `Handler' needs to be
called with.
- delay: a delay time in milliseconds. The delayed queue is
implemented as a separate queue, so what is really done is that
when a timer expires, the messege will be moved from the delayed
queue into the end of the queue of current events. If some
processing is in progress and/or some messages was already there
in the message queue all these prosessing must be finished before
the delayed message will actualy start executing. Most of the time
the queue is empty. The accuracy of time measurment is one unit of
the time resolution provided by Allegro, but as best 1 ms (i.e. a
delay time specified as 5 ms on a DJGPP system will be delayed in
the range of 4 to 5 ms, depending on what delay it happens to be
until next tick). Just pass 0 if you don't want the message to be
delayed.
- objid: An optional (pass 0 if you don't need it) reference to an
window-object. In some cases you may get obscure bugs in your
application if your queued messages refers to data or window-objects
that don't exist any longer. You can avoid such dangling references
by killing the queued event message at proper time (i.e when the
data is about to be destroyed). Often you will find it easier to set
a link from the event to the object that it depends on. It will then
be destroyed, with the object.
Return value: an id that identifies the event, greater than zero, or 0
if it fails (that is: if the event queue has been stopped because of a call
to `StopProcessEvents').
See also:
ProcessEvents,
StopProcessEvents.
Removes specified event from the event queues. Returns the true if
the message was there.
Only events generated by your program can be killed. Events generated
bu CGUI itself are protected.
Returns 0 if the event was not found, else non-0.
Removes all events generated by previous calls to the function GenEvent
from the event queue. Events generated
bu CGUI itself are protected.
See also:
GenEvent.
Will iterate `Function' (using the event queue) until it returns 0. This
can be used e.g. if you want to run a game on top of CGUI, for example in
a window so that mouse and key events of CGUI are still processed.
See also:
GenEvent.
By default the event loop of CGUI will yield a timeslice to the system
between each two checks for new events. This is to avoid that you CGUI
program takes almost all available CPU power. This may slow down your
program in some context. If you want to turn off the yielding of
timeslices then call this function with 0, to turn it on again call it
with non-0.
void InstallKBHandler(int (*Handler)(void *data, int scan, int key),
void *data);
Installs a key-board handler. This handler will be called for each key
pressed by the user.
For "normal" programming of an application this is not needed. By default
the hot-key handler will be installed by InitCgui. When an edit-box
will be selected for input by the user it will install a keyboard
handler for the edit-box - this one overrides the hot-key handler.
I.e. all subsequent key-presses will go to the key-board handler of the
edit-box instead of the key-board handler of the hot-keys.
The call-back function "Handler" should return a non-zero value if the
key is accepted. A rejected key will be passed to next keyboard-handler
on the stack of keyboard handlers.
The pointer "data" will be transparently passed to the handler when
invoked, together with scan-code and ascii-code.
See also:
InitCgui.
Removes the a keyboard-handler previously installed by InstallKBHandler.
Also handlers not on top of the stack may be removed.
Return 0 if the specified handler is not present.
See also:
InstallKBHandler.
int Invite(int mask, void *data, char *text);
Meetings is a mechanism that makes a kind of "hand-shaking" possible. It
will make it possible to simulate "process-like" objects, which may be
used in communication protocols.
About meetings: Any of your functions may invite to a meeting, which
means that its execution will be held (within "Invite"). The only way for
the function to continue is that an event occurs and the callback of that
event calls for "Attend" with a matching mask.
Until Attend has been called, other events will be properly processed.
Invitations are stack-based, which means:
If, while one invitation is open, another call-back "invites" to a
new meeting, then that later of the invitations has to be attended (by
anyone) before the event system will try to match any attendings to the
first of the invitations.
________
| 0x8 | last invite
--------
| 0x80 |
--------
| 0x2 | first invite
--------
In the figure above all "attendings" with mask 0x80 and 0x2 will fail
until the meeting with mask 0x8 has been finished.
Return value: always 1
Parameters:
- mask: the meeting is identified by this bitmask (mask from invite
and attend will be anded, and a non-zero is regarded as a match)
- text: an identification text (n.u.)
- data: a pointer to any data that may be updated or read by the
"attending" function.
Return value is 1 (it will always succeed).
See also:
Attend.
Will attend a meeting invited to by function `Invite' if parameter `mask'
matches the meeting.
Return value: Attend returns the pointer "data" passed by `Invite' if
successful meeting, otherwise NULL.
See also:
Invite.
Various functions that may be of interest.
char const*const*LoadTexts(const char *fn, const char *section);
Loads a section of text from a file. Intended to be used in conjunction
with the `mktext' tool to make executables language independent
in an simple way. See readme.txt for `mktext'. The "text module" doesn't
really do very much, but it does it the right way...
LoadTexts will search for the language specified in the current
environment (i.e. allegro.cfg if no other specified). It will first
search for the language in the CGUI-section, if not found it will look
in the global section, and if not found there (or if config is not
present) it will take english.
If the language determined this way is not found in the specified file
it will look for the english language, and if that is not found it will
take a random (first).
The language name specified in the text-source may be any text (in legal
identifier form), strings will just be compared. To make use of the error
handling you it is necessary to follow the convention used in allegros
cfg-file (i.e. "en" for english, "de" for german etc).
`LoadTexts' returns a pointer to an array of strings. That array must be
indexed with the macros that you specified in the source-file, and
available in the header-file (`*.ht'), generated by
`mktext'.
Calling `LoadTexts' requesting an already loaded section, will not
consume memory (the same pointer as the first time will be returned).
Calling `LoadTexts' requesting an already loaded section, but with a new
language found in the current environment, will re-load the text. All
previously returned pointers to sections within the same file will then
be corrupt, and must be re-loaded.
Parameters:
- fn: filename to load
- section: the name of the section
See also:
DestroyTexts,
PrintFloatingConversion,
RegisterConversionHandler.
Will release memory allocated for all texts loaded by LoadTexts. You
don't need to call it - it will be called automatically at program exit.
See also:
LoadTexts.
Registers `Handler' and `data' as the converter for conversion-code
`name'. `Handler' will be assicated with the text string `name' and
called with `data' and a string pointer when needed. Its only task is
to put some text into the string called with, possibly with use of the
pointer `data'. The `name' shall include the <> like: "<person>".
See also:
LoadTexts,
PrintFloatingConversion.
A text specified in the source text-file, processed by `mktext' may
contain conversion codes of an extended format. These codes look like
%<text> (where `text' may be any text) and may be embedded in the
source-string like the C-standard conversion codes. The difference is
that since the conversion is name-referenced multiple occurances of
conversion codes in the same string may be put permutated order in
different languages.
`PrintFloatingConversion' does not recognise the C standard conversion
codes.
If a no handler is associated with the "<xx>" in "%<xx>" (which
may be the case if you accidently misspell the text), the text
"<xx>" will be printed instead.
Example: Suppose that the row is in you source-text-file:
SIZE_ERROR_TEXT "%<name> has to many (%<nr_things>) things|OK"
Suppose the following fuctions beeing registered for "<name>"
and "<nr_things>":
void name_handler(void *data, char *s)
{
/* suppose data points to a string containing the desired name */
strcpy(s, data);
}
void thing_handler(void *data, char *s)
{
int *i = data;
/* suppose data points to an integer containing the desired value */
sprintf(s, "%d", *i);
}
The above functions will be called whith a pointer to proper location
into the destination string when needed while `PrintFloatingConversion'
is executing in the below statement:
char string[1000];
. . .
PrintFloatingConversion(string, txt[SIZE_ERROR_TEXT]);
Req(string);
This call to `PrintFloatingConversion' will result in the following
string printed by `Req' (imagine the name to be "John Smith" and
value to be 13):
John Smith has to many (13) things
See also:
LoadTexts,
RegisterConversionHandler.
This function works as sprintf, except that the print buffer is not an
input parameter, but instead a return value. The returned pointer is
allocated dymanically and the caller is responsible for freeing the
memory.
Use this function if you want to use other than the default icons for the
built in dialogues in CGUI. 'filename' must be a dat-file, and the
datafile objects (i.e. the icons) must be named exactely as in the
default icons which you can find in the resource directory.
This function converts one string to lowercase, except from the initial
letter of each word. A word is a sub-string that follows a space, a tab,
or a minus-sign '-'.
void CguiSetMouseInput(void (*MouseInput)(int *x, int *y, int *z, int *buttons), void (*ForcePos)(int x, int y), void (*SetRange)(int x, int y, int w, int h));
This function changes the default mouse input, which is the Allegro mouse
driver, to whatever source you like. This can be useful e.g. in an
embedded system where a mouse is not present, and you may want to provide
mouse control anyway, e.g. whith the help of a joystick.
If MouseInput is NULL the default input handlers will be re-installed.
Parameters:
- MouseInput: A pointer to a function that will be called whenever CGUI
needs to know the current state of the mouse. MouseInput will never
return a value outside of the range specified by SetRange.
Parameters to MouseInput:
- x, y: Pointers to locations that MouseInput will update with the
current position of the mouse.
- buttons: A pointer to a location that MouseInput will update with
the current state of the mouse buttons. Bit 0 is left mouse, 1 is
right and 2 is the mouse wheel.
- ForcePos: A pointer to a function that will be called whenever CGUI
need to force a new position of the mouse.
Parameters to ForcePos:
- x, y: The new position of the mouse.
- SetRange: A pointer to a function that will be called whenever CGUI
need to change the area within which the mouse can move.
Parameters to SetRange:
- x, y, w, h: The new area.
int AddClock(int x, int y, int options);
Creates a clock at desired position. The time is shown as HH:MM:SS or
HH:MM. Which one to use is checked in the config-file. If the value can
not be retrieved from the config file the default is HH:MM.
The user can start a dialogue (if not suppressed by flag, see below)
to adjust the clock settings (minute or second based showing and, in
case the platform supports it, modifying the time). User modifications
are always stored into the current config file.
The `options' parameter can be either of:
- CLOCK_NO_DIALOGUE - The dialogue will not be available for the user.
The config file to store and read from is the "current config", so if
you adds multiple clocks they will all get the same setting.
The return value is the id of the clock object.
void Sound(int freq, int duration);
This function is deprecated, use Allegro's functions.
void ScrMode(void (*CallBack)(void));
This function will make a dialogue that lets the user select new screen
settings of resolution and colour depth.
If the changed are done by the user all images that has been
pre-loaded by `CguiLoadImage', will be re-loaded to make it possible for CGUI
to display them properly.
After a selection the new settings will be stored into the
current configuration file. To make CGUI using these stored settings
automatically, you should pass 0 for the settings when calling InitCgui.
Parameter:
- CallBack: If this parameter is not NULL, the function 'CallBack'
will be called after the user has made changes. This may be useful
if you for example wants to store it in some other environment.
Use the Allegro-macros SCREEN_W and SCREEN_H or
bitmap_color_depth(screen) to determine the new settings.
See also:
CguiLoadImage,
InitCgui.
Saves a data file object into an existing datafile.
Parameters:
- path: Path pointing into an existing datafile. The path must follow
the allegro convention for specification of a data file object. i.e.
[optional absolute or relative path]filename.dat#[optional path
within the datafile]objectname
The possible "path within the datafile" must exist (sub-datafiles will
not be automatically added).
If an object with the specified name exists it will be replaced. If
there are several objects with this name (the datafiles themselves has
no restriction of multiple names) the first one will be replaced.
- data: a pointer to the data to be stored.
- type: the type of the object to be stored, e.g. DAT_BITMAP. See
grabber.txt in allegro/tools for more info about data files.
Return-value: 0 if error, 1 if ok.
int CreateNewDataFile(const char *path, const char *filename, int pack, const char *pwd);
Creates a new empty datafile.
Parameters:
- path: Path the the directory where to create the datafile.
- filename: Then name of the datafile.
- pack: A flag to indicate whether or not the datafile should be packed.
If non-zero it will be packed.
- pwd: A pointer to a string containing the password in case encryptation
is wanted, or the empty string if not.
Return-value: 0 if error, 1 if ok.
You can use this function if you wish to customize the colors in CGUI. The
function will only have effect if you call it after the initialization of
CGUI.
Parameters:
- color_name: You can use any of the following color names, meaning what
their names suggest:
- CGUI_COLOR_DESKTOP
- CGUI_COLOR_UNSELECTED_TAB
- CGUI_COLOR_SELECTED_TAB
- CGUI_COLOR_LIGHTENED_BORDER
- CGUI_COLOR_HEAVY_LIGHTENED_BORDER
- CGUI_COLOR_SHADOWED_BORDER
- CGUI_COLOR_HEAVY_SHADOWED_BORDER
- CGUI_COLOR_CONTAINER
- CGUI_COLOR_WIDGET_BACKGROUND
- CGUI_COLOR_LABEL
- CGUI_COLOR_LABEL_FOCUS
- CGUI_COLOR_LABEL_HIDDEN_FOCUS
- CGUI_COLOR_LABEL_INACTIVE_1
- CGUI_COLOR_LABEL_INACTIVE_2
- CGUI_COLOR_BUTTON_FRAME_FOCUS
- CGUI_COLOR_TEXT_CURSOR
- CGUI_COLOR_DRAGGED_TEXT
- CGUI_COLOR_LISTBOX_TEXT
- CGUI_COLOR_LISTBOX_BACKGROUND
- CGUI_COLOR_LISTBOX_FOCUS_TEXT
- CGUI_COLOR_LISTBOX_FOCUS_BACKGROUND
- CGUI_COLOR_LISTBOX_HIDDEN_FOCUS_BACKGROUND
- CGUI_COLOR_LISTBOX_HIDDEN_FOCUS_TEXT
- CGUI_COLOR_LISTBOX_ROW_DELIMITER
- CGUI_COLOR_LISTBOX_COLUMN_DELIMITER
- CGUI_COLOR_TOOL_TIP_BACKGROUND
- CGUI_COLOR_TOOL_TIP_FRAME
- CGUI_COLOR_TOOL_TIP_TEXT
- CGUI_COLOR_TEXTBOX_TEXT
- CGUI_COLOR_TEXTBOX_BACKGROUND
- CGUI_COLOR_CONTAINER_LABEL
- CGUI_COLOR_EDITBOX_BACKGROUND_MARK
- CGUI_COLOR_EDITBOX_TEXT_MARK
- CGUI_COLOR_EDITBOX_BACKGROUND_INACTIVE
- CGUI_COLOR_EDITBOX_TEXT_INACTIVE
- CGUI_COLOR_EDITBOX_BACKGROUND
- CGUI_COLOR_EDITBOX_TEXT
- CGUI_COLOR_STATUSFIELD_BACKGROUND
- CGUI_COLOR_STATUSFIELD_TEXT
- CGUI_COLOR_PROGRESSBAR
- CGUI_COLOR_PROGRESSBAR_BACKGROUND
- CGUI_COLOR_TITLE_FOCUS_BACKGROUND
- CGUI_COLOR_TITLE_FOCUS_TEXT
- CGUI_COLOR_TITLE_UNFOCUS_BACKGROUND
- CGUI_COLOR_TITLE_UNFOCUS_TEXT
- CGUI_COLOR_TREE_VIEW_BACKGROUND
- CGUI_COLOR_TREE_CONTROL_BACKGROUND
- CGUI_COLOR_TREE_CONTROL_OUTLINE
- CGUI_COLOR_CHECKBOX_MARK_BACKGROUND
- CGUI_COLOR_BROWSEBAR_BACKGROUND
- CGUI_COLOR_BROWSEBAR_HANDLE_BACKGROUND
- CGUI_COLOR_RESIZER_HANDLE
- r, g, b: The red, green and blue components of the new color
If you are using a palette mode (8 bit color depth) the result of the color
setting depends on Allegro's makecol() ability to find a suitable palette
index in the palette that you are using.
The default colors in CGUI are set up at init by loading the values from the
current config file (i.e. allegro.cfg). If the file is not present or does
not contain color specifications then internal default values will
be used. These are the same as those in the config file, meaning that you
do actually not need to include the allegro.cfg in your distribution
package.
The config file loading of start color values provides an
alternative way to define custom colors, that also let the user control it.
The names of the config variables are the same as the symbolic names to be
used for the `color_name'. The values in the file should be given as RGB
triples (comma separated, no space, decimal notation like e.g. 0,255,255 for
green).
Return-value: the previous value of the specified color name, or -1 if the
color name is out of range.
The CGUI lib contains a font that is used when various CGUI-objects are
created. You can make CGUI start using your favourite font instead. You just
need to call `SetCguiFont'. The current set font is assigned to objects when
they are created, so you can create object with different fonts in the
same view. Note however that mixing fonts with different heights will cause
most objects to get different heights, since most objcet types use the font
height in the height calculation.
CGUI will not make a copy of the font pointed to by `f', so your program is
responsible for managing the memory of the font.
To restore the original built-in font of the CGUI lib you can at any time
call 'SetCguiFont(NULL)';
The rows in list-boxes uses fonts in a different manner, and will not be
affecte by the call to `SetCguiFont', see details about that in the
`Listboxes' section.
See also:
Listboxes,
GetCguiFont.
Returns the default font for objects.
See also:
SetCguiFont.
When setting a new font using `SetCguiFont' CGUI will make a guess about
where the base line of the font is. This will usually succeed for fonts
conforming to the ususal shape of European letters. However, for odd
looking fonts, or for non-European fonts it may find a base line that
does not look good. In such a case you can set the base line explicitly
after setting the font with `SetCguiFont'.
The base line is the first empty pixel line below the letters (except
letters like p, q, g, etc. that breaks the base line). The base line is
used by CGUI when underlining the letter to be used for short cut selection
(used in labels of buttons, edit boxes etc. as an alternive to using mouse
click).
See also:
SetCguiFont.
A number of objects like buttons, edit-boxes, containers, etc. may have a
text label. This label may primarly contain the text to be shown on the
surface of the object in a manner that is useful (e.g. the edit-box will
put it to the left of the input field, but the container will put it at
top as a header).
The label must not necessarily be static or constant memory, the object
will make a copy of the text.
Labelled objects will adapt thier size to the size of the text.
The label may be extended with
additional information.
- A '~' (tilde) before a letter will make that one to a hot-key.
- A '_' will make a new line (currently only implemented for buttons
and icons). The '_' itself will not be displayed.
- A control character (ascii code < 32). The binary value will be used
as hot-key. This may be useful for attatching hot-keys like
or to the object.
- A '#' followed by a numeric value and terminating with ';'
like "#130;", which will assign the key with ascii-code 130 (0x82)
to the object.
- A '#' followed by two numeric values separated by a comma and
terminating with ';' like "#82,1;". The first one will be
interpreted as the scan-code, and the second the character code
recieved from Allegro (i.e. a control code for cases of interest).
E.g. "#82,1;" will assign the shift-insert key-press as hot-key for
the object.
- Some objects may also contain the "#name;" command. This means that
an image with the name `name' shall be used to display the object.
The image may be combined with a text. The image must have been
previously loaded by the CGUI-function `CguiLoadImage' or
RegisterImage. Objects that currently recognises images are
- Buttons
- Icons
- Check-boxes
- Radio-buttons
- Drop-down boxes (in the label as well as the dropped down items)
- Edit-boxes
- Tags
- Menu-items (except for radio or check menu items).
- List box rows
- List box columns
There can be up to 3 images specified this way, and they will be
interpreted in the following way.
- The first image will be for the normal state.
- The second image will be for the inactive state.
- The third image will be used both for the over and focus states.
In case only one or two images are present the other states will use
the image of the normal state.
Not all widget types will make use of images for all tree state
e.g. the Tag widget type will not.
As a consequence that also other kinds of commands are possible to
embed in the label string, and can start with a "#", you can not use
image names starting with a digit. A specification of an image
assigned a name starting with a digit will be parsed as a short-cut.
- The text string to `Req' has a special format with a leading
info-text followed by a sequence of at least one button-label,
all within the same string. The button-labels are indicated by a
leading '|'.
If you need to actually draw any of the above control-characters - just
type them twice in the string.
See also:
AddButton,
MkMenuItem,
AddIcon,
Req.
By default CGUI scans labels for certain characters that controls some
functionality (see above). This may be a problem e.g. if you use file names
to label some menu items, and the file names occasionally contain characters
like '~' this will be consumed and the subsequent character will be
interpreted as a hot-key.
Therefore you may want to turn off this behaviour. If `state' is zero the
scanning will stop (all characters will appear exactely as they are). If
`state' is non-zero it will be turned on again.
Return value: The previous state of label parsing.
int CguiLoadImage(const char *filename, const char *imagename, int type, int id);
This function loads an image with name `imagename' from file `filename'.
Why? - The image as well as its name will be registered in the CGUI
system which means:
- You may later refer to that image when creating
objects, i.e. you can use the `imagename' in the label string to
specify that it shall be the icon used for the widget. Any
widget type that has a label will support showing images this awy.
See the section Labels for details.
- When node `id' is destroyed the image will also be - you
don't need to worry about returning the memory.
- If you let the user change the colour depth by use of the dialogue
`ScrMode', the images will be converted to the new pixel format (if
that is possible).
An image associated with a node may be referred from
objects that are put into that node (at any depth). I.e. if `id' is a
window, any object put into that window can use that image, or if `id'
is a container, any object put into that container can use it. Also all
objects of a sub-window can use the images of a parent window.
If you want to make an image `global' (i.e. it will remain in
memory until CGUI is shut down), just pass 0 for `id'.
Loading images from 8-bit colour files to a screen mode of 8-bit colour
will only work properly if all pictures uses one common palette. Loading
8-bit colour files into high colour or true colour modes will work
properly only if transparent colour is not used. The same limitation
applies to the reverse (high -> 8).
In short: to avoid problems use 24-bits files, and at least
15 bit colour-depth on the screen.
Parameters:
- filename: The path/name of the file that contains the image to load.
The file-extension may either be any of the types recognised by
the Allegro function `load_bitmap' or a ".dat".
- imagename: A string that identifies the image. In subsequent
references to the image (e.g. when creating a button that shall
display the image) this name must be used.
In case the file is an Allegro-datafile (detected by the
extension ".dat") the imagename is ignored. The name must be be chosen
so that it does not conflict with other commands embedded in labels.
See the section Labels for details.
- In case of loading a single image from a DATA-file
the name ending the path will be used as image name (you have to
use that one as when referencing the image).
- Multiple images can be loaded with a single call, provided that
they are stored within a datafile at the same nesting level. If
`filename' is e.g. "my_icons.dat" then all images at the
top-level of "my_icons.dat" will be loaded, and the image
names to use is the names of the objects in the data file. If
`filename' is e.g. "my_data.dat#icons/the_dialog" and
"the_dialog" is a data-file object of type `DAT_FILE' then all
images in that data-file ("directory") will be loaded. The
meaning of "images" is in this case bitmaps, compiled sprites
and rle sprites.
- type: This parameter controls if CGUI shall draw a bitmap in
transparent mode (draw_sprite) or in solid mode (blit). In case the
image is loded from a datafile and the type of the object is
COMPILED_SPRITE or RLE_SPRITE the type parameter will be ignored.
Image type macros:
- IMAGE_BMP: bmp will be handled as a non transparent bitmap.
- IMAGE_TRANS_BMP: bmp will be handled as a transparent bitmap.
- id: The id-key from the node which to hook the image onto. This
means that when node `id' is destroyed (e.g. because a window is
be closed) also the image will be destroyed. Typically `id' is the
id-key of a window. If you want to keep an image during the lifetime
of the program, just pass 0 for id. If the passed `id' refers to a
simple object rather than a container or window, the image will be
hooked into the parent of `id' instead.
Return value: The id of the node where the image is stored if
sucessful othewise -1.
See also:
RegisterImage,
ScrMode,
GetRegisteredImage,
Labels.
int RegisterImage(void *data, const char *imagename, int type, int id);
Works analogous to `CguiLoadImage' but registers an image that is already
in memory. `RegisterImage' will not make a copy of `bmp' so it must not
be freed or reallocated as long as it is in use (i.e. as long as object
id is not destroyed).
In contrary to images loaded from file the registered ones
will not be automaticallay adjusted when CGUI dialogue for changeing
the screen settings are used.
The `type' parameter shall be either of the IMAGE_* values
meaning:
- IMAGE_BMP: bmp will be handled as a non transparent bitmap.
- IMAGE_TRANS_BMP: bmp will be handled as a transparent bitmap.
- IMAGE_RLE_SPRITE: a RLE_SPRITE will be created from bmp
- IMAGE_CMP_SPRITE: a COMPILED_SPRITE will be created from bmp
Call `RegisterImage' with NULL for `data' if you want to unregister a
previously registered image (the name is your handle). You can also
replace a previous registration by subsequent calls to `RegisterImage'
using the same name. This can be used to make simple animations on
objects (which includes plain image objects like those made by `AddTag'),
see also the examples.
Return value: 0 if it failed (i.e. unknown type, unknown id), else 1.
See also:
CguiLoadImage,
GetRegisteredImage.
Returns a pointer to an image with name `imagename' in node `id' that
has previously been registered by `RegisterImage' or `CguiLoadImage'. The
integer pointed to by `type' will be set to the type of the image, see
IMAGE_* macros. The type of the returned pointer corresponds to the
type value.
See also:
RegisterImage,
CguiLoadImage.
In CGUI there are two functions for browsing the file system. If you use
the functions in your program you must link with the libaldat.a library
located in the lib directory of you Allegro directory.
const char *FileSelect(const char *masks, const char *rpath, int flags,
const char *winheader, const char *buttonlabel);
Opens a file selector dialogue. Simple usage:
char *fn;
FILE *filep;
fn = FileSelect("*.txt", "", 0, "Select a file", "OK");
/* fn points to a full path string, the memory will be deallocated by
the file-browser - you must not do. */
filep = fopen(fn, "r");
...
This function may be useful if your program needs to let the user
specifiy a file to load, or maybe a filename
and path to store things in or just to specify a path where the
program shall put files or seach for files. The user will expect a
file-browser to behave slightly different in each of these 3 cases.
You can control its beaviour using the `flags' parameter.
The dialogue is modal (i.e. the parent window of the file selector is
locked for mouse input until the file-selector has been closed).
The user may browse within Allegro datafiles.
The user closes the dialogue either by use of a cancel-button
or a confirm-button. If cancel was pressed, the return value will be
a pointer to an empty string.
Reuturn value:
The return value is a pointer to a string containing the full path to
the seleceted file (or directory). If an object in a datafile was
selected it is separated from name of the datafile with the '#'
character. If the flag `FS_MULTIPLE_SELECTION' is set the user may
possibly have selected more than one file. If so, each file will be
enclosed in quotation marks, '"', and separated with semicolon,';' (e.g.
like "highscore.txt";"readme.txt") and `UnPackSelection' can be used
to extract single file names from the returned string.
The memory location of the string, is valid only directly after the
return and belongs to the file-selector, so if you need to use the path
later on you have to make a copy to save.
Parameters:
- masks: A string containing the patterns to search matching files for.
Multiple masks are allowed: separate with semicolon (e.g.
"*.txt;*.doc")
- rpath: Restriction path. The given path is used as an restriction
for the browsing. The user will be able to browse from the given point
(witch is always the starting point - the path stored in the datafile
will be ignored) and downwards, not above it in the directory tree.
In particular you can restrict the browsing to some Allegro datafile.
- flags: The `flags' variable control some of the properties of the
browser. Their names and meaning are as follows:
- FS_BROWSE_DAT: Will display Allegro's datafiles as directories
and lets the user browse them as if they actually where
directories.
- FS_DISABLE_EDIT_DAT: Set this flag if you allow the user to
browse datafiles but not want him/her to change them and also do not
allow them to be created.
- FS_WARN_EXISTING_FILE: Will warn the user if he/she specifies a
filename that is already existing. Typically used in store
operations.
- FS_FORBID_EXISTING_FILE: Never give up...
- FS_REQUIRE_EXISTING_FILE: Will only accept a name specification
that really exist. Typically used in load operations.
- FS_SELECT_DIR: When the user selects a directory, that name will
be put into the name-selection field. If the user instead tries to
select a file, that operation will be ignored.
Typically used when the user is supposed to specify a directory
name.
- FS_DISABLE_CREATE_DIR: Don't let the user create directories.
- FS_DISABLE_DELETING: Don't let the user delete files or
directories.
- FS_DISABLE_COPYING: Don't let the user copy files or directories.
- FS_SHOW_MENU: Shows a menu to the user. The menu contains:
- Check-box: Show the image of an image file or object.
- Check-box: Show the original file name of a data-file object.
- Check-box: Show the file or object time.
- Check-box: Show the file or object size.
- Check-box: Show the file attributes of disk files.
- Check-box: Show hidden and system disk files.
- Check-box: Show the file names case-formatted.
- Selection: Open a file manager.
- Selection: Open a subwindow showing the copy buffer.
- FS_NO_SETTINGS_IN_CONFIG: By default the browser retrievs the
previos user configuration from the current config-file (and
stores the new one when closing). Use this flag to suppresse this
behaviour. The data concerned are:
- The initial path (starting point) when opening.
- Flag telling if the image of an image file or object shall be
displayed.
- Flag telling if the original file name of a data-file object
shall be displayed.
- Flag telling if file time shall be displayed.
- Flag telling if file size shall be displayed.
- Flag telling if file attributes shall be displayed.
- Flag telling if hidden/system file shall be displayed.
- Flag telling if formatted case of file-names shall be
displayed.
- The width of each column in the file-list of the browser.
- The width of the file-list of the browser.
- The height of the file-list of the browser.
- The window position.
- A flag indication if the copy-buffer was opened last time.
- A flag indication if the copy-buffer is in add-mode or not.
- The sorting criterias.
The settings for the file-manager is separated from those of
the file-selector.
- FS_MULTIPLE_SELECTION: Let the user select more than one file.
- FS_NO_DRAG_DROP: Disables the feature of dragging files and
directories.
- FS_DIRECT_SELECT_BY_DOUBLE_CLICK: If this option is set and the user
double-click on a file it will have the same meaning as single
click + click on the OK button (i.e. the expected behaviour).
NOTE! this option will automatically set the option FS_NO_DRAG_DROP
since these two can not coexist.
- FS_SAVE_AS: Makes the file selector beahave slightly different
from the default. Currently the only difference is that a name
entered by the user (typed or selected) will not be rubbed from the
selection field when changing directory.
- FS_SHOW_DIR_TREE: Will show the directory tree in a separate view
to the left of the list with selectable files. If this flag is set
then there will be no directories displayed in the file list unless
you also set `FS_SHOW_DIRS_IN_FILE_VIEW'.
- FS_SHOW_DIRS_IN_FILE_VIEW: You only need to use this flag in case
you use a separate directory view (i.e. use the flag
`FS_SHOW_DIR_TREE'), because otherwise it will be the default
setting.
- FS_HIDE_LOCATION: By default there is a location field showing the
full path to the currently selected directory to the user. In case
you don't like this you can avoid it by setting this flag.
- FS_HIDE_UP_BUTTON: By default there is a button that let the user
change to the directory "above" the current. In case a directory
tree is shown this may seem redundant. If the ".." directory is
present in the file list it is also redundant. Use this flag to
skip the button.
- FS_HIDE_UP_DIRECTORY: By default the up-directory (i.e. "..") is
displayed in the file list (however not in case directories are
hidden because `FS_SHOW_DIR_TREE' is set). Use this flag to skip
that line.
- FS_FILE_FILTER_IS_READ_ONLY: The edit-box showing the masks will
be disabled for user input.
- winheader: A string that will be used as header of the browser
window. If you pass the empty string, a default text will be used.
- buttonlabel: A string that will be used as label of the confirm
button. If you pass the empty string, a default text will be used.
Note! The implementation of the browser is a list, and by default lists
get an event for SINGLE CLICK. In the browser the user can double-click
to select a certain file or directory directly (this is a common
behaviour of bowsers). However, what will happen if doubel-clicking on
e.g. a directory for opening it? If the drag-drop is active it will in
most cases be seen as a try to grip the object and therby it will be
inserted into the copy-buffer.
See also:
FileManager,
UnPackSelection.
This function may be used to unpack individual filenames (including path)
from the return string of `FileSelect'.
The return value points to the first file of *flist and is dynamic memory
and it is your responsibility to free it. *flist will be advanced to next
file and will point to the string end when no more files.
See also:
FileSelect.
Creates a dialogue that lets the user inspect and maintain the
file system.
- Files and directories may be deleted and copied in the file list,
either by use of hot-keys, menu-selection or drag-and-drop.
- Directories may be created in the file list.
- The contents of the file list to display may be configured by the user.
- The size of many window objects may be configured by the user.
- There are special copy features, allowing the user to walk around
and marking files in the file list for copying and also the possibility
to display the current set of files marked for copying.
- I is possible for the user to start new file-managers that can
used for e.g. drag-and-drop.
- The possibility of multiple file-masks.
- The user may edit the name and attributes of files and directories.
- Modifications of the various window settings and feature modes made
by the user will be stored in the current config file, and are
retrieved next time a file-manager is opened. Specially the current
directory will be stored.
Parameters:
- winheader: A string used as header of the browser window.
- flags: The flags variable control some of the properties of the
browser. Thier names and meaning is as follows:
- FM_BROWSE_DAT: Will display Allegro's datafiles as directories
and lets the user browse them as if they actually where
directories.
- FM_DISABLE_EDIT_DAT: Set this flag if you allow the user to
browse datafiles but not want him/her to change them.
- FM_DISABLE_CREATE_DIR: Don't let the user create directories.
- FM_DISABLE_DELETING: Don't let the user delete files or
directories.
- FM_DISABLE_COPYING: Don't let the user copy files or directories.
- FM_DO_NOT_SHOW_MENU: By default a menu is created (See
FileBrowse about the contents). This flag suppresses the default.
- FM_NO_SETTINGS_IN_CONFIG: By default the browser retrievs the
previos user configuration from the current config-file (and
stores the new one when closing). Use this flag to suppresses this
behaviour. The data concerned are:
- The path to use when opening.
- Flag telling if the image of an image file or object shall be
displayed.
- Flag telling if the original file name of a data-file object
shall be displayed.
- Flag telling if file time shall be displayed.
- Flag telling if file size shall be displayed.
- Flag telling if file attributes shall be displayed.
- Flag telling if hidden/system file shall be displayed.
- Flag telling if formatted case of file-names shall be
displayed.
- The width of each column in the file-list of the browser.
- The width of the file-list of the browser.
- The height of the file-list of the browser.
- The window position.
- A flag indication if the copy-buffer was opened last time.
- A flag indication if the copy-buffer is in add-mode or not.
- The status field width.
- The sorting criterias.
The settings for the file-manager is separated from those of
the file-selector.
- FM_SHOW_DIR_TREE: Will show the directory tree in a separate view
to the left of the file list. If this flag is set then there will be
no directories displayed in the file list unless you also set
`FM_SHOW_DIRS_IN_FILE_VIEW'.
- FM_SHOW_DIRS_IN_FILE_VIEW: You only need to use this flag in case
you use a separate directory view (i.e. use the flag
`FM_SHOW_DIR_TREE'), because otherwise it will be the default
setting.
- FM_HIDE_FILE_VEW: If this flag is used the file view will not be
displayed at all (which makes the flags concerning the file view
useless).
- FM_HIDE_UP_BUTTON: By default there is a button that let the user
change to the directory "above" the current. In case a directory
tree is shown this may seem redundant. If the ".." directory is
present in the file list it is also redundant. Use this flag to
skip the button.
- FM_HIDE_UP_DIRECTORY: By default the up-directory (i.e. "..") is
displayed in the file list (however not in case directories are
hidden because `FM_SHOW_DIR_TREE' is set). Use this flag to skip
that line.
- FM_NO_FLOATING: This will force the browsing window to be modal.
(by default it is a floating window).
See also:
FileSelect.
int RegisterFileType(const char *ext,
void (*Handler)(void *privatedata, char *path), void *privatedata,
const char *actionname, const char *icon, const char *typetext,
void (*Viewer)(void *privatedata, void *viewdata));
This function will register a file type so that the file-browser
will identify it and give it some special handling. There are three
things that can be done:
- Assign an icon to that file type (to be displayed in the browser).
- Assign a name to that file type (to be displayed in the inspect/edit
dialogue).
- Assign a call-back function to that file type. This will give the
user the opportunity to perform some action with such files
as input. Optionally you can pass a name for the action.
- Assign a pre-viewer for that file type.
If e.g. you only want to register an icon or name just pass NULL for the
data and call-back parameters.
The registration will be reflected both in the file-selector and the
file-manager concerning icon and info. The action registration will
however only have effect in the file-manager.
All registering is global, i.e. if the browser is used in different
contexts they will be present at all of them. You can disable a
registration by calling with all parameters set to NULL.
Parameters:
- ext: The file extension to register e.g. "txt" for "*.txt"
files.
Note: this is not the usual "file-mask". Only the substring following
a possible '.' in the filename must be passed and it must also be a
distinct string - no wildcards.
If you alternativly want to make a registration for a datfile object
type, just pass the name of the data-object type prefixed by a '#',
e.g. like "#RLE" for rle sprites.
- Handler: The name of a function to be called when the user selects a
file of this type (i.e. click with the right mouse button and selects
"action name"). The call-back will be executed without closing the
fila-manager dialogue.
`Handler' takes the following parameters:
- data: A pointer to any data (this will be the same value as
previously passed to `RegisterFileType').
- path: The path and filename that was selected.
- privatedata: A pointer to any data. It will be passed to `Handler'
and `Viewer' when called.
- actionname: An optional string that specifies the action for the
user, (e.g. "Edit" or "Execute"). The action-name will e.g. be
displayed in the drop-down menu where the action is executed. If
omitted the default text will be "Action".
- icon: An icon that the browser will show to the left of any file
of this type. If you want the icon to be displayed properly without
clipping: keep the size within 22x16. The icon must have been loaded
globally with the CGUI-function `CguiLoadImage' prior to the registration.
- typetext: A string that tells the user what type of file this is
(i.e. as an alternative to the icon, but may possibly be more
exhaustive).
- Viewer: A function that understands files of type `ext'. It will be
called when the file browser is about to view the content of a file.
This may be done in some different contexts depending on what the user
does (which can be restricted by your settings) and which options the
user has set (which availibility for modification can also be
restriced by your settings). E.g. in the inspect/edit dialogue of file
object and in the pre-view.
`Viewer' shall take two parameters. The first one is your `privatedata'
and the second is:
- if `ext' defines an file extension then viewdata is the fullpath
name to the a file of type `ext'.
- if `ext' defines a data-file type the viewdata is a pointer to
a datafile object.
`Viewer' is supposed to add some object that displays the content of
the file in a some way.
Pass an empty string for those parameters not used.
Pass NULL-pointers for call-backs you don't need.
Returns 0 if fail (ext is empty) else non-zero.
You should not use the Allegro functions/variables for mouse-manipulations
directly. CGUI will do some changes for certain events, that will override
such changes. Instead use the functions listed below. There are some pre-
defined cursors "installed" that you can selecet among (CGUI uses them
itself). You may also extend this list of installed cursors. In addition to
this you may create overlayed cursors, i.e. make a new cursor from the
currently selected and some other sprite.
A global variable that tells the mouse cursor to be drawn inside the
interrupt. The default is not. The reason why the mouse is drawn "polled"
(or rather via the event queue), is that the interrupt drawing will not
draw well if you use canvases. This is a weakness in CGUI, that may be
removed in later versions. The reason why uou want to let the cursor to
be drawn in the interrupt is that it otherwise will "freeze" if the
program is busy for a long time without returning the control to the
event queue processor (this is quite rare in most programs, e.g. disk
accesses for 1M will not be affect the mouse moving).
Installs a sprite to be a predefined cursor. This cursor may replace an
existing cursor, as well as extend the list of available. x,y is the
hotspot point relative to the upper left corner of the sprite.
InstallCursor will make a copy of the bitmap, so you are still
responsible for the memory after the call, and may feel free to destroy
it.
If your cursor replaces an existing one, the latter will be destroyed.
Selects a predefined cursor using the specified index.
Available cursor alternatives are:
- CURS_DEFAULT
- CURS_DRAGGABLE
- CURS_ILLEGAL
- CURS_BUSY
- CURS_DRAG_H
- CURS_DRAG_V
- CURS_CROSS
The mouse event processing will occasionally switch between the above
indexes. E.g. moving over a draggable object will set CURS_DRAGGABLE. If
you select another index this will inhibit this automatic cursor
switching.
Selecting another cursor than above requires that the cursor have been
installed first.
See also:
InstallCursor.
Returns the mouse pointer locataion related to the specified object.
See also:
OverlayPointer.
Returns a pointer to a bitmap showing the current view of the specified
object. The bitmap belongs to you, i.e. it's your responsibility to destroy
it when you don't need it any longer.
See also:
OverlayPointer.
Creates an overlayed mouse pointer. This means that a new pointer will
be created by merging the shapes of `sprite' and the current selected
pointer.
The current selected pointer will appear on top of `sprite'.
Overlayed mouse pointer may be useful e.g. during dragging operations
showing the dragged object as a cursor and letting the current selected
cursor still be left on top to point out the "hot spot".
The current selected cursor can later be restored as a single pointer
by `RemoveOverlayPointer'.
Subsequent calls to `OverlayPointer' let you overlay multiple cursors.
If `SelectCursor' is called while an overlayed pointer is in use
the requested change will be reflected in the overlayed pointer.
Parameters:
- sprite: a pointer to a sprite. This may be destroyed after the call
- x,y: specifies the offset from top-left corner of your sprite to
the hotspot.
See also:
InstallCursor,
RemoveOverlayPointer,
PointerLocation,
ObjectApearance.
UnInstalles a secondary cursor previously installed by OverlayPointer.
See also:
OverlayPointer.
Creates an overlayed cursor using the specified text and font
Restore a plain pointer by a call to `RemoveOverlayPointer'.