[Omnis-Newsletter] Omnis Technical Newsletter

[omnis-news-admin@omnis.net]

Omnis Tech Newsletter        April 4th, 2001

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

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 to this the second issue of our Omnis Technical Newsletter.
Published fortnightly, it is intended for Omnis developers of all levels and
experience and for those people evaluating Omnis Studio. 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.

The first article in this newsletter is the second part of Geir's 'Building
your first Omnis Studio application': this time he explains more about the
structure and composition of the Studio application and their class types.
The second main article discusses the use and advantages of using styles in
Omnis Studio, a great time saver for cross-platform development. 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 your first Omnis Studio application: PART 2 Omnis Classes, by Geir
Fjaerli
-About Omnis Training
-Matters of Styles, by David Swain
-About Omduit, the 'out-of-the-office' data management tool
-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, soon to be released for Mac OS X.

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.


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

Building your first Omnis Studio application:
PART 2 Omnis Classes
By Geir Fjaerli, Sunshine Data
Email: geir@sunshinedata.net
Web: www.sunshinedata.net

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

In the previous issue of the technical newsletter we made our first Omnis
application. If you didn't complete that exercise, you may want to do that
before continuing with this part.

Assuming that you know the basic elements of the Omnis Studio development
environment, like the Browser and the Component store, it is time to look
closer at the elements of the Studio application. In this article, we are
going to start explaining the structure of a Studio application.

Your application will link to a database, it will open windows to look at
and edit the data, and reports to print them. Maybe you want menus and
toolbars to navigate and control your application. These functions map well
to the main building blocks of Studio applications, which we refer to as
'classes'. Omnis Studio classes include windows, reports, menus, schemas,
tables and others. The following is a simple description of these building
blocks.

A class is the smallest self-contained unit in an application. You build
your application by designing a number of these classes, set their
attributes, and program the interaction and dependencies between them. Once
you have the basic idea about the purpose of the various types of class, you
will be able to decide on the appropriate structure of your application.

Each type of class has a distinct purpose and a basic set of features which
you will then expand upon to build the specific logic for your application.
For example:
* A window class is designed to be opened on screen so that the user can see
and enter data, and otherwise interact with the application.
* A table class holds basic logic to interact with your database server, log
on to it, select and fetch or update data.
These differences in purpose are what make the class types unique. Examples
of the distinctions are:
* Visual versus non visual: Some classes have a visual interface. Window
classes open as a visual area on screen, a menu installs on the menu bar, a
remote form displays inside your web browser. A report may display its
result either on screen or on a printer.
* Smart versus dumb: Some classes contain logic that may be invoked in
different ways, e.g. as a result of a user action. This logic is stored in
objects known as methods. Other classes are just definitions and depend on
others for action.

Let us list all the class types, with a brief description. Later when we
start using each class in our application, we shall look at them in more
detail. An easy grouping would be splitting them in three categories:
Definition classes, visual classes and non visual classes. Here they are:

-- Definition classes: -- these hold column definitions for our databases
and are used by other classes to format the data to match our database
tables. The definition classes are:

* Schema classes. These hold the column definitions for a (SQL) database
table. The schemas therefore are the representation inside your application
of the database structure. Schemas hold the table name, and for each column,
name, column type and primary key information.

* Query classes. The query class lets you combine two or more schemas with
an SQL statement to join these classes, for example, an employee record with
the company record.

* File classes. File classes contain the column definitions for tables
(called files) in the native Omnis database, and index information for these
columns. Generally, the exercises in this newsletter will be SQL based and
we shall not be using file classes.

* Search classes. The odd one out, the search class lets you define and
reuse complex search criteria, especially for use with the native Omnis
database. For our SQL exercises we shall use inline searches instead.

-- Visual classes: -- these are classes that have a visual element, that
appear on screen. All visual classes have variables, methods and other
properties. The visual classes are:

* Window classes. Windows are used inside applications to display data to
the user, prompt the user for input or actions and allow them to navigate
and use the functionality of the application. Window classes can be designed
with various sizes and colors, and can contain fields and buttons. Windows
can be "nested" inside other windows. The window and each control (field,
button, etc.) inside it can hold methods.

* Remote forms. Remote forms are equivalent to window classes, but are
designed to be used with the Omnis Web Client inside web browsers. Some
methods can be executed locally, some have to be sent to the server.

