[Omnis-Newsletter] Omnis Technical Newsletter

[omnis-news-admin@omnis.net]

 February 6th, 2002

========================================

UNSUBSCRIBE OPTIONS: You have been sent this email because you have directly
signed up for, or expressed an interest in receiving a technical newsletter
when you downloaded an evaluation of Omnis Studio, or registered the Lite
version of Omnis Studio. If, however you feel you have received this email
in error you can unsubscribe as well as change your subscription options at
www.omnis.net/newsletter.

N.B.  If you subscribed by checking a box on one of our forms, you will not
have received a password. You will need to submit your email address at
www.omnis.net/newsletter and select the 'email me my password' option on the
next page in order to receive this.

========================================

WELCOME!

Welcome and thank you for subscribing to the Omnis Technical Newsletter.
Published fortnightly, it is intended for Omnis developers of all levels and
experience, for those people evaluating Omnis Studio, or for developers
moving from a similar tool. We think you'll find the content both
interesting and useful for your Omnis development needs and hopefully it
will help you become more productive in Omnis application design.

In the first article in this newsletter, Geir Fjaerli continues his tutorial
by adding the main menu to our Task management application. In the second
article, David Swain discusses radio buttons and check boxes and describes
how you can use them in your Omnis applications. You may find it easier to
work through the exercises and examples in this newsletter by printing it
out before you begin.

CONTENTS:
-About the Authors
-Building part 17: Toolbars and menus, by Geir Fjaerli.
-Omnis News: Omnis at CeBIT 2002, Studio 3.2 Heads up, and more...
-Checkbox, Radio Button and Toolbar Object Options, by David Swain.
-Copyright and Unsubscribe details


========================================

About the Authors

The Omnis Technical Newsletter contains high quality content from two
leading and well respected Omnis developers, Geir Fjaerli and David Swain.

Geir Fjaerli is based in Norway and has been an Omnis professional developer
for many years as well as a Regional Sales Manager for Omnis. He is
currently working freelance again developing a range of products (in Omnis
of course) including his Prophet5 sales and customer relationship management
solution, now available for Mac OS X. Geir is a regular contributor to the
annual Omnis Developer conferences in the US and Europe, speaking about
Object-Oriented programming in Omnis and SQL development, amongst other
things.

David Swain is the founder and president of Polymath Business Systems, for
many years a leading provider of Omnis training. His expertise in Omnis
programming and his ability to make complex concepts understandable are
recognized throughout the worldwide Omnis community. Latterly, David has
appeared at Omnis Developer conferences providing his own Studio 101
introductory course to Omnis programming and application development.


========================================

Building part 17: Toolbars and menus.
By Geir Fjaerli, Sunshine Data
Email: geir@sunshinedata.net
Web: www.sunshinedata.net

Hi, and welcome back to our Omnis Studio tutorial.

Here is our work so far:
Part 1: Hello World, our first little Studio application
Part 2: The Studio Classes. The classes are the building blocks of an
application, and include windows, reports, menus etc.
Part 3: The Omnis Integrated Development Environment. Here we looked at the
Component store, the Property Manager and the Catalog.
Part 4: The Data Structure. Including basic terminology.
Part 5: Creating schemas and database tables.
Part 6: Adding table classes and using our schemas in application windows.
Part 7: What did the wizard build, and a tour of the method editor.
Part 8: The logon window and object class.
Part 9: The task window.
Part 10: The task window continued.
Part 11: Designing a proper data entry interface.
Part 12: Implementing the data entry interface.
Part 13: Implementing the data entry interface, part 2.
Part 14: Implementing the data entry interface, part 3.
Part 15: Implementing the data entry interface, part 4.
Part 16: Implementing the data entry interface, part 5.
You should have those handy, and your "tasks.lbs" library file.

As usual, I strongly suggest that you refer to these parts if you haven't
already, or if you feel uncertain about the details. From part 5 onwards,
each new part will be based on programming done in previous parts, so you
have to follow them all. (For back issues, please go to
www.omnis.net/newsletter and click on the Newsletter Archive link.)

