26. Programming with Geneva - Geneva.cnf, Help and other Docs

Index,   Changes to existing functions,   New Data types & Functions

  1. The GENEVA.CNF File
  2. Miscellaneous Programming Information
    Geneva documentation from Programming Read.me file
    Make Help file
    Geneva Read.me file
    Programming documentation from Geneva Read.me file


26.7. The GENEVA.CNF File

Geneva saves all of its settings in a file called GENEVA.CNF. This file can contain information stored by other programs, as well. It can be read by using the x_shel_get() function, and written to by using x_shel_put().

When writing to the file, the following conventions should be followed: The program name passed during the X_SHOPEN phase must not contain the characters [ or ]. It can contain any other characters, though, and the use of lowercase is encouraged.

  1. Comment lines can be included. These begin with the semi-colon character in the first position. Comments are ignored when using x_shel_get() to read the file.
  2. All data should be in readable text format. Each line should be no more than 80 characters, though nothing adverse will happen until more than 120 are used. A Carriage return/linefeed is automatically appended to each line.
  3. It is a good idea to make the first line of your program's configuration some sort of version number identifier. This way newer versions of the program can give the user a warning if an old information format is used.
  4. As little information as possible should be stored in GENEVA.CNF by a program. The use of outside configuration files is still encouraged.


beginning of section
top of page

26.8. Miscellaneous Programming Information

The shel_get() function always reads NEWDESK.INF or DESKTOP.INF from the directory Geneva was loaded from (or the root of the default drive, in the case of it being run from the AUTO folder). It does not use a static buffer in memory. shel_put() does nothing, since it is dependent on the old desktop anyway.

shel_envrn() uses the environment pointer passed when the application was executed. shel_find() (and, for that matter, rsrc_load()) use Geneva's internal idea of the PATH env. var. (which can be modified with shel_write()) or the value "," if there is no PATH. shel_read() always works, even for applications that were not run with shel_write().



beginning of section
top of page

Geneva Programming Docs from the Read.me file

The files here are intended for use primarily by people who are interested in programming.

GNVA_DB.PRG (in the PROGRAM folder on the Master disk) is a special version of GENEVA.PRG that includes debugging alerts which will appear when an application uses an AES function call incorrectly. It traps things like a bad parameter to wind_set(), a program attempting to close windows that do not belong to it, etc. These things are simply ignored by the normal version of Geneva. In some cases, Atari's AES will do unexpected things when you pass bad values, so GNVA_DB can be quite useful. To disable a particular alert, click on Ignore All. From that point on (until you reboot), all alerts of that specific type will be ingored.

SETMOUSE.C is the C source code for the SETMOUSE.PRG which appears in the GENEVA folder of ths disk.

NEW_GEM.LIB is a Pure C library containing all AES and VDI functions, as well as Geneva's extended AES functions. It can be directly substituted for the PCGEMLIB.LIB that comes with Pure C.

XWIND.H is an ANSI C include file which defines Geneva's extended functions.

XWINDGFA.LST is a GFA BASIC file with the contents of XWIND.H translated into BASIC.

NEW_AES.H is an ANSI C include file which defines several helpful extensions to AES functions, and attempts to bring Pure C's AES.H up to date with MultiTOS 5.0.

The MAKEHELP folder contains the MakeHelp utility for compiling context-sensitive help files. See MAKEHELP.HLP for more info.

The TASKMAN folder contains the entire C source and resource definition (HRD) for the Task Manager.

The SKELETON folder contains a C source file for creating new programs that use Geneva's functions. By changing the #defines, you can modify the program to work as a desk accessory and/or a program. You may find it helpful to remove most of the unused #ifs once you have decided how you want the code to be implemented.

The VECTEST folder contains source code for using Geneva's vectors. It demonstrates how to access the vectors and use them properly.




beginning of section
top of page

Geneva Makehelp Utility version 1.1

The instructions for creating source files to be compiled into HLP files are contained in the file MAKEHELP.HLP. To view this file, you need to use GNVAHELP.PRG.

Either run GNVAELP and use its File->Open menu entry to load MAKEHELP.HLP, or, if using NeoDesk, drag MAKEHELP.HLP to GNVAHELP.PRG.



Geneva HLP file

Geneva Makehelp Utility