* Toolbar classes. Toolbars hold icons (usually buttons) that sit beneath
the menu line or window titlebar in many applications. Selecting one
triggers a method either within the toolbar or inside another object.

* Menu classes. A menu class represents a pull down, pop up, or context menu
in your application, and contains a number of menu lines. Selecting one
triggers a method either within the menu or inside another object.

* Report classes. The report is special in that it doesn't have to appear on
screen, and it can appear in many shapes and forms. Where the other visual
classes appear on screen only, the report can be sent to screen, but also to
a printer, to a port, to disk. Omnis reports are section based.

-- Non visual classes: -- Non visual classes contain logic and variables
just like the visual classes, but have no visual part. Instead they "live"
in the background and perform various services for the visual classes or
even for each other. They are:

* Table classes: Table classes hold built in and user defined methods,
usually methods that interact with the database server. A table class is
linked to a schema or query, which means that it knows the structure of the
database table(s).

* Object classes: An object class is a set of methods that can be used by
other parts of the application. The methods will usually be related to the
others within the object, and may be subroutines or functions. An Object
class can be both the "master", controlling the opening of windows and
printing of reports, and the "slave", doing what it is instructed by the
calling class.

* Task classes: A task is a logical container for related class instances.
It allows you to create a logical level between your application and the
individual class. (Note: You can also create physically separated
application parts, by splitting your classes into separate files on disk,
called libraries.) For most small scale applications, a single task is
enough.

* Remote tasks: The remote task is used by the Omnis server in a web
environment. A remote task instance will be created for each user session
with the server.

* Code classes: A code class is a global code container. In a coming issue
of the technical newsletter we shall discuss the differences between code
and object classes, as well as the other non-visual classes, and why - in
this authors opinion - code classes have no place in a properly structured
application.

Now you know the basic purpose and attributes of each class type in Omnis
Studio. Later in this newsletter we shall start using these building blocks
to make a real application, by defining schemas to hold our data structure,
tables to hold the logic, windows and menus and reports for local
applications, and remote forms for web based ones. By then when the task at
hand calls for a web client interface to your data, you will hopefully reach
for the remote form.

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

About Omnis Training

Raining Data, the creator and distributor of Omnis Studio, provides hands-on
training for all levels of Omnis developer, from beginners to experienced
users. All courses feature small class sizes, experienced instructors with
real world Omnis experience, personal attention from the instructor, a
separate workstation for each student and lab sessions for hands-on
learning.

Training is available at a number of locations globally, however, if you
cannot get to a training venue than we can negotiate bringing the training
to you. For more details about Omnis training, go to: www.omnis.net/training


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

Matters of Styles
By David Swain, Polymath Business Systems Inc
Email: dataguru@polymath-bus-sys.com
Web: www.polymath-bus-sys.com

Omnis Studio is engineered to work in a multi-platform world. It not only
creates binary-compatible library and data files, but it deals with other
issues of cross-platform compatibility - including web deployment - in a
very elegant way.

A Font of Problems:
One of the biggest obstacles to cross-platform development is the font
issue. That is, different platforms differentiate themselves partly by using
different sets of typefaces as their "standard" look, and many of those
fonts are not even available on the other platforms.

The traditional approach, still used by most software manufacturers today,
is to ship sets of fonts for the "other" platform to mimic those used as
standard on the "base" platform. Omnis was among the first programs to have
such "cross-platform fonts" available. Many years ago, an Omnis development
company named AccuWare created a set of fonts for Windows that emulated the
Chicago, Monaco and Geneva fonts from the Macintosh platform (and added a
Password font as well). A few years later, Omnis developed its own set of
such fonts. While this allowed Omnis developers to deploy solutions on the
Windows platform that looked exactly like their solutions on Mac OS, those
solutions did not have the "standard" look of Windows applications. Omnis
applications developed on Windows with the "standard" look had similar
problems when deployed on a Mac.

Tangled in the Web:
This issue was mainly a problem for those of us trying to sell custom
cross-platform applications based upon an interpreting engine, so it really
didn't get much attention from the rest of the programming world for many
years. Two relatively recent developments have made this an issue of more
general concern: the blossoming of the web and the prevalent use of .pdf
files for deploying cross-platform documents. Although web browsers will
make their own font choices by default, web designers want more control over
the typographic look and platform-to-platform consistency of the content
they design. The same goes for people disseminating documents in .pdf
format.

