Latest Notes

The list below offers a sample of over 200 specific function points that made up the original MasterStudio requirements, which are now part of the product. Numerous features were added after this list was created. See the complete and detailed release notes and known issues.

MasterStudio comes with a comprehensive Developer Manual in PDF format. It is available as a free download.



75 MasterStudio Features

Intelligent Record Lists

MasterStudio includes an enhanced implementation of the revertible 'smart list' concept. Individual records have a backup that is completely accessible. Each list line also stores nested detail lists. List managers and record managers offer additional functionality, such as 'reverting' the list and individual records. State of individual records is cleanly indicated by an icon in the margin of complex grids.
Design pattern(s) implemented: Model-View-Controller
 
Refresh Method

Any unmodified record visible on the screen can be re-fetched from the database, either programmatically or from a context menu.

Update April 15, 2005: Each entity context menu has a "Refresh" option that allows users to refetch the latest record from the database. When using the "pessimistic record locking" option, records are even refreshed automatically when the user starts editing.
Design pattern(s) implemented: -  
 
Model includes a 'Default View'

After creating a schema class (including XML-formatted business rules), adding a <VIEW> tag to the primary key column description is all you need to do to open a ready-to-use and fully featured application window, containing the subwindow or complex grid that you draw. This dynamically links any view to your database model.
Design pattern(s) implemented: Model-View-Controller
 
Automatic Find Mode

Any MasterStudio database window supports a Find mode, in which users enter a 'query by example'. Non-enterable fields become enterable (and searchable) in Find mode. Developers and users control whether searches are case sensitive or not.
Design pattern(s) implemented: Model-View-Controller
 
Finding Master-Detail Relationships

In nested Master-Detail windows, users enter search criteria into Detail panes to find Master records that contain Details matching those criteria. MasterStudio even allows users to enter combinations of search criteria into Master fields and multiple Detail fields.
Design pattern(s) implemented: Model-View-Controller
 
Finding Ranges and Empty Fields

In Find mode, any database field can be searched for a range of values (from ... until) or for empty values. MasterStudio does this completely automatically.
Design pattern(s) implemented: Model-View-Controller
 
Result Set Limiting

MasterStudio prompts the user if there are more than a certain number of records available for fetching from the database, thus allowing the user to stop fetching if search criteria were too broad. Optionally, MasterStudio refuses to search if no search criteria were entered.
Design pattern(s) implemented: Model-View-Controller
 
Deferred Selecting

MasterStudio is smart enough to only perform database queries for active tab panes; queries for other tab panes are executed when the user clicks on them.

Update April 15, 2005: Developers have full control over whether "invisible" database entities are fetched from the database or not. When an entity is hidden in a tab or in a collapsed pane in a frameset, MasterStudio by default fetches the data when the corresponding views are revealed again.
Design pattern(s) implemented: Model-View-Controller
 
Enhanced Session Objects & Automatic Login Panels

MasterStudio session objects support the same methods that Omnis Studio™ version 3 session objects do. In addition, MasterStudio sessions support 'connection dictionaries' and 'login panels'. Connection dictionaries encapsulate login information (including user name, user password, database name or alias, database password, etc) so it can be transparently saved in the user's preferences. If a session doesn't have sufficient data to be able to logon to the database, it automatically opens an appropriate login panel when you call its $logon method. MasterStudio even gives you a complete session menu that allows users to log on, log off, or switch to a different database. MasterStudio sessions offer all the power of the 'non-visual DAMs' in addition to features inspired by Apple's Enterprise Objects™ database adapters.
Design pattern(s) implemented: Facade, Dictionary data structure
 
Session and Statement Objects for V2 DAMs

Although Omnis Studio™ 'version 3' or 'non-visual' DAMs are definitely 'the way to go', certain databases (including the built-in Omnis SQL database) work well with the old 'version 2' or 'Classic' DAMs. MasterStudio allows you to use your old database code (keeping the SQL: statement) while working with 'real' session objects and statement objects. You no longer need to worry about correct use of 'Set current session' or 'Set current cursor'. Thus, MasterStudio gives you the power of session objects and statements while maintaining connectivity through Classic DAMs as well as native V3 DAMs.

Update Oct. 21, 2003: Version 2 DAMs are no longer supported by the MasterStudio session superclass, since Raining Data have clearly indicated that they will be deprecated in the future. If you want, you can still use your own V2 database sessions, of course.
Design pattern(s) implemented: Adapter
 
