Misc

$hscroll & $vscroll

Various window objects allow you to show a vertical and/or horizontal scrollbar. The properties associated with this capability are $horzscroll and $vertscroll. Setting them to kTrue or kFalse shows or hides the particular scrollbar.

If the user scrolls the object an evHScroll or evVScroll $event message is sent to the object.

The $hscroll and $vscroll properties return an integer value telling you how far the user has scrolled. The integer value is a ratio of 1:8 pixel units. To convert the $hscroll or $vscroll property to pixels use the following calculation:

Calculate Pixels as 8*(ScrollableObjRef.$hscroll-1)
Calculate Pixels as 8*(ScrollableObjRef.$vscroll-1)

Cross-Platform Modifier Keys

Display ASCII Characters

Fonts, Field Styles, #STYLES

If you look in the System Classes folder of any libary you will see a #STYLES class and a series of #W*FONTS and #M*FONTS classes.

The Omnis Studio help states that #STYLES supercedes #W*FONTS, #M*FONTS. #STYLES is better because it not only allows you to specify different fonts for different platforms, but it also gives you full control over font size, font style, etc.

Once a style is declared and used in your library, any text which is assigned $fieldstyle is mapped to the row # in the #STYLES table, not the style name! If you change a style name in the table, the style name of all the text in your library which is mapped to that row will immediately change its $fieldstyle name to match the #STYLES style name. (Try it, it's harmless to do, just be sure to change it back.)

If a text related object with a $fieldstyle is copied into your library, Omnis Studio tries to match its name to the existing styles in the #STYLES table, if it finds a match, the $fieldstyle is then mapped to that row. If it doesn't find a matching style, Omnis Studio automatically adds the new style to the next available line in the #STYLES table.

If you don't have any styles in your library, your styles table will be built in the order that you drag components in. For example if you have an empty #STYLES tables in Library A and B. In Libary A and you first drag in a button object, #STYLES row 1 will be CtrlPushButton. In Library B you drag in an entry field first, row 1 will be CtrlEditText. As you can see, that can get messy if you decide later decide you want the same #STYLES table in all your libraries and you drag a brand new #STYLES class table into your library. If you drag #STYLES from Library A to Library B, the field styles which were mapped to #STYLE row 1, will still be mapped to #STYLE row 1. The $fieldstyles in your library are mapped to the row #, not the name!

To set up custom field styles:

1. F2 Browser and select the System Classes folder of a library.
2. Double-click on the #STYLES class to open the Styles window.
3. The interface is intuitive and the Omnis documentation is clear, so I won't get into more detail.

For each style you can control the properties for All platforms, kMSWindow, kMacintosh (OS9), kUnix (Linux), and kMacOSX.

For any $has... property you set to kTrue in All platforms, the specified property can not be changed at the field level. If the styles says the $textcolor is kBlue and the $hastextcolor setting is set to kTrue, you won't be able to change the $textcolor property for that $fieldstyle at the field level. Change $hastextcolor to kFalse in the #STYLES class for the style, will allow you to change the default $textcolor at the field level.

I recommend that you create your own field styles in the #STYLES class for any special text you want to consistent cross-platform control of the font size and style. Here are some hints when you are doing this:

1. Think through and set up your #STYLES table very early in developing your application. Otherwise you'll be going back doing a lot of extra clean up work later on.
2. Don't use font names for your style names.
3. Set up separate styles for window classes and for report classes. Fonts that work well for window classes, don't necessarily work well for reports, so keep them separate.
4. Don't get carried away and declare more styles than you need.
5. Only enforce color or justification on a style if you are sure about the need to control the color or justification.
6. Use a consistent prefixes for your custom styles. e.g. Prefix all report styles with rprt. This makes it easier to enter the $fieldstyle in design mode with the notation helper.

Here are some field styles to consider for reports:

1. rprtText - regular report text (Mac/Win:Helvetica 10)
2. rprtCorrespText - report text for correspondence (Mac/Win:Times New Roman 12)
3. rprtSmallText - report text for tiny header or footer text (Mac/Win:Helvetica 6)
4. rprtTitle - report text for report titles (Mac/Win:Helvetica 12 Bold)
5. rprtSubtitle - report text for for the subtitles (Mac/Win:Helvetica 10)
6. rprtCompanyName - report text in the style that best suits the company (Mac/Win:Helvetica 12 Bold?)
7. rprtSpacer - red report spacer (Red color makes spacer fields stand out on the report)
8. rprtMicroSpacer - red report spacer (Mac/Win:Helvetica 3)

StudioTips Documentation - Copyright 2006 Vencor Software