Recently Microsoft developed an extensive set of cross-platform screen fonts
to address this issue and made them freely available on their web site. This
past month Adobe Systems announced their Open Type standard that allows the
same font files to be deployed on all platforms - and offered an initial set
of such font families for sale.

While these approaches may be fine for documents, applications (including
those written using products like Omnis Studio) are still expected to
reflect the standards of the platforms on which they appear. This goes for
both workstation-based and web-based applications.

Solving It with Styles:
Omnis Studio has a different and very diplomatic way around this problem.
Why not let each platform use its own preferred set of typefaces for
specific jobs? The way this is implemented in Omnis Studio is with the use
of fieldstyles.

A fieldstyle is a predefined set of text characteristics that can be applied
to an object containing text, such as a field or button. This object can be
on a window, a report or a remote form. (Text in menus and toolbars
automatically take on the appropriate font for the host operating system.)

Fieldstyles are similar to paragraph styles used in word processing or
desktop publishing applications. They are used to specify certain text
characteristics for an object. Once such styles have been assigned to
objects, changes to a style's definition are automatically applied to all
objects using that style.

Unlike paragraph styles, though, the attributes imposed on an object by a
fieldstyle cannot be overridden. Omnis Studio also allows, in fact it
requires, us to define the specific characteristics on a
platform-by-platform basis. An examination of how fieldstyles are set up and
used will clarify this.

The #STYLES System Table:
The fieldstyles for a library are stored in a system table named #STYLES. If
you are new to Omnis Studio, you may not yet have encountered a system
table, so you might want to print out this newsletter and work through these
exercises. The first exercise is to make the system tables visible.

Exercise 1: View system tables in a library

1. Open Omnis Studio and create a new library. (You can open an existing one
instead if you wish.)
2. Double-click on the library icon to open the Class Browser.
3. From the View menu in the Class Browser window, select the "Browser
Options..." item. This will open the Browser Options window, which shows
which class types are visible in the Class Browser. When Omnis Studio is
first opened, system tables are not visible by default. If you had never
opened this window, this should still be the case.
4. Check the checkbox for "system table", then click the OK button to accept
your change and close the window.
5. The Class Browser should now display a number of new items with a
different icon (if you are using the icon view of the browser window). These
are the system tables for this library. The one we are interested in is
named #STYLES.

Our next task is to examine what a fieldstyle looks like and what options it
has.

Examining Fieldstyle Options:
We can only use a fieldstyle effectively if we understand what it does. To
do so we must open the #STYLES system table. Let's see what Omnis Studio
gives us by default.

Exercise 2: Examining fieldstyle options

1. Open the #STYLES system table by double-clicking on it. (Yours may show
different default styles.)
2. Select the style named "OMNISbutton" in the list labeled Styles.
3. Notice that there are four items in the list labeled Platforms (in
version Studio 3.0). Select the item named "All platforms" in this list if
it is not already selected.
4. Open the Property Manager using the F6 key or by selecting View>Property
Manager from the main Omnis Studio menu. As with other items in an Omnis
Studio library, we use the Property Manager to examine and assign property
values. The properties for the "All platforms" aspect of the "OMNISbutton"
fieldstyle will appear. This is where we determine which text attributes the
fieldstyle will control.
5. Notice that there are five properties whose names begin with "has". These
properties determine which text properties are imposed by the fieldstyle.
Properties whose value is set to kTrue are the ones that are in force. In
OMNISbutton, three text properties are imposed: fontname, fontsize and
fontstyle. Alignment and textcolor are free to be assigned on a case-by-case
basis.
6. In the Styles window, click on the Platform item labeled kMSWindows, then
click on the "Text" tab in the Property Manager window. Since only three of
the properties shown are set to be imposed by the "All platforms" property
set, these are the only ones we need to be concerned with in the
platform-specific views. Here we see that for the Windows platform, this
fieldstyle will impose "MS Sans Serif 9 plain" when assigned to an object.
7. Now click on the "kMacintosh" Platform item in the Styles window. The
Property Manager shows that items using the OMNISbutton fieldstyle will
appear as "Geneva 10 bold" when viewed on a Macintosh computer.
8. Now click on the "kUnix" Platform item in the Styles window. The Property
Manager shows that items using the OMNISbutton fieldstyle will appear as
"Adobe Helvetica 9 plain " when viewed on the Linux platform.

