While it is easy to build a window in Omnis Studio, most applications consist of many windows and “panes” that contain near- identical functionality. While it is easy to create a window superclass that provides common functionality, this superclass has a tendency to grow out of control. As a result, instantiating a complex window can become very slow. And, once we start mixing and matching functions and subwindows more than one level deep, it becomes difficult to manage the relationships between these components.

In this session, we’ll talk about using tasks and controller objects to host the “logic” behind your windows, giving window classes only one responsibility: being a “View”. Anything related to the “Model” and the “Controller” should not be in the window class! By linking window components to a corresponding controller object, they can suddenly be reused anywhere. And you can easily implement seemingly complex features, such as “open this tab in a new window”. By nesting controller objects in a hierarchy, we can use the “chain of responsibility” pattern to manage their relationships.

•This topic will be of special interest to client/server developers who have a need to:

•Control growing window complexity

•Improve window instantiation speed

Session participants will receive a fully unlocked development version of the MasterStudio framework, code examples, and a working demo application that shows what can be achieved.

By cleanly applying object-oriented concepts in Omnis Studio, we can avoid writing any logic twice. And thus, we can avoid fixing a bug and having it pop up again anywhere else. Also, we can spend more time on optimizing the code, resulting in faster, consistent, bug-free applications. And we can add luxurious functionality that is suddenly available anywhere in all windows of all of our applications.

It is not always obvious that code for checking user input behind a field in a window should really be located in a table class. And what if multiple fields do the same thing? In that case, we can create a common object instance to manage their functionality. If we display buttons as well as menus and context menus that allow users to control your application, shouldn’t these various “View objects” call the same function automatically? And if a specific function is currently disabled, shouldn’t all corresponding buttons and menu lines be disabled as well?

•This topic will be of special interest to client/server developers who have a need to:

•Reuse complex functions throughout many parts of an application with no copying of any code;

•Reduce “feature creep” and the associated bugs and maintenance cost;

•Add user interface features without copying or replicating code.

In this session, we’ll explore various ways in which the ideal of “Single Point Of Definition” can be implemented in Omnis Studio, implementing long-established design patterns in ways that make sense in Omnis. Participants will receive a fully unlocked development version of the MasterStudio framework, code examples, and a working demo application that shows what can be achieved.