This program allows you to create context-sensitive help files for use in your own programs. It works by reading a source text file which includes various directives to specify how the text should be split up into individual screens, and where references to other screens occur.

Source Format

The basic format for a help file source is a straight ASCII file containing one or more blocks:

\screen_type1 screen_name1
[\screen_type2 screen_name2]
...
[Help text]
\end \screen_type3
screen_name3
...

Any text appearing after an \end directive, but before the next screen directive, is ignored. This is a good way to add comments to the help file source.

Each screen definition can have one or more names associated with it. Which directive you use affects how the name (or "keyword") is treated by the help compiler, and the help viewer. The screen_name can contain up to 43 characters, including any character (spaces, too.) The actual text of a help screen can include up to 100 lines of 100 characters each.


Screen Types

When Makehelp encounters a keywords at the start of a line in the source file, it knows that a new screen of help text is being defined, or an additional keyword is being added to the current screen.

A can be up to 43 characters long, and can use any ASCII character (including spaces.)

\screen
\casesens
\hidden
\index

The following table summarizes the three main directives, whether or not the keywords they define would appear in the index, and if a search using the string "Abc" would match if the keyword defined by each was "aBc".

Directive In Index?Match Case OnMatch Case Off
\screenyes yesyes
\casesensyesnoyes
\hiddennonono

\screen
This directive defines a default screen. The name appearing after the directive will appear in the help file index, and can be found during a search in GNVAHELP regardless of whether the user provides upper or lowercase letters in the search specification.

\casesens
This defines aOase-sensitive name. The name will appear in the help file index, and can be found during a search only if the case exactly matches what the user types, or if he has turned the "Match upper/lowercase" option Off.

\hidden
The purpose of this directive is to provide a way for the programmer to reference a help screen whose name will not appear in the index and will not be considered during searches. The individual "A.." through "Z.." entries of a multiple screen help file index are examples of hidden screens.

\index
This directive is optional. It instructs Makehelp to use the screen following it as a replacement for the normal index. Only one \index can be specified per help file. Screens of this type can also be aliased with other names by follwing the \index line with one or more of the other types of screen directives. An index should contain all of the important screen n%es contained throughout the help file, so that the user can easily see the range of help topics.
Example:

\index Index
\screen Alternate Name
This is the body of the screen. Here is a reference to another screen: \#Another Screen\#
\end

Special Sequences
For the most part, any character can be entered. There are several special control sequences, though:

\\ Substitute a single backslash \ character.
\x Substitute the ASCII character with the hexadecimal value that follows.
One or two characters comprise the hex value. Examples:
This \x7f is the delta character.
\x3 This is the right arrow.

\# This encloses one or more words which denote the name of a screen appearing either somewhere else in the help text source, or in another help file. The name will appear underlined when viewed in the Help Text Viewer. Double-clicking on the name will jump to the appropriate help screen. If the name is not in the current help file, then the Help Viewer will search in the path set by the user with the Set Help File Path option in the Help Viewer. A preferred filename can be set for missing keywords with the \@extern function.
If the keyword is not found in the current help source, you will receive a warning message from Makehelp. This serves as a reminder to verify that the keyword was not mis-typed.

\@ Identifies a function.


Set Help File Path

This option allows you to select a path which contains other help files. These files are searched when a particular topic is not found in the current help file. Most likely, you will want to have this path point to the \GENEVA\HELP folder on the disk where Geneva is stored.


Named Links
Sometimes, it is preferable to link to another screen without having to use the destination's screen name as the text of the hypertext link. A named link looks like a regular link, except it includes the name of the destination screen in curly braces {}.

For example, to link to the screen named "Screen Name" using the text "click here" as the underlined hypertext, this would work:

To jump somewhere else \#{Screen Name} click here\#!!


Functions
Any word beginning with the sequence \@ is evaluated for function calls. Each call performs a specific purpose, doing something like drawing a particular type of graphic within the help screen.
Function calls are part of a screen; they must appear between one of the screen directives and an \end directive.

The placement of function calls is not important. All functions are evaluated by the Help Viewer after any text in the help screen is displayed. However, order is very important, since many function calls affect the output from other calls.

To make calculating coordinates of graphics objects easier, it is best to place all function calls at the end of a screen, after any normal text. Since each line holding a function call still counts against the 100 lines-per-screen limit, it is often helpful to put multiple function calls on the same line, like so:

\@line 1 1 5 5
\@line 2 2 6 6

is the same as:
\@line 1 1 5 5 \@line 2 2 6 6

Each function call accepts one or more parameters, and in some cases a certain number of parameters is required. Parameters should be separated by one or more spaces in the source file. Numeric parameters can be either in hexadecimal (preceded with $ or 0x), or decimal (preceded by nothing). These lines are all the same:

\@line 20 10 9 11
\@line $14 10 9 0xb
\@line 0x14 $a $9 $B

Many of the graphics functions simply set options that affect other drawing functions. Because there is no way to know what order the user might access help screens in, the options are all reset to their default values every time a new screen is encountered. In order to get the desired effect, it may be necessary to include the same function calls in each of your screens, to initialize the options before any actual drawing takes place.

A .HLP file which uses functions cannot be loaded by older versions of GNVAHELP. The version which accompanies release 004 of Geneva (or newer) must be used.


Character Coordinates
Many of the functions use character coordinates to describe the position and size of a graphic. The first line after any \screen, \casesens, \hidden, and \index directives is line 0. The upper-left corner of a screen is coordinate 0 0. Coordinate 5 0 is the width of 5 text characters to the right. For example:

\screen Example
* This asterisk is at coordinate 0 0.

And * this one is at 4 2.
\end

In order to draw most objects using character coordinates in a consistent way, a compromise has to be made. When an object is actually drawn, its coordinates are adjusted so that they lie in the middle of the appropriate character. An object's width and height specify the number of character cells the object will be part of; they are not the true size of the object. For instance, drawing a box with the function call
\@box 1 0 2 2 would actually produce something like this blown-up diagram:


Function Descriptions
In the function descriptions, required parameters appear within < > brackets, and optional parameters appear within [ ] brackets. The following functions are available:


\@image A GEM XIMG graphic
\@image <x> <y> <width> <height> <IMG file1> [IMG file2] [IMG file3]...

This function includes one or more GEM image (IMG or XIMG) files in the source. Unlike all other graphics functions, the coordinates for this function really do define the outer size of the entire graphic.
The width and height are treated as a maximum: the image is expanded until either its width or height hits one of these two values.

Furthermore, the aspect ratio of an image is corrected if the user is in a video mode whose aspect differs from that of the image itself. For instance, to display an ST High resolution image in ST Medium resolution, GNVAHELP compresses the image vertically by 1/2. This prevents the image from looking stretched-out.

By specifying more than one image file name, you are providing alternate versions of the same image, to be used depending on the quality of the user's video display. XIMG files with any number of bitplanes, up to 24-bit true color, can be used. When GNVAHELP displays the screen, it chooses the image that contains the closest number of bitplanes to the current screen mode, without going over. This means that you should always have at least a 2-color (1 bitplane) image in the list; otherwise anyone looking at your help file in ST High resolution will get a blank spot instead of a picture.

Makehelp does not interpret the contents of an IMG file that is included in a HLP file, it simply stores it inside the HLP file. GNVAHELP will not display any picture if there is an error in the format of the IMG.
Example:

\@image 3 31 99 3 c:\images\2color.img 4color.img 256COLOR.IMG


\@button A selectable button that links to another screen
\@button <x> <y> <width> <screen name>
This function draws a dialog button in the help screen at the chosen coordinates. When the user clicks on the button, GNVAHELP will try to access a help screen with the name . The also appears as the text inside the button.
Example:

\@button 4 9 14 Screen Types

Instead of using normal text, you can also provide a named link by enclosing the location to link to in {}'s. Example:

\@button 4 16 14 {Screen Types}Same Thing


\@bar A filled, outlined box
\@bar <x> <y> <width> <height>
Display a filled, outlined box. See also: \@sfill, \@swrite, \@slinecol, \@slineends, \@slinestyle, and \slinewidth. Example:

\@bar 4 6 10 2


\@rbox A hollow, rounded, outlined box
\@rbox <x> <y> <width> <height>
Display a rounded, outlined box with no interior. See also: \@swrite, \@slinecol, \@slineends, \@slinestyle, and \@slinewidth. Example:

\@rbox 4 6 10 2


\@rfbox A rounded, filled, outlined box
\@rfbox <x> <y> <width> <height>
Display a rounded, filled, outlined box. See also: \@sfill, \@swrite, \@slinecol, \@slineends, \@slinestyle, and \@slinewidth. Example:

\@rfbox 4 6 10 2


\@recfl A filled rectangle
\@recfl <x> <y> <width> <height>
Display a filled rectangle, without an outline. See also: \@sfill and \@swrite. Example:

\@recfl 4 6 10 2


\@line One or more straight lines
\@line <x1> <y1> [x2 y2] [x3 y3]...
Draw a single point, or a continuous line from coordinate to coordinate. See also: \@swrite, \@slinecol, \@slineends, \@slinestyle, and \@slinewidth. Example:

\@line 9 7 14 9 9 11 4 9 9 7


\@swrite Set the writing mode
\@swrite <mode>    1 (Replace) by default

Set the "writing mode" that will be used by all graphics functions except for \@image (which always uses Replace mode.) By writing on top of existing graphics or text with the various writing modes, different effects can be produced.


Replace     1       (default)

Transparent 2

XOR         3

Erase       4

For examples of these modes, refer to GRAPHICS.HLP: Writing Modes


\@sfillcol Set the fill color
\@sfillcol     1 (black) by default

Set the color of filled objects, drawn by \@bar, \@rfbox, and \@recfl. is the index of the VDI color register to use:


White            0			Gray             8

Black (default)  1			Dark Gray        9

Red              2			Dark Red         10

Green            3			Dark Green       11

Blue             4			Dark Blue        12

Cyan             5			Dark Cyan        13

Yellow           6			Dark Yellow      14

Magenta          7			Dark Magenta     15

For examples of the colors, refer to GRAPHICS.HLP: Lines


\@sfillint Set the fill interior type
\@sfillint <type>    2 (pattern) by default

Set the fill interior type, drawn by \@bar, \@rfbox, and \@recfl. is one of these values:


Hollow    0

Solid     1

Pattern   2  (default)

Hatch     3

A call to \@sfillstyle will set the style of the fill when mode 2 or mode 3 is used. For examples of the types, refer to GRAPHICS.HLP: Fills


\@sfillstyle Set the fill style
\@sfillstyle <style>    7 (solid) by default

Set the fill interior style, drawn by \@bar, \@rfbox, and \@recfl. When \@sfillint is set to 2 (Pattern), valid range from 1 to 24. When \@sfillint is set to 3 (Hatch), values range from 1 to 12. For examples of the styles, refer to GRAPHICS.HLP: Fills


\@slinecol Set the line color
\@slinecol <color>    1 (black) by default

Set the color of lines, drawn by \@bar, \@rfbox, \@rbox, and \@line. is the index of the VDI color register to use:


White            0			Gray             8

Black (default)  1			Dark Gray        9

Red              2			Dark Red         10

Green            3			Dark Green       11

Blue             4			Dark Blue        12

Cyan             5			Dark Cyan        13

Yellow           6			Dark Yellow      14

Magenta          7			Dark Magenta     15

For examples of the colors, refer to GRAPHICS.HLP: Lines


\@slineends Set the line start/end types
\@slineends <start> <end>    both 0 (square) by default

Set the type of ends that are used on lines, as drawn by \@line, \@bar, \@rbox, and \@rfbox. The following values are supported for and :
Square (default)0 Arrow 1 Rounded 2
Example: Use arrows at start and end of line segments: \@slineends 1 1 For examples of the start/end types, refer to GRAPHICS.HLP: Lines


\@slinestyle Set the line style
\@slinestyle <style>    0xFF (solid) by default

Set the appearance of lines, as drawn by \@line, \@bar, \@rbox, and \@rfbox. This can be used to produce a dashed or dotted effect on lines. The style is a single number in the range 0 to 255 ($0 to $FF) whose bits give the pattern of the new line.
Examples:


\@slinestyle 0xFF   XXXXXXXX (solid line, the default) 

\@slinestyle 0x55   X.X.X.X.

\@slinestyle 0xF0   XXXX....

\@slinestyle 0xCC   XX..XX..

For examples of styles, refer to GRAPHICS.HLP: Lines


\@slinewidth Set the line width
\@slinewidth <width>    1 by default

Set the thickness of lines drawn with \@line, \@bar, \@rbox, and \@rfbox. Only odd numbers 1 or greater cause the actual appearance of the line to change. Higher numbers produce a thicker line.
For examples of the thicknesses, refer to GRAPHICS.HLP: Lines