WHERE ARE WE?
The last issue marked the end of a marathon development effort: We have
spent the last 5 issues implementing the controls and the code for our task
window data entry and retrieval. We now have a working window, including
most of the bits and pieces that a user expects from a proper application.
Compare this to the Employee window generated by the built in wizard. In
fact, if you want a little test of your Omnis skills, you could try to
implement the modal techniques that you have learned now in that window too.
(If you do, feel free to ask me if you get stuck somewhere.)

ALTERNATIVE USER CONTROL INTERFACES.
While our window now has most of the interface logic in place, we have put
less effort into tying the bits and pieces together. Today we are going to
look at how the user navigates through our application, and through the
data.

So we have two levels of navigation:
1. How does the user navigate through the various parts of the application?
This is the most glaring omission in our little application so far. We do
not have any mechanism to let the user select which window to open, which
report to print and so on. (Currently we do not have any reports to print,
that is coming soon.)

As we have been working in the development version of Omnis, we have opened
the windows from the design environment. This is no good for the user, in
fact they will most likely be using a runtime version of Studio, which does
not have the design tools at all. So we need to create and environment for
them to navigate by.

2. How does the user navigate around their data? Find, insert and delete
records in the database. Currently we have solved this by the use of
pushbuttons. This is a traditional approach, in fact buttons have been used
in Omnis since the first graphical version was released in 1985. Since then,
new operating systems and new standards for GUIs have emerged.

There are many alternatives today. Almost as old as the pushbutton is the
drop down menu. Unix GUIs introduced the pop up menu. With Windows 95 came
the icon toolbar, and with Outlook the Sidebar control, to name a few.

Studio offers a number of controls to let us implement such interfaces. So
you can pick your favourite, and get to work. Well actually, it is not quite
that easy. Most of these various interfaces were built for a reason, and one
may be better suited to a given purpose than another.

Look at the drop down vs. the pop up menu. When the Macintosh first arrived,
user friendliness was important. They didn't want the user to have to look
around for a function, they should always know where to find it. So they put
the menu bar at the top of the window, and urged all developers to put the
standard menus in there, in the same order. I must admit I still think this
is the perfect user interface.

However, for a CAD designer working on a set-up of two or three large
monitors, this was not ideal. Because if you were working on an object on
the bottom of the third monitor, it was not so good to have to go all the
way to the top of screen one to select a function. Better then to have the
menu popping up under the mouse, wherever it currently was.

Another issue is OS standards. Between Windows, MacOS, various Linux/Unix
GUIs and more, you will find that they each have a given look and feel. You
may remember that in our task window I recommended using drop down lists on
Windows and pop lists on the Mac. You should design your application for the
platform it is going to run on, and if you target multiple platforms you
should make sure that it looks "at home" on all of them.

So there is a time and a place for each of these interfaces. Arguably, some
of them have little to recommend them other than a pretty face, like the
Outlook sidebar. But I will leave such considerations to you. We are going
to look at the technical side of things.

THE MENU AND THE TOOLBAR.
Today we are going to look at the first of two of these interfaces, the menu
and the toolbar. These are fundamental to modern GUIs. Also, in Omnis they
are different from some of the others, in that they are classes in their own
right, just like a window or report. This is unlike say a pushbutton, which
is 'just' a window control.

Since the menu and toolbar are classes, it means we can define them and
design them independently of where we ultimately want to use them. So the
same menu can be installed on the main Omnis menu bar, or inside a window,
or popped up anywhere as a context or pop up menu.

Note: Saying "the same menu" is a bit wrong. We are actually creating
instances of the menu class, so each time we install or pop up a menu, it is
a separate instance, but they may be of the same class.

The toolbar has two possible locations, either in the main Omnis toolbar, or
in the toolbar of a window.

Where we put them, depends on what we use them for. Again, there are many
ways to do it. I would say that if a menu or toolbar works on a given
window, I would install them inside the window. That is usually not so on
the Macintosh, though.

OUR MENUS AND TOOLBARS.
As we started discussing, we need two sets of toolbars and/or menus. One for
navigating the application, and one for navigating the data. The data menu
is traditionally referred to as the Commands menu in Omnis, which in fact
has a built in one. That one is intended for the native Omnis DML, so we are
not going to use it.

THE APPLICATION MENU.
We just said that menus are classes in Studio. That means that to add one,
we add it to the class browser just like windows or other classes. So open
the Browser to show your existing classes (like wTask, wLogon, sEmployee...)