Session Subscription Mechanism

Any object can subscribe to a session instance: When the user opens the object (such as a subwindow) it automatically asks the session to log on. If the session cannot be logged on, it automatically opens its login panel. If the user enters incorrect logon data or cancels the login panel, the original (sub)window refuses to open (in fact, the main window will not even open). As a developer, you no longer need to disable buttons or menu lines that require an active database session. When the user logs off from the database, any objects that have taken a subscription from that session will be notified. If any of those objects interrupts the log off process, then the session refuses to log off, too.
Design pattern(s) implemented: Foreign method
 
Session Database State Indicators

Windows register with their database session instances to automatically display database access state. During database operations, state icons of registered windows are redrawn automatically.
Design pattern(s) implemented: Model-View-Controller, Enumeration
 
Unique Record Number Generation

MasterStudio session objects include dedicated methods to generate unique record numbers for new records to be inserted into the database. For Omnis Studio™ native data files (Omnis SQL) or PostgreSQL, this uses a separate table. For Oracle, this uses native sequence objects (the name of which does not need to match the name of the primary key column).
Design pattern(s) implemented: -
 
Support for all Studio DAMs

MasterStudio includes superclasses for V3 (Non-Visual) Omnis Studio™ DAMs with concrete subclasses for Omnis native data file, Oracle, and PostgreSQL. Additional subclasses can easily be added.

Update July 29, 2005: MasterStudio's built-in session and statement objects no longer support V2 DAMs.

Update October 9, 2009: The FrontBase DAM is no longer actively supported by Master Object AB.
Design pattern(s) implemented: -
 
XML-formatted Business Rules for Database Columns

MasterStudio lets you add XML-formatted information to each schema class field (database column). Views (subwindow panes and grids) that use the corresponding database entity automatically adjust individual field styles (for entry fields, mandatory fields, display-only-fields), label texts (for multiple-language support), default sorting order, database locking, joins, etc. After changing the model, controller and view behavior changes automatically. MasterStudio automatically caches database rules for optimal performance when re-opening windows.

Update April 15, 2005: Information from XML elements is read from the schema class once and then fully cached in-memory for very high performance.
Design pattern(s) implemented: Model-View-Controller
 
Complex Joins between Schema Classes

You define joins between database tables by adding an XML tag to foreign keys in your schema classes. MasterStudio dynamically builds the corresponding SQL (including inner and outer joins, complex nested joins and recursive joins). Controllers that use your database entities (lists defined from a generic table superclass) automatically manage nested Master/Detail entity panes without any manual coding.

Update April 15, 2005: MasterStudio automatically checks the integrity of joined schemas.
Design pattern(s) implemented: Model-View-Controller
 
Recursive Joins

MasterStudio fully supports recursive and nested joins (with limitations imposed by the database used: Omnis SQL does not support this very well). A schema class can be joined to itself any number of times.

Update Oct. 21, 2003: MasterStudio supports nested and complex joins, only insofar this is supported by SQL on the database. OmnisSQL does not perform well for complex joins and only allows one outer join in a select statement. OmnisSQL only provides partial support for this feature.
Design pattern(s) implemented: -
 
Automatic Translation of Checkboxes and Radio Buttons

Labels for checkboxes and radio buttons are derived dynamically from XML tags in the schema class. Radio buttons texts include a separate string for the 'group'; checkboxes include a separate name to be used in tooltips.
Design pattern(s) implemented: Model-View-Controller
 
Record Locking

By default, MasterStudio uses 'optimistic record locking', where an 'update counter' is automatically incremented and compared before each update. MasterStudio is prepared for other locking schemes, for which separate subclasses need to be implemented.

Update April 15, 2005: MasterStudio also offers a "pessimistic record locking" option, where records are refetched and locked automatically when a user starts editing them, and unlocked after saving or canceling the modifications.
Design pattern(s) implemented: -
 
Support for Stored Procedures

Although MasterStudio will automatically create the appropriate SQL for $insert, $update and $delete, developers can subclass the table superclass and easily implement their own version. This includes the option of calling a stored procedure. MasterStudio automatically divides database actions for Master-Detail relationships into transactions (using Commit and Rollback for each Master record with all of its details: If saving a detail record fails, its Master record is rolled back as well).
Design pattern(s) implemented: Template methods
 