\@extern Define the default file for external keywords
\@extern <HLP file name>
When a help file contains references to screen names that are not contained in that help file, GNVAHELP searches all .HLP files in the path the user has specified in the Set Help File Path menu entry of GNVAHELP. This function speeds up the search for an external reference by allowing you to tell GNVAHELP the name of the file to look in first. The filename should not contain any path or drive information, but should have the .HLP extension on the end.
Example: This is an external reference to Geneva's main help level:
\#Geneva\# \@extern geneva.hlp Only one \@extern can be specified per help screen. If the help topic is not found in the specified file, or the file does not exist, the remaining .HLP files are searched, as normal.


Types of Index
By default, Makehelp tries to generate an index for the help file which consists of all keywords listed alphabetically on one screen. If this would exceed 100 lines, or if you use an optional commandline switch, Makehelp will instead generate a main level index with just the entires "A.." through "Z.." and will also provide as many individual help screens as are necessary for these categories.


Commandline Arguments

Makehelp can be called from the desktop as a TTP program, or from a command line interpreter. It has two distinct modes. The first mode is used to automatically highlight all hypertext links that were not already pre-defined:

 Usage: makehelp -s <source> <newsource>

In this case, <source> is the name of a help source (usually ending in ".HS") file. <newsource> is the name of a new .HS file which is generated by Makehelp.

The new file contains all screens in the source file, with all new hypertext links starting with the sequence \## (as opposed to \#). If the same keyword appears more than once in a given screen, only the first occurence is marked, so as to avoid too much clutter in the help screen. Since there may be cases where you do not want a particulpu link, the \## allows you to easily pick out which references were generated by Makehelp, and remove the ones that are unwanted.

Note that all \## sequences must be either completely removed or replaced with \# before compiling the <newsource>!! You should also be aware that the order of the \screens in <newsource> will most likely be different from the order they were in in the <source> file, and that any comments in <source> will not carry over to <newsource>. There may also be other formatting differences which do not affect the final .HLP file.

The other mode is used to generate a finished help (.HLP) file. It has two required parameters, and two optional ones:

 Usage: makehelp [-m] [-n<lines>] <source> <hlpfile>
-m: force multiple-screen index
-n: maximum number of lines per screen (default=200)

The file (which usually ends in the extension ".HS") is compiled, and the output is written to the (which usually ends in ".HLP".)

The -m option forces Makehelp to generate a multiple-screen index, as described in the Types of Index section.

The -n option allows you to use more than 200 lines of text per help screen. Since the help viewer that comes with Geneva 004 and NeoDesk 4 (005 or older) cannot view more than 100 lines per screen, this option can also be used to force a fatal error if more than 100 lines appear in any screen. Make sure not to put a space between -n and the number.

Source Examples


For clarity, the following examples are indented two spaces.

 Examples of some special sequences

\screen Sequences
    This is the \x3 right arrow character. Here is the Registered symbol, as part of NeoDesk\xBE 4.
    This produces a single backslash: \\.
\end

 Define a normal, case insensitive screen. Also give it an alias and a named link

*** This is a comment, because it appears before the first directive.
\screen Normal Topic
\screen First Screen
First Screen

This is the text of a help screen which can be found regardless of the case of the string the user supplies.

Here is a reference to the screen, below:	\#Second Screen\# 

a reference to a hidden screen:				\#Hidden\# 

and a named link to the same screen:		\#{Hidden}Yowza!\# 

\end


 A case-sensitive screen

\casesens Second Screen
Second Screen

This screen can be jumped to from the \#First Screen\#, or it can be searched for in the index.
\end


 A screen with a Hidden name and a normal name

\hidden Hidden
\screen Third Screen
Third Screen

While the name "Third Screen" will appear in the index, the name "Hidden" will not. Furthermore, it cannot be searched for at all.
\end

 An index screen
*** Define an index screen which is different from the default
\index

This is an optional index. Without it, the default alphabetical index would be used.
Double-click on a screen name below:
\#First Screen\#     bsp \#Second Screen\#      \#Third Screen\#
\end


 A screen which shows how the \@extern function works

\screen Test
"extern" Test of "extern" function

This screen contains a reference to a topic which appears in the file TASKMAN.HLP. The "extern" function instructs the help viewer to look in a particular HLP file first.