Notice how we can work with font information for platforms other than the
one on which we are currently running. Now let's see how we set up a
fieldstyle.

Creating New Fieldstyles:
We can create fieldstyles for any purpose in our Omnis Studio applications.
We may have fieldstyles for entry fields, list fields, labels, emphatic
text, or anything else we might require. It is best to name a fieldstyle in
such a way that its intended purpose is clear. Here are the steps we follow
to create a new fieldstyle. Let's make one for entry fields on a window.

Exercise 3: Creating a new fieldstyle

1. Click in the empty box under the name of the last fieldstyle in the
Styles list of the Styles window (open #STYLES as above) and type the name
"myEntry".
2. Include a brief description in the next column if you wish.
3. Select "All platforms" in the "Platforms" list and open the Property
Manager.
4. Set the hasfontname and hasfontsize properties to kTrue. (Set all other
Boolean properties to kFalse. This allows us to set style, alignment and
textcolor as necessary for each field.)
5. Select "kMSWindows" in the "Platforms" list of the Styles window, then
select the Text tab in the Property Manager window.
6. Specify "Arial" for the fontname property and "8" for the fontsize
property. The one caveat here is that we must spell the name of each font
exactly as is required for the target platform.
7. Select "kMacintosh" in the "Platforms" list of the Styles window, then
specify "Geneva" for the fontname property and "9" for the fontsize
property.
8. Select "kUnix" in the "Platforms" list of the Styles window, then specify
"-adobe-helvetica" for the fontname property and "9" for the fontsize
property.
9. When finished, click the OK button on the window to close it.

We now have a fieldstyle intended for use with window entry fields that is
appropriately defined for all platforms Omnis Studio 3.0 supports. This is
only the first step in the process, however, since a fieldstyle does us no
good unless we apply it to a text-bearing object.

Applying Fieldstyles to Objects:
Let's go back to our library and create a simple window to test our new
fieldstyle.

Exercise 4: Applying a fieldstyle

1. Create a window class named "styleTest". Do this by opening the Class
Browser for our library, selecting Class>New>Window from that window's menu
bar, and naming the resulting class "styleTest'. It will then appear in the
Class Browser. Double-click on the window to open it in design mode.
2. Drag two Single Line Edit fields to the Window from the Component Store;
edit fields are the second button labeled 'Entry' in the Component Store.
3. Select the first field and open the Text pane of the Property Manager to
view its text properties.
4. Click in the fieldstyle property box and drop down the list. Since each
style is stored in our library and has definitions for all platforms, this
list will be the same no matter which platform we use for development.
5. Select the "myEntry" item from the list. Notice how the font and fontsize
properties were changed to match what we had specified for this platform in
the definition stored in #STYLES and that these two properties are greyed
out and unavailable for modification. Since our fieldstyle only has two "All
platforms" properties, hasfontname and hasfontsize, set to kTrue, these are
the only text properties influenced by our fieldstyle selection.
6. Fieldstyles can be set for multiple object simultaneously. If multiple
objects on the current class are selected, they can be given the same
fieldstyle property value in one move if they all have this property. Select
both of the Single Line Edit fields we placed on our window earlier. Now go
to the Text pane of the Property Manager window and select the "myEntry"
fieldstyle. Examining this property for each field individually will confirm
that the property was set for both at the same time.

Fieldstyles are really easy to set up and use, and they're great for
cross-platform consistency. But what if we need to make changes? Fieldstyles
give us an advantage here too.

Modifying Existing Fieldstyles:
Fieldstyles offer another benefit to those who use them. As with paragraph
styles in a word processing or desktop publishing document, changing a style
automatically applies that change to all items using that style. Let's
perform a quick test of this.

Exercise 5: Modifying a fieldstyle

1. Open the #STYLES system table and select our "myEntry" fieldstyle.
2. Change the Windows fontsize property to 10 point and the Macintosh and
Linux fontsize property to 12 point.
3. Click the OK button to accept the changes and close the window.
4. Now open the "styleTest" window and select one of the field object placed
on it.
5. Examine the text properties for this field. Notice that the change for
the platform on which you are working has been applied to the object.

This short exercise demonstrates one of the most powerful reasons for using
fieldstyles. It is just a matter of deciding on a set of fieldstyles that
meets the needs of all text-bearing objects in an application, then building
them.

A Few Suggestions of Styles to Create:
While I can't possibly anticipate all your detailed future needs here, I can
at least provide a few general suggestions.

entryField: For normal entry fields as well as masked and multiline entry
fields
listDisplay: All list types except list boxes used to display multiple
columns
listMonospace: List boxes used to display multiple columns (if you prefer
not to use headed list boxes)
label: Normal label and text objects
title: Label and text objects used in a heading capacity
pushbutton: Pushbutton objects and other controls
radio/checkbox: Used if these are to have a different look than a pushbutton

Additional fieldstyles for basic report, window, and remote form objects are
also advisable. There may be some differences among the interface standards
you choose for these three areas. For example, you may wish to use
Postscript or TrueType fonts on a report while using simple screen fonts on
a window or remote form.

It is also wise to consider what fonts will be available on the end users'
computers. If you are creating an application strictly for in-house use in
your or a client's company where you have control over what fonts are
installed on each machine, you can choose anything you like. However, if you
are building an application for sale to a broad base of users or for
deployment to the web, it is safest to stick with standard fonts for the
various platforms.

Once you have an ultimate set of fieldstyles designed and implemented in a
library, you then need to find a way of including them in other Omnis Studio
projects without having to build them anew for each library.

Moving Styles to Other Libraries:
As with any class, Omnis Studio lets us copy #STYLES to other libraries with
a simple drag-and-drop between the Class Browsers of the two libraries. If
you are moving a class from one library to another and the components of
that class use styles, a little preparation will save you a lot of work. Be
sure to either move the #STYLES system table from the source library to the
destination library or at least determine that all styles required by the
class already exist in the destination library (with the same name and
properties). If you do not, the fieldstyle property will be empty for all
objects in the copied class that can't find their proper fieldstyle.

Styles and the Component Store:
One important library to which we might want to move our prized set of
fieldstyle definitions is the Component Library. This is the perfect
repository from which to drag our #STYLES system table. The #STYLES system
table in the Component Library does not act as an automatic default set of
fieldstyles.

Another reason for doing this is that we can then assign fieldstyles to
default design objects for windows, reports and remote forms. As long as we
retrieve #STYLES into a new library before creating these class types, the
components we place on them from the Component Store will already be
"styled" saving us a significant amount of work. Here is how we open the
Component Library and perform these tasks:

Exercise 6: Working with fieldstyles in the Component Library

1. Open the Component Store and select "Show Comp Library In Browser" from
its context menu.
2. Bring the Library Browser to the front, showing the Component Library.
3. Drag the #STYLES system table from the normal library to the Component
Library. This makes the fieldstyles we just created available to the items
we can retrieve from the Component Store. Since a #STYLES system table
already exists in the Component Library, you need to overwrite it by
clicking the "YES" button when prompted.
4. Open the Component Library by double-clicking on it. This allows us to
view the classes it contains.
5. Scroll down to the window class named "_Field Components" and open it by
double-clicking its icon.
6. Locate and select the pushbutton object and assign "OMNISbutton" to its
fieldstyle property using the Property Manager.
7. Now close the class and the Class Browser, then toggle off the "Show
Component Library In Browser" item from the Component Store context menu.
8. Create a new window class in your test library, open it and drag a
pushbutton field to the class editor from the Component Store.
9. Examine the fieldstyle property of the pushbutton object. It should read
"OMNISbutton".

Applying fieldstyles to default design objects in this manner can save hours
of repetitive work in the long run. Give careful consideration to which
fieldstyles you will need in your work and which of these is the most
appropriate default for the many text-bearing components Omnis Studio
offers.

Using Notation with Styles:
As with all other aspects of an Omnis Studio library, we can access
information about fieldstyles and their use with the Omnis Notation. Here
are some quick exercises to illustrate this:

Exercise 7: Notationally accessing the fieldstyles themselves

1. Open the Notation Inspector, found in the View menu on the main Omnis
Studio menu bar. We will use this to locate our fieldstyles in the Omnis
Studio object tree.
2. Fieldstyles belong to a specific library, so we must drill down through
$libs to the target library and then to the $fieldstyles group. You can
drill all the way down through the $platforms group of our "myEntry"
fieldstyle. Notice how the full notational reference to the selected item in
the Inspector is shown in the status bar at the bottom of that window.
3. Working along with the Property Manager, notice that the $has...
properties are properties of the fieldstyle itself while the text properties
for a specific platform must be accessed by drilling down through the
$platforms group to that specific platform.

If it were ever necessary to notationally access a fieldstyle or any of its
properties in code, such things can be dragged from the Notation Inspector
or the Property Manager (when used in conjunction with the Notation
Inspector) to any text field in the Method Editor. However, you should be
aware that the #STYLES system table (in fact this applies to all the system
tables) is not instantiable, so making a change to it is immediately stored
in the library as a global change. For this reason, it is unlikely that you
will modify these items in this way. It is much easier to simply open
#STYLES than it is to write code to do the same job.