Support for Database Triggers

By adding an XML tag to individual columns in your schema classes, you can have MasterStudio automatically re-fetch specific columns from the database after an insert or update. This is especially useful for columns that the database fills by executing a trigger.

Update Oct. 21, 2003: Developers can override $update and $insert, re-fetching specific columns if they were changed by a trigger in the database. This is not an automatic feature.
Design pattern(s) implemented: -  
 
Intelligent Record Sorting

MasterStudio automatically adds an 'order by' clause to select statements, to ensure correct sorting if only a subset of records is fetched from the database. Once records are fetched locally (including Detail records), they are cached in intelligent Omnis Studio™ lists. If the user changes their sorting order, cached entries are automatically re-sorted as well.
Design pattern(s) implemented: Model-View-Controller
 
Framesets & Frames

MasterStudio brings the concept of framesets to Omnis Studio™. Subwindows can be nested into flexible and resizable 'framesets'. Individual resizable frames in a frameset remember their width and height; frames can be 'collapsed' or 'expanded/maximized' by the user. Window panes can be moved into any pane within a frameset; panes can be nested several levels deep.

Update April 15, 2005: Framesets offer several keyboard shortcuts allowing users to expand or collapse them without using the mouse.
Design pattern(s) implemented: Model-View-Controller, Composite
 
Panes & Pane Selectors

If a frame contains more than one pane, tabs appear automatically. Because component controllers never call each other directly, you can move individual panes into different frames (reorganizing the look and feel of the window) without changing a single line of code.
Design pattern(s) implemented: Model-View-Controller, Composite
 
Automatic Adjustment of Field Styles from Business Rules

MasterStudio uses predefined field styles that are assigned to window fields dynamically, depending on business rules in the data model (schema class). Field styles can easily be replaced on an individual basis by subclassing the 'user interface kit'.
Design pattern(s) implemented: Strategy (kit), Model-View-Controller
 
Automatic Entity Nesting