Now we shall create the application menu. So create a new menu class by
either:
A. Dragging a "New Menu" in from the Component Store, or
B. Selecting "New" and then "Menu" from the Class menu in the Browser.

Name the new menu mMain. Its icon resembles a pull down menu. To design the
menu, double-click its icon. A menu editor window opens. We design a menu by
simply typing the text of the menu titles and menu lines in this editor.
There are no controls to add, so the Component Store is of no use here.

When you open the menu editor, you will see a grey inset line with a blue
rectangle above it. The area above the line is the menu title, while the
area below it will display the menu lines as you create them. When the
window is opened, the menu title is selected, so if you start typing right
away you will be adding the menu title text. Type "Main" (without quotes),
that will be the title of our menu. Hit the Return key to finish editing the
title.

Hit Return again and the first line will be added to the menu. You will
notice that initially it displays a separator line. When you start typing,
it is replaced with the text you type. Type "Tasks" (again without quotes)
and hit Return to confirm and go to the next line. This time type
"Employees".

Note: If you create a line and do not type anything, it will display as a
separator line, useful for grouping parts of the menu.

If you want to delete a line, right-click the line to open the context menu.
(That happens quite often, since Return automatically creates a new line.)
You can also use the context menu to add a line, instead of using Return.

Now that you have created a couple of lines, you can test/install your menu.
Right-click in the editor and select "Install Menu". Your menu will be
installed on the main Omnis menu bar, between the Tools and the Window
menus. Click it to see your two menu lines drop down. As you can see it is
already fully functional. It doesn't do anything, since we haven't added any
code to the menu options, but Omnis has saved us all the work of making the
menu appear and "drop down".

Note that the installed menu is an instance of the menu class, just as an
open window is an instance of a window class. So if you make changes to the
menu class, you have to remove the menu (right-click in the editor again and
choose "Remove Menu") and install it again.

MENU PROPERTIES.
While the Component Store is of no use to us here, the Property Manager is.
Let us quickly examine some of the properties for menus and menu lines.

To set the properties for the menu class, you must select the menu title
rather than a menu line. (You can also set the properties by selecting the
class in the Browser.) So click the menu title and open the Property Manager
if it isn't already.

You will see all the usual properties on the top of the list, like name,
desc, moddate and external. In fact the menu class has only got four unique
properties:
Title, which is already set in the editor,
Enabled, which enables or disables the whole menu, and
Helptest, which holds the text that will be displayed in the helpbar when
the user selects the menu, and finally
Users, which controls user access levels.

The title can be set either in the Property manager or by typing directly in
the editor. The "enabled" class property controls the initial state of the
menu, if false the menu cannot be "dropped down"; note "enabled" is also a
property of the installed menu instance, so we can toggle the menu "on" and
"off" at runtime, depending on some condition.

The User levels can be set according to a user password, so that a given
user is given access to a menu or not. The same property can be assigned to
an individual menu line to control access to that line.

Now we will look at the menu line properties. Click on either of the two
lines in the menu editor. Here are a few unique properties. As with window
controls, a menu line has a name and a text attribute. The name is the
internal name for the menu line that we use in our code, while text is what
is displayed in the menu when the user selects it.

Next are "enabled" and "checked". Enabled works as for the menu property,
but here it enables or disabled the selected menu line only, rather than the
whole menu. "Checked" displays a little check-mark in front of the menu
text, meaning "This option is currently toggled on". This is just a visual
element, it is up to us to create any related code. Both of these are both
class and instance properties, so in design you can set the initial value,
and at runtime you can toggle it from your code.

After the "users" property come three shortcut key properties, one for each
of the main platforms. The shortcut property assigns a keyboard key
combination to a menu selection, so that rather than pulling down the menu
and selecting "Save" in a program, you can e.g. hit Ctrl+S on a PC or Cmd+S
on a Mac. You can set these in three ways:
1. By simply typing a Ctrl/Cmd combination when the line is selected in the
editor. (You may already have discovered this if you tried to hit Ctrl+S to
save the menu.)
2. You can type the combination as text into the Property Manager, with a +
sign between the modifier name and the key.
3. Clicking the down arrow on the property will bring up a dialog to set the
property or clear it.