Jump to TASKMAN.HLP:

\#Task Manager\# \@extern TASKMAN.HLP

\end


Limits


Lines per screen:                           (see -n parameter)

Characters per line (including CR/LF):      100

Length of a keyword:                        43

Maximum number of index entries:            5346

Maximum number of index entries per letter: 198




beginning of section
top of page

README for Geneva

12/31/93

Please be sure to use the NeoDesk and NeoDesk CLI patch programs, as appropriate. Then, install the new versions and make sure that they work properly before installing Geneva.

Then, use the automated installation program, INSTALL.PRG. It automatically ensures that all of the Geneva files end up in their correct locations.

Another important note: if you use the INSTALL.PRG to set up NeoDesk as the "shell" program: If you also have NeoDesk set to autoboot, you will end up with two copies running at once. If this is the case, you should disable Autoboot status using Atari's desktop, or with your boot-up manager.

Furthermore, if you normally use STARTGEM.PRG to autoexecute a program, you should know that it is no longer needed. It should be removed from the AUTO folder. FormDoIt! is also not needed.

IMPORTANT:

The following programs have default flags with the "Lit memory" option turned on. If you run one of these programs regularly, you may want to increase the amount of memory it is allowed to use. Otherwise, you may run out of memory at unexpected times:


  CALAMUS.PRG         2.5 Mb

  FLASH.PRG           1 Mb

  PGS2.PRG            2 Mb

  TEMPUS*.PRG         1 Mb

  WORDPLUS.PRG        1 Mb

In the case of Calamus, the use of 2.5 Mb assumes that you are using Calamus 1.09. Calamus SL uses its own memory configuration (see below). Unfortunately, both versions of Calamus use the same file name, so it is not possible to have independent flags for both versions, unless you rename one of the programs. (Like calling the old version CALAMUS1.PRG).

If you intend to use Calamu5"SL, the best procedure is to remove Geneva's flag entry for it completely, or just disable the Limit Memory option. Then, use Calamus's "System" dialog to configure the memory. IMPORTANT: the memory numbers in this dialog are the number of bytes (not Kb) of system memory to leave free AFTER Calamus has loaded, NOT the amount for it to actually use! If you make this number too large, Calamus will refuse to run and you will have to remove or rename your CALAMUS.SET file and rerun Calamus in order to change this setting.

Known incompatibilities (there are a few other minor ones):

One problem with version 1.1, however, is that the main area of the XCONTROL window will be too short when displayed in ST High resolution. This causes several pixel lines at the bottom of the window to be left undrawn. While this can be corrected by using the Task Manager's Window Options to increase the gadget border height, it is really only cosmetic. This has been fixed for XCONTROL 1.3.

There is also a problem with the BCOLORS.CPX (Background colors) that comes with XCONTROL. It only saves one group of settings. This means that if you begin in a color resolution, save the settings, and then go to a monochrome resolution, BCOLORS will try to set the colors to all black! Geneva has code which detects the fact that it is being told to use a bad color index, and it ignores the request.


Geneva Revision Notes

TASKMAN:

Added a new Misc. Option to allow the video resolution in GENEVA.CNF to be ignored, in favor of the one in NEWDESK/DESKTOP.INF. This means that you can continue to use a boot manager like XBoot to choose video resolutions using the same method you always used.

The main window can now be "iconized" by clicking on the "delta" gadget.This shrinks any open windows to a single "icon" window. Double-clicking on the icon window's contents will reopen the Task Manager.

The Window Options dialog now accepts any Speedo GDOS font, and any other monospaced GDOS (bitmaped or scalable) font which has all 255 characters. This font is used when drawing menu bars, windows and dialogs. There are a few restrictions, though:

The objects which make up the Sample dialog in the Dialog Options dialog can be clicked on in order to switch object types.

GENEVA:
The icons in alerts will be colored if there are at least 16 colors available in the current video mode.

Item selector: If the path is very long, only the first 10 characters of the template will be shown when the path gets updated. This way you can always see at least the last 16 chars of the full path.

You can now press [Alt][\] to move to the root directory in the item selector.

Using GDOS fonts within TEDINFO objects is now supported, as in AES 4.1. Note that if you click on an editable field containing a GDOS font with the mouse, the edit cursor will always be positioned to the end of the field. Actually positioning to the character under the mouse would be too computationally intensive.

