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

Enter data for Modal Windows

The Enter data command puts Omnis into enter data mode which allows data to be entered via the current window.

By default, the Enter data command waits for an evOK or evCancel event. When these events are triggered enter data mode is terminated (assuming the window is not in modeless enter data mode). However you can include a termination condition with Enter data which causes enter data mode to continue until the expression becomes true.

I often ran into trouble when trying to control Enter data with custom modal prompt windows. I might be executing a method and open a modal custom prompt window with several entry fields and halt method executing with an Enter data command. Behind the window I'd have some code that checked to make sure the user entered correct data and if not discard the evOK event, keep the prompt window open and tell the user what they did wrong. Inevitably an evOK would somehow sneak by and Enter data would be terminated before I wanted it to thereby allowing code execution to continue in the halted method.

Another developer (Jean-Marc Azerad) explained to me how he uses the termination condition to control enter data mode. You can preset a numeric task variable or a global variable to -1, set a termination condition in the enter data where the variable has to be >=0, then open the modal prompt window. Code execution will not continue after the Enter data command in your method until you set the variable to >=0. Brilliant!

; Open a modal prompt window
Open window instance wModelPrompt

; Halt method execution of the method using the "Enter data' command.
; Set the "Termination condition" of enter data to #59>=0

; Preset #59 to negative 1
Calculate #59 as -1

; In our modal window we could set #59 as follows: 0=Error, 1=Cancel (no error), 2=Okay Continue
Enter data until #59>=0
If #59=0
   OK message Controlling Enter Data (Icon) {#59=[#59] - Error}
Else If #59=1
   OK message Controlling Enter Data (Icon) {#59=[#59] - Stop (no error)}
Else If #59>1
   OK message Controlling Enter Data (Icon) {#59=[#59] - Continue (no error)}
End If

Close window instance wModelPrompt

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