On the other hand, it may be possible that you will want to change the
fieldstyle for one or a number of objects on some instance within your
application. Here is an exercise to explore how this might be done:

Exercise 8: Selecting and applying a fieldstyle from a list

1. Create a new window named "styleSelector".
2. Double-click on the window to open the Method Editor. Once there, create
two instance variables with the following attributes:

Name               Datatype
styleList          List
text               Character 20

3. Put the following code in the $construct method:

Calculate styleList as $clib.$fieldstyles.$makelist($ref.$name)
; to enter this command select the Calculate command, enter the Field name
as 'styleList' and the calculation as
'$clib.$fieldstyles.$makelist($ref.$name)' without the quotes
Do styleList.$search($ref.C1=$cinst.$objs.target.$fieldstyle,kTrue,
kFalse,kFalse,kFalse)
Calculate text as 'Text to test'

Note: We can refer directly to a column in a list by its column number (C1)
without having a name for the column. Also, the additional search parameters
used above make certain that the selected line becomes the current one so
the initial fieldstyle of our target field is displayed in our dropdown list
on opening the window.

4. Place a dropdown list and an entry field on this window. Name the
dropdown list field "styles" and the entry field "target", then set the
following properties for them:

For styles
dataname: styleList

For target
dataname: text
fieldstyle: myEntry (under the Text tab)