"Cascade" allows you to set cascading menus, also known as sub-menus or
hierarchical menus. When a menu line is set as cascading, selecting that
menu option will open another menu as a sub-menu next to that one. A
sub-menu can itself contain a sub-menu, but I recommend that you use them
sparingly, as many users find them tricky to navigate.

Then there is an "iconid" property, which lets you assign an icon to a menu
line. Note that icons are not used in menus on the Macintosh.

And finally there is a text "fontstyle" property, which allows you to set a
menu line text to bold, underlined etc. Not recommended on any platform...

For the main menu none of these properties need to be changed, so let us
move on to the logic behind the menu.

THE MAIN MENU CODE.
To add code to a menu, either double-click or right-click and select the
appropriate option. (Class methods or line methods). When double-clicking,
clicking on a line will open the method for that line, clicking elsewhere in
the editor will open the class methods. Their relationship is basically the
same as between the methods of a window control and the window class
methods.

A menu class has a $construct method which runs when a menu is instantiated,
that is when it is installed. We do not need any code here for the main
menu, but shall use this later for our commands menu.

THE TASKS MENU LINE.
Double-click the first menu line (Tasks) to open the method editor. (Tip: Do
not click on the text itself, as this will select the text for editing
rather than open the method.) This brings you to the $event method of the
menu line. Unlike window objects, the menu lines $event does not have an
event filter filled in. This is because menu lines only receive one event,
clicks, so no test is needed. If you want to, you can add an "On evClick",
and I actually do that, for historical reasons.