Added a new type of wildcard to the item selector. The ! can be used for inversion ("not") of the next item in a string. If the next item is just a regular character, then that one letter will be inverted; if the next item is a {} or [] bracketed expression, then the meaning of that expression will be inverted. Examples:


    *.prg           Ending in PRG

    *.!abc          *.?BC, excluding *.ABC

    *.ab!c          *.AB?, excluding *.ABC

    *.!a!bc         *.??C, excluding *.ABC

    [a-d]*.*        Starting with A, B, C, or D

    ![a-d]*.*       Anything not starting with A, B, C, or D

    *.{prg,prx}     Ending in PRG or PRX

    *.!{prg,prx}    Anything not ending in PRG or PRX

Any number of !'s can be used within a wildcard. The effect is that the expressions are negatively added together. For example:


   !{stalker,neodesk?}.!{ac[cx],rsc}



   Matches anything but:



   stalker.acc    stalker.acx    stalker.rsc

   neodesk?.acc   neodesk?.acx   neodesk?.rsc

However, NEODESK.ACC will match, since it does not have a character between the "k" and the period.

The ! can be used in the main item selector path, and also in the Find dialog.

Added a new flag to allow the video resolution in GENEVA.CNF to be ignored, in favor of the one in NEWDESK/DESKTOP.INF.

A program flag has been added for GENEVA. This allows you to change the name of the Geneva Manager in the Desk menu (and also its Activation key) by using the Task Manager.




beginning of section
top of page

Programming additions:

wind_get() modes X_WF_HSPLIT (0x1700) & X_WF_VSPLIT (0x1800)

The manual does not document the parameters returned by this call, and it differs from what is passed in the equivalent wind_set().

wi_gw1: Split bar position
wi_gw2: Size, in pixels, of the upper (or left) window region
wi_gw3: Size of the lower (or right) window region

evnt_mesag() return X_WM_OBJECT (0xE900)

This message type is returned to an application when it uses wind_set() mode X_WF_OBJHAND to affect the manner in which window gadgets are handled.

If an application receives this message, it is because the object tree handler routine instructed Geneva not to process the mouse click on a window gadget as a normal event. Instead, a special message is returned to the application:


        Word 0: 0xE900

        Word 1: Application ID

        Word 2: 0

        Word 3: Handle of the window containing the object

        Word 4: Object tree index of the object which was clicked

Note that in order HEr Geneva to determine that the mouse has been clicked on an object in a window's tree structure, it must be of type EXIT or TOUCHEXIT. Geneva's default window gadgets already have these attributes set correctly.

See also: wind_set() mode X_WF_OBJHAND.

wind_get()/wind_set() mode X_WF_OBJHAND (0x1F00)

When an application wants to intercept some or all of the button events that would otherwise be interpreted as Geneva to mean that a window gadget has been clicked on, this wind_set() mode can be used to provide Geneva with the address of a routine which instructs Geneva to either ignore the event, or to process it as normal. This allows the programmer to redefine the operation of window gadgets, and to define his own actions for new gadgets which have been added with the x_wind_tree() function.

The routine is passed the handle of the window containing the object and the index of the object within the window's object tree. If the user routine returns a 0, then Geneva will generate an X_WM_OBJECT message and send it to the application. If the routine returns a 1, then Geneva will process the action as a normal event and act accordingly.

IMPORTANT:

The application's object handler routine must not using any AES functions.

The following example declares an object handler which allows the action of the vertical scroll bar to be redefined:


      /* change this to "int cdecl objhand..." for Pure C */

      int objhand( int handle, int obj )

      {  /* hand

 parameter is not used */

        if( obj==WGVSMLSL ) return 0;   /* this is the vertical slider 

          */

          return 1;                       /* otherwise, process as 

          normal */

        }



        main()

        {

          int handle, message[8];



          handle = wind_create( NAME|MOVER|VSLIDE|UPARROW|DNARROW,

              50, 50, 150, 150 );

          if( handle > 0 )

          {

            wind_set( handle, X_WF_OBJHAND, &objhand );

            wind_open( handle, 50, 50, 150, 150 );

          }



          ...



          evnt_mesag( message );

          switch( message[0] )

          {

            case X_WM_OBJECT:

              if( message[3]==handle && message[4]==WGVSMLSL )

                 /* do something new with the slider */

          }

        }

