   
|
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), 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). MasterStudio uses FrontBase's native 'select unique' implementation.
|
|
Design pattern(s) implemented: -
|
|
|
|
|
|
|
Support for all Studio DAMs
|
|
MasterStudio includes superclasses for both V2 (Classic) and V3 (Non-Visual) Omnis Studio™ DAMs with concrete subclasses for Omnis native data file, Oracle, and FrontBase. Additional subclasses can easily be added.
Update July 29, 2005: MasterStudio's built-in session and statement objects no longer support V2 DAMs.
|
|
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. Oracle fully supports 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 numbe |