5. Put the following code in the $event method of the field named "styles":

On evClick
 Calculate $cinst.$objs.target.$fieldstyle as styleList.C1
 Calculate $cinst.$objs.target.$fontstyle as kPlain

Note: We set the fontstyle to kPlain as it is overridden by some of our
fieldstyles but not others. Doing this gives us more of a visual difference
when switching from one to the other in this example.

6. Now open the window in test mode by closing the method Editor and typing
Ctrl/Cmnd-T. Notice how selecting a fieldstyle name from the dropdown list
changes the fieldstyle property of the text field.

This specific example probably doesn't have a practical use, but the code
line that sets the fieldstyle property of our entry field is the key
element. We can cast this in either of two ways:

Calculate $cinst.$objs.target.$fieldstyle as name of style

or

Do $cinst.$objs.target.$fieldstyle.$assign(name of style)

Either technique is equally correct for assigning a value to a property.

Future Trends:
The addition of the Mac OS X operating system to the list supported by Omnis
Studio in version 3.1 will add a few new wrinkles to fieldstyles. Mac OS X
introduces the concepts of "themes", "theme fonts" and other items that will
have to be accommodated by the fieldstyles mechanism in Omnis Studio.
Fieldstyles will then come even closer to being the interface design rules
for an Omnis Studio application.


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

About Omduit, the 'out-of-the-office' data management tool

Raining Data is pleased to announce the availability of Omduit, the plug-in
that lets you interface your Omnis application with any Palm OS(r)
compatible handheld device. The Omduit plug-in, for Omnis Studio 3.0 or
above, allows you to transfer data from your Omnis application, whether
stored on a server or Omnis database, to your Palm handheld device via the
HotSync(r) function. This means you can mobilize your data from your Oracle,
Sybase, DB2, or Informix server database, as well as any ODBC-compliant
databases such as MySQL and MS SQL. This data can then be altered and
uploaded back to your Omnis application database, allowing the
synchronization of data to and from your Palm handheld device and Omnis
Studio solution.

For further details about Omduit, please go to: www.omnis.net/omduit


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

I hope you've found this second 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 Tech 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 2001. 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