This method has only one simple task; to open the wTask window when
selected. So add the following statement to the method:

  Open window instance wTask/*

This tells Omnis to open an instance of wTask. The * tells Omnis to generate
the instance name for us. The reason is that two instances cannot have the
same name in Omnis, they have to be unique. As the instance name is not seen
by the user, it is not that important what it is, so we can happily let
Omnis do it for us. It does so by appending an underscore and a number to
the class name, e.g. wTask_25.

4GL COMMANDS VS DOT NOTATION.
The Open window instance command used above is a so called 4GL command in
Omnis. A number of the main functions in Omnis has these commands, but some
do not.

The 4GL is the way Omnis worked from the beginning. It is a very fast and
easy way to program. As we have discussed earlier, Omnis has a syntax
checking editor, so it can guess which command we want even as we type the
first characters, and prompt us for relevant options and so on.

While fast and convenient, it is a bit limiting. An alternative "language"
was therefore developed in later versions of Omnis. Known as the "dot
notation" it traded some of the convenience for ultimate power and
flexibility. We have already used both in many of our methods.

Using notation, the method above could be written like this:

  Do $clib.$windows.wTask.$open('*')

Here we do exactly the same, we ask Omnis to open an instance of the wTask
window class. Again, we ask Omnis to assign the instance name, note that
this time the * is enclosed in quotes, since the notation parser interprets
it as a text parameter.

In this case either version of the statement will do equally well. But say
we do not want to allow multiple open windows. In the 4GL we would have to
test if the window was open, open it if not and bring it to front if it was.
Notation has a single statement for that. So rather than saying:

  Test for window open {wTask}
  If flag true
    Bring window instance to front wTask
  Else
    Open window instance wTask
  End If

we can simply say:

  Do $clib.$windows.wTask.$openonce('*')

Now whether we do want our users to have multiple open windows or not, is
another discussion. The way we have designed them, that will work fine. We
have used instance vars for our data, and they are unique to each instance.
But we may still decide against it, too many windows may confuse our users.

For now I am going to stick to allowing one open at a time only, so I use
the final statement:

  Do $clib.$windows.wTask.$openonce('*')

That is all that is needed in the Tasks menu line $event method.

THE EMPLOYEES MENU LINE.
The Employees menu line code will be identical to the one we just made,
except of course it should open the wEmployee window. So open the $event
method for the second menu line and add:

  Do $clib.$windows.wEmployee.$openonce('*')

Note that if you simply go from line one to line two in the method editor,
it does not have a $event method yet, and you have to add it. But if you
double-click the line in the menu editor, Omnis will add one for you.

Now you can install the menu again and test how it works. Notice that while
the $openonce method prevents you from having more than one instance of each
window open, you can have both the task and employee window open at the same
time.

INSTALLING THE MENU.
Ok, so now we have a working menu that allows the user to open our windows
at runtime. However, we still have to manually install the menu, and that is
no better. We need to install the menu for the user.

When and where depends on the purpose of the menu. In this case it is the
main navigation menu, it should be open at all times to the user to select
which windows they want to open. (And possibly which reports to print etc.)
So it should be installed on the main Omnis menu bar, at startup, and not be
removed until we close the application.

So the appropriate place for our code to install the menu is the
Startup_Task. As you may remember, when we open the application Omnis
automatically creates an instance of the Startup_Task, and therefore
$construct of the task is executed. We used that to open our logon window.
Now we shall install our menu from the same method.

So close the menu and method editor and double-click the Startup_Task in the
Browser. This will open the method editor for its $construct method. Under
the current line that opens wLogon, add a new line that says:

  Install menu mMain/*

Again we let Omnis name the instance for us. This time it is less important,
since we probably will not install the menu from anywhere else, and so there
will only ever be one instance of it. But better safe than sorry...

We could have used notation here as well:

  Do $clib.$menus.mMain.$openonce('*')

Exactly the same as for our windows, only this time we "open" mMain in the
group of menu classes.

Now to test this, close the method editor, close the application and reopen
it. You should see the logon window open and the Main menu appear on the
menu bar.

There is one small issue with this. The menu is installed immediately after
the logon window is opened. So the user can open the task or employee
windows before they have logged on. That is not so good. How do we solve
this? Well, there are a couple of viable alternatives. Try and think of how.
I'll let that be your little homework until next time.

Take care!

Geir :)


========================================

Omnis News: Omnis at CeBIT 2002, Studio 3.2 Heads up, and more...

Raining Data Germany are pleased to announce they are attending CeBIT, in
Hannover, 13 to 20 March, 2002. For the first time ever, we are in Hall 3
(Stand C66) which hosts many of the world's leading software providers. Come
and meet us!
For more information, click here: www.omnis.net/news
Or see the back issues at: www.omnis.net/news/backissue.html


========================================

Checkbox, Radio Button and Toolbar Object Options
By David Swain, Polymath Business Systems Inc
Email: dataguru@polymath-bus-sys.com
Web: www.polymath-bus-sys.com

------------------------------------------------------------------

In the last issue of Omnis Technical Newsletter we examined various ways we
could display and use pushbutton fields. Checkbox and radio button fields
are quite similar to pushbutton fields in many respects - at least on the
surface - but there are some significant differences.

The "iconid" Property

We can assign an icon to a checkbox or radio button field in the same way we
can to a pushbutton field by using the "iconid" property. That's the
similarity. There are a couple of differences, though. For one, the icon we
specify replaces the default image associated with the control (the default
checkbox or radio button icon for the platform). Omnis Studio intelligently
uses the appropriate icon for the proper look and feel of each platform
without any intervention on our part, but it also allows us to override this
behavior if we have a special fondness for a certain look. If we want our
checkboxes to look like Windows checkboxes, for example, no matter which
platform is currently running our library, we could select icon #206 (from
the "Multistate 2" icon page of the omnispic.df1 icon datafile). Then even
on the MacOSX platform a checkbox will look like an indented square with a
little check mark in it when selected. (Unless otherwise specified, I'll be
using 16x16 pixel icons in this article.)

To have our controls still work "properly" for check boxes and radio
buttons, we must use appropriate "multistate" icons. These icons have five
"states" on their icon page (as seen in the Icon Editor): Normal, Checked,
Hilited (sic), Checked and Hilited, and Checked, Hilited and Grayed.

The highlighted state is the one displayed when the mouse button is down
over the control. For example, suppose we have a checkbox that is currently
not selected. If we move the mouse cursor over the control, nothing
happens - it remains "Normal". If we now press the (left) mouse button, the
icon displays the "Hilited" version. If we don't move the mouse cursor off
the control, but then release the mouse button, the "selected" state is set
for the corresponding variable and the "Checked" version of the icon is
displayed. If we click it again, the "Checked and Hilited" version is
displayed on mouse down and then the "Normal" version is displayed when the
"de-selection" is completed. (The "Checked, Hilited and Grayed" version of
the icon is used to display a disabled field that has been previously
selected.)

The following are some "iconid" values (and icon pages) for various
platforms Omnis Studio supports:

202    Windows 3D beveled and indented radio button (Multistate 1)
206    Windows 3D beveled and indented checkbox (Multistate 2)
200    Smaller version of beveled and indented 3D checkbox from earlier OS
versions
1642   Mac OS9 3D rounded and embossed checkbox (Multistate 3)
1643   Mac OS9 3D rounded and embossed radio button (Multistate 3)

The icons supplied in the Omnis Studio icon libraries allow us to modify the
"look" of these controls. For example, the default Windows controls appear
beveled and indented while the default Macintosh controls appear rounded and
embossed. If we wanted a "beveled and embossed" look consistently across
platforms, we could use icon numbers 203 (radio buttons) and 207 (or 201 -
checkboxes). These were readily available options in Omnis 7 that are now a
little more "hidden" in Omnis Studio, but are available through the "iconid"
property.

But the "userpic.df1" icon library offers a few more options to us. We can
supply an indented or embossed "diamond" look, suitable for either
checkboxes or radio buttons, by using icon ids 204 or 205 (from the
"Multistate 18" icon page). There are also indented and embossed
"radio-style" icon sets (208 and 209 on the "Multistate 19" icon page) with
a slightly different "offset" (up and to the left a pixel) from the "normal"
radio buttons - these left over from some earlier incarnation of Omnis for
ancient operating systems as well.

If you have been exploring along with me to this point, you will have
noticed a few other icons on the "multistate" pages that I have passed over.
These are intended for use with other controls than the ones we are
examining here, so they work a little differently. For example, we might
think it clever to use a closed and opened folder icon for a checkbox field
and select icon number 614 from the "Multistate 2" page. It will certainly
work to display a static state for our control. But this icon set was
intended for use with tree list nodes where there are only two states - so
to conserve space in the icon library, a completely different pair of
two-state icons (closed and opened book) with a completely separate icon id
value (615) was put in the "Hilited" and "Checked and Hilited" slots on the
same line as the folder icon set. The result is that when the mouse is down
on the control when we use the folder icons, an "appropriate" book icon will
flash. (Not a pretty sight!)

Of course, if we still want to use a folder or a book icon for a checkbox
field or a group of radio buttons, we can always make a multistate icon page
in the #ICONS system table of our library and copy these icon sets onto
separate lines of that page. (More on this in the next issue.)

One final word (at least for this section of the article) on the topic of
icons: Nothing but convention keeps us from using round icons for checkboxes
and square icons for radio buttons. We can assign any (properly populated)
multistate icon set to either control type since we are simply using the
different icons within the set to display a state. Convention, though, is a
powerful influence on experienced users, so I'm not suggesting that anyone
pervert convention without good reason. A comfortable user is a happy
user...

The "buttonstyle" Property

The entire discussion above assumes that the "buttonstyle" property is left
at its default value of "kNoBorderButton". The "no border" style for
checkboxes and radio buttons allows the basic nature of the control to be
expressed. If we choose a "normal" icon (single state) for one of these
controls, it will not be able to display the state of the corresponding
variable - as long as we are using "no border" buttons.

But the "buttonstyle" property for radio buttons and checkboxes has the same
options as it does for pushbuttons and these can be used to markedly change
the appearance of the control. The other values for this property also
display the state of the underlying variable independently of any associated
icon.

The main difference between pushbuttons and the controls we are focusing on
in this issue is in how these controls are used. A pushbutton field simply
receives a click (or drop) event and executes a method as a result. Checkbox
and radio button fields display a visible "state" (selected or not) when
clicked as well as providing an option for executing a method as the result
of a click event. The "buttonstyle" property allows us to express the state
of the control in a number of ways.

Any of the "border" button styles indicates a "selected" state by displaying
the button as indented (Windows), indented and darkened (Mac OS9) or colored
(Mac OSX). We may find this more useful in some cases than the "standard"
radio button/checkbox look.

And we can still use icons on these buttons as well. We can either use
"multistate" icons (somewhat redundant, but maybe appropriate) or static
ones - whatever gets the point of the control across best! The icons are
juxtaposed with the text of the button in the same way as with pushbutton
fields (discussed in the last issue) depending on the value of the "align"
property. This lets us do things like putting a working Windows indented
checkbox icon within a Mac OSX system button checkbox field (which turns
blue when selected and clear when not) - if we feel that expresses the
underlying Boolean value well.

But we may not always be using checkbox or radio button fields to represent
data. We may have a need to let the user select states we have created for
our application or choose from among tools we provide (that are only custom
states, after all).

Here are brief explanations of the various button styles as applied to radio
button and checkbox fields:

System Buttons

This button style surrounds the text and/or icon for a radio button or
checkbox field with a system-specific 3D button border. The button acquires
a special platform-specific "look" when it is selected: indented on Windows,
indented and darkened on Mac OS9 and colored (blue) on Mac OSX. For checkbox
fields this style may not convey the proper meaning well, especially on a
Windows machine, without an included multistate icon, as the appearance does
not contrast with anything.

On the other hand, radio buttons groups (that are clustered together)
provide this contrast between the selected item and the non-selected ones.
In fact, it is actually more reminiscent of the automobile radio buttons of
my youth (especially the Mac OS9 look) than is the conventional round radio
button icon.

Header Buttons

These are similar to "system" buttons (identical on Windows), but "flatter"
(fewer pixels for the 3D border) and squarer. On Mac OS9 the selected state
is similar to the "system" style on Windows and is best suited for radio
button groupings. On Mac OSX the selected state darkens the button rather
than coloring it, but the difference is still distinctive.

Multistate icons can again enhance this button style - especially for
checkbox fields.

Combo Buttons

This button style displays no text - only a downward-pointing triangle
(arrow) and an optional icon. On most operating systems this triangle is
displayed on a "heading" style border the full size of the control, but on
Mac OSX it appears on a blue 24x24 pixel square bubble no matter how large
the control is made (as described in the last issue). On OSX the "align"
property puts the optional icon to the right or left of this bubble unless
"kCenterJst" is specified. In that case, it superposes the triangle (but
never quire centers vertically), but can be made to appear above the bubble
if the control is made large enough.

I wouldn't use an icon with this style, as its intended purpose usually
doesn't have an icon. A control like this is normally used to open a dialog
window to show further details. We may have occasion to need this facility
in our applications, so bear it in mind.

"Round" Buttons

These are only actually round in the Mac OSX environment. They are
rectangular everywhere else. If this button style is to be used, I suggest
that the field be made 24x24 pixels in size (as discussed in the last
issue). These buttons display only icons, not associated text, within them.
(The "align" property should be set to "kCenterJst" for best effect.) If
explanatory text is needed, a tooltip is usually the best option. A text
block or label object adjacent to the field is an alternative, but it
doesn't automatically travel with the field if it must be moved or copied.

This look for a radio button or check box is similar to toolbar pushbuttons.
Suppose we wanted to emulate the object group selectors on the Component
Store window toolbar for selecting window class objects. We could create
four radio button fields for the same (Short integer) variable and assign
them these icon id values: 1651 (Standard Fields), 1653 (Background
Objects), 1652 (External Components) and 1848 (Background Components). On
Mac OSX these will look like little round water drops with icons inside, but
on all other platforms they will look like toolbar tools.

Next Time

I hope this discussion has given you some new ideas about how you might
enhance the interface of your applications. In the next issue I will explore
the Icon Editor and how we can create our own icons of various types. We
have already introduced the concept of "multistate" icons, but there are a
few others awaiting discover as well.


========================================

I hope you've found this issue of the Omnis Tech Newsletter both interesting
and informative. Please send me your comments and feedback, and include
suggestions for future articles if you like. We would like to hear from
you...

Regards,
--Andrew Smith.
Omnis Technical Newsletter Editor
Email: editor@omnis.net

========================================

No part of this newsletter may be reproduced, transmitted, stored in a
retrieval system or translated into any language in any form by any means
without the written permission of Raining Data.
(c) Copyright Raining Data, Inc., and its licensors 2002. All rights
reserved.
Omnis(r) is a registered trademark and Omnis 7(tm), and Omnis Studio are
trademarks of Raining Data UK Ltd. Other products mentioned are trademarks
or registered trademarks of their corporations.

========================================

To unsubscribe from this newsletter or change your subscription options,
please go to:
www.omnis.net/newsletter