SQL Meta-Data

The schema classes in Omnis are used to map list and row variables in your application to the SQL database. Each schema class is mapped to a database table and the schema class columns are mapped to database table's columns.

The Omnis schema classes keeps track of the column name, datatype, whether on not the column is a primary key column, and whether or not null values are allowed. However, the Omnis schema classes are not able to keep track of whether or not the column is indexed, if it is a foriegn key and if so what table and column the foreign key references, and other column constraints.

The StudioWorks SQL Meta-Data Editor allows you to store addition information (meta-data) about each schema class column. The meta-data is kept in a row variable which is stored in the $userinfo of each schema class column.

Database Administrator

Setting up and keeping your database in sync with your Studio application can be a lot work. The Database Administrator tool makes it easy. Using the SQL meta-data the Database Administrator can intelligently add tables, add columns, alter column datatypes, add indexes, add primary and foreign keys, set constraints, and collations.

Sign In Window

StudioWorks provides you with a prebuilt Sign-In (Logon) window.

The code that is included with the Sign-In window supports using the DBMS users security as well as the list of application users which you store a table in the database. The application users table is where you would store the user's formal name, group memberships, user security settings, email address, etc.

Sessions Manager

Getting the session settings correct for different DBMS back ends can be difficult for developers, let alone end users. The StudioWorks Session Manager assists both developers and end users.

Templates are provided for each DAM with text explaining what information to fill in which field. If the Omnis DAM is select the fields which don't apply are hidden and the host name field is resized accordingly.

Concretizer

StudioWorks reduces development and maintenance time by generating window instances on the fly based on the SQL meta-data. Lists, entry files, labels, and tooltips are added to windows the instance they are opened.

The disadvantage of generating window instances on the fly is that window instantiation time suffers. There is a performance hit which the user experiences. To overcome this the Concretizer creates 'concrete window classes' for each of the window instances. Prior to releasing a runtime version you 'runtimize' the window instances. The runtimized window classes are put in a separate library which is then released with the development libraries. If a runtimized class is available it will be used.

Error Handler

Object-oriented programming places code in visual and non-visual classes. Visual classes are windows, menus, toolbars, reports, and remote forms. Non-visual classes are table classe, object classes, and task classes. By making a clear separation between visual and non-visual classes your classes can be much more reuseable. Non-visual classes used by a window class can also be used by a remote form, or even a web page that communicaes with a remote task. Non-visual classes can not have prompts, okay messages, working messages, or error messages. The dilema we run into is what to do inside a non-visual class method when it hits an error. How can it easily communicate the error back to the visual class that called the method in the non-visual class. The call quite often will have been passed through several different methods.

One solution is to develop a large series of error codes and return the appropriate error code back to sender, however developing and remembering a table of error codes is a lot of work to create and maintain. And how do pass an error code back to a method which is expecting a list or a result value?

The solution to all of this in StudioWorks is the error handler object. The error handler sits on the sidelines waiting for any method to log an error. The first parameter sent the log message is a reference to the method where the error occurred. Additionally the error message text, optional details, and an optional error code are sent by the method where the error occurred. The method where the error occured return false or null as may be appropriate to its sender. The error handler immediately writes the error to a log file and stores the error in a list. When the visual object where the request originated receives a returned false or null value it sends a message to the error handler asking it for the last error which was logged. The visual object then prompts the user with the error or makes an appropriate decision based on the error code.

Icons Browser

Finding the icon you need in the Omnis icons can be tedious and time consuming. Keeping track of icons you create or trying to share icons among different libraries is a hassle. Remembering the icon by its number isn't much fun.

The StudioWorks Icons Browers solves all of the above.

The icons are stored in a single library. You assign a name and number to each icon. You can also assign search words and synonyms in a search list. When you need to find an icon, you open the Icons Browser, enter a search word, and hit return. The Icons Browser displays a list of icons which march or are related to your search word.

An icons object in the StudioWorks icons library can be instantiated by any of your application's libraries. You can ask the icons object to return to you the iconid of any named icon.

Do oIcon.$retIconID('BookPencil') Returns IconID ;; The iconid 2143 will be returned.