If wind_set( X_WF_OBJHAND ) is passed a NULL pointer, instead of a pointer to a function, object handling is discontinued for that window.

Note that in order for Geneva to determine that the mouse has been clicked on an object in a window's tree structure, it must be of type EXIT or TOUCHEXIT. Geneva's default window gadgets already have these attributes set correctly.

wind_get() can also be used to get a pointer to the current object handler routine. A NULL pointer means that there is no object handler defined.

wind_get()/wind_set() mode X_WF_DIALEDIT (0x2000)

When a windowed dialog has been defined with wind_set() mode X_WF_DIALOG, these two options can be used to get or set the index of the object which currently has the edit cursor. This can be helpful when an application changes the contents of a text field while the dialog is still displayed, or when it needs to hide the object that currently has the edit cursor.

wind_get( X_WF_DIALEDIT ) will return the index of the object which currently has the edit cursor in the "wi_gw1" parameter, and the position of the edit cursor within the object's text in the "wi_gw2" parameter.

wind_set( X_WF_DIALEDIT ) changes the object ("wi_sw1") and the edit index ("wi_sw2"). If the object is 0, then the edit cursor will simply be turned off; otherwise it will be moved to the new object. If the index is 0, the cursor will be positioned before the leftmost character in the field; if it is a number > 0, it will be further to the right. If the index is -1, then the cursor will be automatically moved to the rightmost position.

New extended OBJECT types X_USRDEFPRE (90) and X_USRDEFPOST (91)

It is sometimes desirable to change the appearence of an object slightly, but using a G_USERDEF object would necessitate putting a lot of extra code into the user routine, since a G_USERDEF object cannot have any text, fill, or border. They have to be drawn by the user routine, or not at all.

Geneva provides two new extended object types which allow an object to be modified or have its appearence altered, while still having the iyme opportunity to be drawn like a normal object.

If bits 12-15 of an object's ob_state are 9 ((ob_state&X_MAGMASK)==X_MAGIC) and the high byte of the ob_type is either 90 (X_USRDEFPRE) or 91 (X_USRDEFPOST), then the ob_spec of the object is assumed to contain a pointer to a USERBLK structure. This is much like a normal G_USERDEF object, except that the ub_parm member of the USERBLK structure must contain the value which would have been in ob_spec if the object was not a G_USERDEF.

Since this may sound a little confusing, the following example can be used. It defines a G_BOXCHAR object which has its character increased by 1 every time the object is drawn:


        /* contains the code which increments the character and

           the old ob_spec value */

        USERBLK user;

        /* start with a G_BOXCHAR object, with the character '1',

           black border of thickness of 2, black text, patterned */

        OBJECT ob = { -1, -1, -1, G_BOXCHAR, 0, 0,

            ((long)'1'<<24)|(2L<<16)|(1<<12)|(1<<8)|(2<<4)|1,

            50, 50, 25, 25 };



        int cdecl inc_char( PARMBLK *p )

        {

          char c;



          /* extract the character, which is in the MSB of the

             ub_parm element of "user" */

          c = ((user.ub_parm>>24) & 0xFF) + 1;

          /* now put it back */

          user.ub_code = (c<<24L) | (user.ub_parm & 0xFFFFFFL);

          /* return the current state */

          return p->pb_currstate;

        }



        void draw_it(void)

        {

          objc_draw( &ob, 0, 0, 50, 50, 25, 25 );   /* draw */

          Bconin(2);                   /* wait for keypress */

        }



        main()

        {

          /* start by drawing the object normally */

          draw_it();

          /* now, set up the USERBLK */

          user.ub_code = &inc_char;     /* function */

          user.ub_parm = ob.ob_spec;    /* old ob_spec of object */

          ob.ob_type |= X_USRDEFPRE<<8  /* extended ob_type */

          ob.ob_state |= X_MAGIC;       /* set magic number */

          ob.ob_spec.userblk = &user;   /* set ob_spec */

          /* now, draw it a few times anCwatch the number go up */

          draw_it();  draw_it();  draw_it();  draw_it();

        }

An X_USRDEFPRE function is called before the object is drawn. In contrast, an X_USRDEFPOST function is called after the object's contents have been drawn, but before any ob_state effects are processed.


beginning of section,  Index,  Previous section
top of page