Creating Master-Detail windows is just as simple as building individual entity windows: As long as the model (schema class) defines a 'foreign key' to 'primary key' relationship, MasterStudio allows you to simply nest the detail entity into the master entity window. If you add multiple detail entities, they can either appear in separate side-by-side frames, or in individual tabs of a tab pane. The number of detail entities and panes is unlimited. A single window can display multiple nested master-detail relationships (e.g. a customer, its associated orders, and each order's individual order lines).
Design pattern(s) implemented: Model-View-Controller, Composite
 
Clean Model-View-Controller Implementation

Because views (windows, menus) in MasterStudio applications do not contain any application logic or data, data and controller state visualized by them is persistent. For example, when you close a window and re-open it, everything appears exactly in the same place: List data is still there, the current line and selected lines remain unchanged, and state of expandable views and tab panes is restored.

Update April 15, 2005: By default, MasterStudio automatically stores window positions and frameset sizes in the local user preferences. Developers have full control over initial window and frameset positions and sizes.
Design pattern(s) implemented: Model-View-Controller
 
Sticky Cursor Positions when re-opening (sub)windows

MasterStudio automatically puts the cursor into the appropriate field after opening a window or a (tabbed) pane and remembers the current field when parts of the window are collapsed (hidden) temporarily.
Design pattern(s) implemented: Model-View-Controller
 
Commands and Command Bars

MasterStudio offers you an abstraction layer between methods to be called and visual objects (buttons and menu lines) that activate those methods. Each 'command method' is encapsulated in a 'command object' that knows the name of the command and its associated attributes (such as icon id, tooltip, enabled state, keyboard shortcut, etc). Commands are added to a 'command controller' that groups, orders and manages the commands that are active in a certain context (usually, in a window). Separate view objects (command bars, dynamic menus, or toolbars) register themselves with the command controller to display the commands to the user.
Design pattern(s) implemented: Command, Model-View-Controller
 
Dynamic Command Menus and Context Menus

Commands can be added dynamically (they simply appear in the command bar and/or the menu). Commands can also be added for inclusion in the context menu that appears automatically when the user clicks anywhere on a window.
Design pattern(s) implemented:
 
Dynamic Context-Sensitive Menus

As commands are added to windows and subcontrollers, they appear automatically in corresponding menus. MasterStudio allows you to popup dynamic menus from your own list, where selected lines are checked automatically.
Design pattern(s) implemented: Model-View-Controller, Command
 
Command Ordering

MasterStudio automatically re-orders commands for different platforms: On Windows and Linux, 'Ok' and 'Cancel' are usually on the left. On the Mac, they automatically appear on the right. 'Alternate' (often dangerous) commands appear in a separate group.
Design pattern(s) implemented: Command, Model-View-Controller
 
Flexible Button Bars and Palettes

MasterStudio separates 'commands' from the 'views' that access them, such as button bars, toolbars, menus or palettes. MasterStudio automatically adopts their 'look and feel' to the current platform. Developers can easily subclass the view superclasses to create their own look and feel.
Design pattern(s) implemented: Model-View-Controller
 
Enhanced Button Feedback

MasterStudio command bars offer additional user feedback by temporarily highlighting the current command button. MasterStudio fixes the 'kBMok' button problem (Omnis Studio™ doesn't always redraw the default button correctly in multi-window applications).
Design pattern(s) implemented: Model-View-Controller
 
Window-dependent Palettes and Menus

Context-specific menus and palettes are installed automatically as users switch between windows. Palettes are positioned relative to a window margin or to the screen.
Design pattern(s) implemented: Composite
 
Full Keyboard Control

Developers assign default keyboard shortcuts to individual commands, after which these shortcuts automatically appear in the menu bar. No additional programming is required to activate the commands from the menu, shortcut keys, or buttons. Standard behavior of MasterStudio components can be controlled from the keyboard as well. For example, users use the 'Return' key to put a complex grid into $enterable mode and the Escape key to cancel entering data.
Design pattern(s) implemented: Model-View-Controller
 
Automatic Message Size Adjustment

MasterStudio offers easy-to-use 'dialog box' and 'prompt' panels that allow you to easily replace Omnis Studio™'s built-in messages. Panels automatically adjust their size (while staying centered on the screen or on their corresponding (sub)window component) to accommodate any icon size, any text size, and any number of command buttons. Panels use a command bar rather than fixed buttons so buttons are positioned in exactly the same (platform-dependent) way as they are on other framework windows.
Design pattern(s) implemented: Model-View-Controller
 
Dialog Messages Conform to Apple and Microsoft User Interface Guidelines

Panels (such as dialog boxes and prompts) and command bars (containing buttons) in MasterStudio automatically adjust their look and feel to conform to current platform standards. This includes icon used, division of text paragraphs in 'major' and 'minor' fonts, inclusion of the application name in the title of its dialogs, button sizes, button gap spacing, button focus (including the use of arrow keys to navigate dialogs) and button order. In short: MasterStudio messages look like they were made specifically for the end user's platform.
Design pattern(s) implemented: Strategy, Model-View-Controller
 
Messages and other Panels open on top of their Supercontroller

Panels automatically open on top of their associated component. Like in Java or Apple's Cocoa™, user interface panels are inserted into the component hierarchy so they can access data (and receive notifications) from supercontrollers. A panel may instantiate any number of subcontrollers that also become part of the application's controller hierarchy. Subcontrollers are destroyed automatically after their 'owner' is closed.
Design pattern(s) implemented: Composite, Model-View-Controller
 
Dialog boxes move their associated window into view automatically

If a dialog box is opened by a window that is currently out-of-view (because it is in the back, because it is minimized, or because it was moved off the screen), the window is moved into view automatically.
Design pattern(s) implemented: Model-View-Controller
 
Intelligent Dialog Messages and Tooltips

Window objects and dialog messages automatically use prompts derived from the data model. Dialogs include the name of the corresponding entity, as in 'Would you like to save your modifications to these customers?'. Dialog buttons use appropriate descriptive names such as 'Save' and 'Don't Save' rather than 'Yes' and 'No'. Texts of default messages and buttons are included in the language manager and are thus multi-lingual.
Design pattern(s) implemented: Model-View-Controller
 
SQL Error Message Handling

SQL error messages that occur during saving of changes in an MasterStudio enhanced smart list are automatically queued and appear as multiple messages with 'Next' and 'Previous' buttons. A SQL error message has a 'More Info' button that allows users to see the original SQL, native error code and native error text. Users can copy the error message to the Clipboard or export it to a file.
Design pattern(s) implemented: Model-View-Controller
 
Enterable and Selectable Grids

Individual complex grids can be toggled into 'enterable' or 'selectable' mode by the user depending on business rules in the data model; MasterStudio includes the 'Edit field' option in the context menu so the user can right-click on any field of a complex grid to edit it.
Design pattern(s) implemented: Model-View-Controller
 
Display of enterable grid selection, Multi-line select in enterable grids

Complex grids allow users to select and deselect lines while in 'enterable mode'. Users Shift-click or Control/Command-click in the left margin to select and deselect lines; MasterStudio automatically draws a checkmark in front of selected lines.
Design pattern(s) implemented: Model-View-Controller
 
Multiple-Column Sorting

Grid columns can be single-clicked to sort them or control/command clicked to add them to the sort order. Sort direction is reversed by clicking again on the same column header. Column icons indicate the sort level and sort direction. The data model (schema class) determines initial sort settings.
Design pattern(s) implemented: Model-View-Controller
 
Consistent Font and Color Use

Icons and field styles use a very consistent default color scheme that is subdued and doesn't detract the user's attention from your application data. Colors were carefully chosen to conform to the general look and feel of Windows and Mac OS, with special attention to the latest releases (Windows Vista and Mac OS X).
Design pattern(s) implemented: -
 
Custom Framework Icons

MasterStudio comes with a complete set of professional quality icons in a separate #ICONS table which can easily be replaced by your own icons on an individual basis by subclassing the 'user interface kit' (includes an icon factory).
Design pattern(s) implemented: Strategy (kit)
 
Platform Factories, dedicated enhancements for Windows XP/Vista and Mac OS X

MasterStudio includes an abstract superclass containing platform-dependent behaviors with concrete subclasses for any supported operating systems. Instead of checking sys(6) all over your code, MasterStudio offers a rich collection of platform-dependent accessors and methods, encapsulated in a dedicated 'platform manager'. The platform manager allows the use of special layouts, sizes, screen and report distances, icons etc. per platform. Because all platform-dependent code is in one place, adding future operating system support is trivial.
Design pattern(s) implemented: Strategy (kit)
 
Reusable Subwindows

MasterStudio comes with a collection of reusable subwindow components, such as a subwindow that adjusts itself to the size of a picture it contains, a subwindow that does the same for text, and a subwindow that displays a status icon and text in an 'LCD display'. These subwindows all use standard Omnis Studio™ attributes ($iconid and $text) so you can easily configure them from your own code.
Design pattern(s) implemented: -
 
Management of Omnis Studio™ 3.2 Platform Focus Borders

Omnis Studio™ 3.2 introduced system focus borders, where a border is drawn around the current field or grid. In some cases, this doesn't work very well, especially with panes that are resized dynamically. MasterStudio automatically manages the system focus (borders around active fields) and restores its setting to its previous value for other Omnis applications that are running.
Design pattern(s) implemented: -
 
Class Broker for Class Management and Multi-Library Support

MasterStudio allows you to divide classes into any number of logical libraries. A central 'class broker' manages location and version of individual classes and allows you to move classes into different libraries (or even a single library) for deployment or distribution. This concept is similar to the behavior of Java archives (JARs or ZIPs): You no longer worry where a class is located, as long as it's available anywhere in the class path (collection of subfolders).
Design pattern(s) implemented: Factory method
 
Automatic Version Patching, Version Control for Subclasses

To fix a bug in a single class, you can create a patch library that contains just the improved class. As long as you increment its version number, MasterStudio (and the rest of your application) automatically uses the patched class.
Design pattern(s) implemented: Factory method
 
Abstract Factories

MasterStudio 'class factories' have dedicated accessor methods for framework classes, allowing you to override them in your own subclass of the factory: You can simply replace any framework class by your own (sub)class, where any other applications (including framework itself) automatically uses your improved version.
Design pattern(s) implemented: Abstract factory, Factory method, Prototype
 
Live Language Switching

Locale-specific information is centralized into concrete subclasses of a 'language manager', which sends out a notification whenever the application language is changed. By listening to this notification, you easily build applications that can be switched to different languages 'on the fly'. Language strings can be (but don't have to be) read from Omnis Studio™ string tables; you may also fetch them from the database or from an XML file.
Design pattern(s) implemented: Observer, Strategy
 
Controller Hierarchy

Although Omnis Studio™ doesn't organize tasks into a hierarchy, MasterStudio controllers (including the root context and application contexts) are instantiated in a clean hierarchy following the 'composite' design pattern. Where applicable, MasterStudio follows Apple's EO (Enterprise Objects™) naming conventions. MasterStudio controllers have very similar behavior to those of Apple's WebObjects™ Java Client controllers. Objects can traverse the controller hierarchy by asking for an enumeration (list) of supercontrollers or subcontrollers. Each controller has a 'typeName' that signifies what the controller is used for. Controller enumerations can be filtered by controller typeName.
Design pattern(s) implemented: Model-View-Controller, Composite, Chain of responsibility, Enumeration
 
Application and Window Contexts

MasterStudio was built from the ground up to support multiple applications running in a single Omnis Studio™ runtime. When you close an application, any of its own windows will close as well (if there are unsaved changes, the user can save those changes, dismiss them, or cancel quitting the application)
Design pattern(s) implemented: Composite
 
Control Responders, Multiple Nesting of Components

In most Omnis Studio™ applications, events from subwindows are not passed to the subwindow container, but directly to the main window. MasterStudio component controllers automatically nest subwindows recursively and manage events (from standard $event and $control methods in associated subwindows and grids) so that they traverse the entire controller hierarchy. An event in a nested subwindow (such as a pane in an inner tabbed pane) can be trapped from the pane itself, from the tab pane, or from any pane the tab is nested into. Since there are no direct method calls between controllers in the hierarchy, controllers keep working if they are rearranged into different panes or even different windows.
Design pattern(s) implemented: Chain of responsibility, Composite, Adapter, Enumeration
 
Event Responders & Event Handling

Building on top of Omnis Studio™'s $event handler, event responders are called for events that occur at a certain level in the controller hierarchy. If an event is NOT trapped by its immediate event responder, it is automatically passed to the corresponding control responder and control responders of any supercontrollers in the hierarchy.
Design pattern(s) implemented: Chain of responsibility, Composite, Adapter
 
Command Responders and Dynamic Context Menus

Each controller in the controller hierarchy can add its own 'commands' to context menus by implementing a 'command responder'. When a user right-clicks on an object in a nested subwindow, then a dynamic context menu automatically displays the commands associated with the object, followed by commands associated with its component (subwindow), followed by commands associated with any of the outer subwindows or the main window. Developers no longer need to manually configure menus or button bars as the user interface changes.
Design pattern(s) implemented: Chain of responsibility, Composite
 
Delegation

Although MasterStudio allows you to subclass any of its classes, often it is easier to implement a 'delegate': An object that implements one or more 'delegate methods' that determine the ultimate behavior of a standard class. Delegation is a very powerful concept inspired by Apple's Cocoa™ Foundation framework that greatly promotes implementation and reuse of MasterStudio classes.
Design pattern(s) implemented: Template methods
 
Notifications & Notification Centers

MasterStudio automatically instantiates a 'notification center' for each application and window context, allowing objects belonging to each application and window to notify each other of events without creating any fixed dependencies between those objects. Applications can be extended and enhanced by adding observers, without any changes in objects that send notifications. MasterStudio notification centers offer all the power and flexibility of Apple's Cocoa™ notification centers in a clean and efficient Omnis Studio™ implementation.
Design pattern(s) implemented: Observer
 
Delayed Notifications & Deferred Drawing

Notifications can be queued (postponed) and/or coalesced (grouped and filtered). By queuing a notification, you can have commands execute at the end of a complex process. This is very handy for redraws and cleanup or garbage collection. By coalescing notifications, you avoid sending the same notification multiple times, an essential feature for notifications being queued from within a loop. MasterStudio lets you defer redraws of individual subwindows and other objects, thus increasing performance and eliminating 'flashing' as parts of the UI are redrawn.
Design pattern(s) implemented: Observer
 
Saving of User and Application Preferences, Column and Frame Widths

Many objects in MasterStudio store their internal data and settings ('Preferences') in a so-called dictionary (in simple terms, a list of key-value pairs). Other objects, such as a local preferences manager, simply store and retrieve these dictionary object instances without needing to know their contents. This enables MasterStudio classes to transparently store their preferences. For example, complex grids in Master-Detail windows automatically store their column widths. Frames in framesets remember their width or height. Windows optionally remember their last coordinates. As a developer, you can easily encapsulate your own object data into dictionaries, so that it can also be transparently saved into the preferences file.
Design pattern(s) implemented: Dictionary data structure
 
WYSIWYG Printing

Without additional programming, any database grid can be printed by the user. The report adjusts itself to the user's preferred column widths. Radio buttons are automatically replaced by their text; checkboxes become a check mark. Just like any windows, their corresponding reports contain localized strings derived from the data model (schema class).
Design pattern(s) implemented: Model-View-Controller
 
Automatic Hyperlinks

Once a schema class includes a foreign key relationship to a table for which MasterStudio has a 'default view', users can open a corresponding helper window by clicking a hyperlink. No programming is required. If the user enters a few starting characters for the joined field and presses tab, the helper list is automatically filtered for records that contain those starting characters. If only one record matches the search criteria, the helper list remains closed.
Design pattern(s) implemented: Model-View-Controller
 
A solution to the Omnis List Reference problem

Object instances store their notational access path in a dedicated instance variable. This enables them to communicate with other objects by passing a reference that always works. Objects can get references to other objects by using their $objectPath attribute.
Design pattern(s) implemented: -
 
Solutions for the Omnis Method Stack Limitation

To avoid hitting the 'too many methods on the stack' and 'calculation too complex' errors in Omnis Studio™, MasterStudio allows you to defer execution of methods. By serializing execution of complex tasks (rather than nesting the method calls on the stack), MasterStudio applications stay within the Omnis Studio method stack limit while executing complex behavior that would otherwise be impossible without resorting to externals.
Design pattern(s) implemented: Chain of responsibility, Command
 
Solution for the Omnis 'objects in list' problem

Omnis Studio™ has certain limitations that make it difficult (and slow) to access and call methods of object instances stored in lists. Instead of using nested lists, MasterStudio controllers offer a $newObject method that allows you to dynamically add object instances to any controller in the hierarchy.
Design pattern(s) implemented: Factory method
 
Consistent and Complete Naming Conventions

Local and parameter variables follow StudioTIPS™ conventions, which makes it easy to exchange code with other Studio developers. Additional conventions (e.g. naming of class and task variables) greatly improve the efficiency and practicality of multiple-level inheritance. Class naming conventions (grouping packages alphabetically) greatly reduce 'library clutter'.
Design pattern(s) implemented: -
 
Native Omnis Studio™ IDE Integration and Support for Omnis Debugger

Although MasterStudio offers additional tools and utilities, these are not required for developing MasterStudio applications. No additional development tools need to be installed and everything can be done using Omnis Studio™'s built-in IDE. Omnis Studio™ has a great IDE so MasterStudio doesn't try to re-invent the wheel. MasterStudio can be completely debugged using the provided source code.
Design pattern(s) implemented: -
 
Component Store Support

Reusable components and subclassable objects of MasterStudio have easily recognizable icons in the Omnis Studio™ component store. You don't need to customize your local Omnis Studio™ component store library to take advantage of MasterStudio's native window component store.
Design pattern(s) implemented: -
 
XML Attribute Editor

The XML attribute editor allows developers to edit specific MasterStudio attributes that are added to classes and schema columns.

Update Sept. 1, 2009: This feature is being considered for a future release.
Design pattern(s) implemented: -  
 
Controller Hierarchy Browser

Context and controller instances can be easily debugged by viewing and calling their methods from a dedicated tool that displays and browses the instantiated controller hierarchy.

Update Sept. 1, 2009: This feature is being considered for a future release.
Design pattern(s) implemented: Composite, Enumeration  
 
Deployment Tool

A dedicated tool allows developers to automatically deploy an application into a single deployment library, where selected classes are locked automatically.

Update Sept. 1, 2009: This feature is being considered for a future release.
Design pattern(s) implemented: -  
 
UML Class Diagram

MasterStudio documentation includes a UML class diagram that clarifies the relationships between framework objects and the corresponding inheritance tree. The UML class diagram will help you understand and soon take full advantage of this sophisticated object-oriented framework.
Design pattern(s) implemented: -
 
 

Omnis Studio is a trademark of TigerLogic Corporation. WebObjects, Cocoa and Mac OS X are trademarks of Apple Computer. Java is a trademark of Sun Microsystems. Windows XP and Windows Vista are trademarks of Microsoft Corporation. FrontBase is a trademark of FrontBase A/S. Oracle is a trademark of Oracle Corporation. StudioTIPS is a trademark of Vencor Software. These companies have in no way sponsored or endorsed Master Object AB.



Copyright © 2014 Master Object AB Terms of Use