Preferences

Most applications need to store various user preferences on the local client computer. It make for a nicer user experience if your application remembers the last user ID, the last session settings, the last language, etc. when the user reopens your application.

The StudioWorks preferences object provides you with this functionality. You simply add the preferences you wish to store on the local client computer to the preferences schema list definition. StudioWorks adds the appropriate getter and setter methods to the preferences object. When you close your application StudioWorks looks for a local preferences Omnis data file, and if necessary creates it, and then saves the preference values to the file. When you reopen your application StudioWorks loads the preferences from the local Omnis data file into the preferences object where they can easily be access by the your application code.

Prompts

The built in OK, Yes/No, No/Yes, Prompt for input prompts which come with Omnis Studio are a bit behind the times. With a 255 character limit your messages are often truncated. If you want to prompt the user with list, radio buttons, check boxes, mutliple inputs... you have to create your own prompt windows.

StudioWorks version 4 has flexible prompt window which supports unlimited length text message, an option for including additonal message details in small text, list prompts, any mix of radio buttons, check boxes, and multiple inputs in a single prompt. Often used prompts such as Delete Record? or Save Changes? are already built for you and designed to look good on multiple platforms.

The above prompt was opened with the following line of code:

References Module

Often times in application development you need a simple lookup with optional or mandatory values which the user can enter in a field. (e.g. Mr, Ms, Mrs, Dr, Lord, Duke,...) Hard coding these into your application is not a a good idea. Creating a table in your database for each of these is overkill.

Another scenario is that you might need a counter to keep track of the last purchase order, last invoice number, last customer ID, or last primary key assigned in each table.

The References module is the solution for these and many more situations.

You simply declare a unique group/subgroup combination of values (e.g. PO/PONum), a datatype (integer), and a reference type (counter). When you need the next PO number you simply an appropriate message to the references object:

Do refs.$retNextNum('PO','PONum') Returns NextPO

or for a lookup list of name titles

Do refs.$retLookupList('NameTitles','UK') Returns UKNameTitlesList

Report Builder

Making end user reports can be a time consuming job. Adding fields to a report class, positioning, sizing, and setting the field properties, adding report titles and column headings... use up your valuable time doing rather low level work. Time better spent elsewhere.

The report builder object is able to generate reports on the fly for you. The StudioWorks Report Builder creates a report class and based the SQL meta-data of the schema or query class used to fetch the report records it adds the fields, labels, and titles to the report class and then prints the report. The developer can further customize the report class after it has been generated by the report builder.

Security

Most applications require some form of security. Control over which users can access which windows and what reports. Which users can view, edit, insert, or delete records in which tables. If the DBMS supports grant and revoke privileges keeping your application's users in sync with the database privileges can be a lot work.

Administering security on a user by user basis can be time consuming and require constant updating. Being able to put users into groups and then administernig security on a group by group basis is simpler and more practical.

The StudioWorks Security Manager helps out with all of the above. Users can be added to groups. Both users and groups can be assigned schema class, window instance, and report instance privileges. The schema class privileges can be synchronized with the database. Users who are members of multiple groups are given the highest level of authority for each schema, window, and report for the summary of all the groups they are in.

The Security Manager window provides you with simple user interface and can be instantiated as a subwindow in one of your own window classes.

Report instance security and DBMS synchronization is not yet implemented as of 2005-04-20.

String Tables

If now or at some point in time you wish to sell your application in another county, or even different region of one country, you'll need to be translate the labels, tooltips, column headings, menus, and window titles throughout your application. This can be a huge job.

StudioWorks utilizes OMST's string tables for the labels, tooltips, column headings, menus, and wnidow titles. For the first language you develop the text is stored in the SQL meta-data.

When it comes time to translate your application to another language you simply export all of the string table IDs and the current language text to a tab delimited file. The translator simply needs to add a column for each additional language and enter the translated text in that column. The file with the additional columns of translated text is added to the startupsettings folder and loaded by StudioWorks during startup.

StudioWorks Documentation - Copyright 2005 Vencor Software