StudioWorks Features

The following is an overview of the features in StudioWorks. This is not an all inclusive list of the features in StudioWorks.

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.


The StudioWorks SQL Meta-Data Editor not only stores database meta-data, it also stores GUI meta-data. The GUI meta-data allows you to preset if and how the column will be displayed in lists and entry fields, when and how users can edit the field, whether to include the field in prompts, default sorting, etc. Even the label, tooltip, and abbreviation (for list and report column headings), are stored with the GUI meta-data. Storing the label and tooltip text in the meta-data ensures that where ever the column is displayed in a window or on a report the label will be consistent and if it is used in several windows you only need to change it in a single location.

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.


In an ideal world the SQL92 standard would be the same for every DBMS, but unfortunately we aren't living in an ideal world. The SQL used to rename a column for one DBMS is not necessarily the same as the next. The database administrator is structured so that custom SQL can easily be added for each DBMS.

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.

The Sign-In window defaults to the last session. Users can change session settings.

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.


Session settings are automatically saved to the local preference data file.


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.


The Concretizer can also be used to create a developer window class that is mapped to a schema class or a query class. The developer simply selects the window instance in the Concretizer and clicks the Developerize button. A window class with all of the fields and labels is created in the same library as the schema or query class. The window class can then be modified by the developer.

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.

By making a clear distinction between visual and non-visual classes and using the StudioWorks error handler you are able to easily develop non-visual classes which can be used by different visual classes.

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.

The StudioWorks icons library makes it easy for StudioWorks members to add icons and share icons.


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.

The local preferences data file is stored away from your application to that reinstalling the application or updating it won't wipe out the user's preferences.


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:

Do prmpt.$promptSave('Save Changes?) Returns ButtonPressed

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

There's plenty more than you can do with the references library. Store user preferences for reports, user defined businesss rules, soft coded SQL query text for reports,... the list goes on and on.

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.

The column heading labels use the same text as the headed list heading which is all sources from the meta-data.


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.

End users can localize your StudioWorks application by changing labels and tooltips to suit their business. One business refers to 'clients', another calls them 'customers'. Localized labels and tooltips are stored directly in the customer's database and loaded during startup.