Tips   >   Objectclasses   >   Data Objects

Data Objects

When you get fairly deep into the object-oriented mindset, you start to see that everything in Omnis Studio is an object. Objects have attributes, also know as properties, plus methods that do things. Omnis Studio classes have built in properties and methods which you can view in the F6 Property Manager after you select the class in the F2 Browser.

Let's say we create an object class called oApplicationProperties.

Now we decide to add some properities to this object. A public method is added to oApplicationProperties for each property. e.g.

$:AppName, $:DeveloperName, $:VersionNum/code>)

The code behind each of these property methods ends with Quit method RetValue


You can make a property assignable, by creating a $assign method for the property.

e.g. $:AppName.$assign(pAppName)

The public method name actually includes the .$assign suffix in the method name!

You can now instantiate oApplicationProperties using an instance variable in a window class, and then use the instance variable name followed by the public method name as the $dataname for the entry fields in the window class.

e.g. Instead of iList.ColName, you would use ioProperties.$:AppName

If there is a .$assign suffixed method available for a property, Omnis Studio will automatically call the $assign method in the data object just prior to the evAfter event for the entry field.

Click the Run Demo button in the StudioTips Browser window to open a Data Object demo window.

Data Object Advantages

There are several advantages for using data objects:

  1. You can use data objects to create a layer between your interface classes (window and report classes) and your persistence classes (table classes/database). This layer can give you finer control and data validation between these classes and the flexibility to use different field names.
  2. You can encapsulate all the functionality of a complex set of data into a single object with a clearly defined public interface.
  3. The $assign suffixed method is called before evAfter allowing you to execute code prior to the evAfter event. There may be situations where this would be useful.

Data Object Problems

There are some drawbacks to using data objects.

  1. A list property cannot be directly used in a window object $dataname.

    If I have a data object property which is a list, you can't put that property name directly into a window list object. The work around is to create a list variable in the window class and Calculate iListVar as ioDataObject.$:TheList
  2. Data objects can not be used in web client remote forms. To the best of my knowledge remote forms will only support row and list variables.
  3. Creating the data objects can be time consuming. You have to create a public method for each property, and a .$assign suffix method for each assignable property.

Data Object ivars

You can directly access the ivars in your data object. This is demonstrated in the demo included in StudioTips with the tip.

Instead of setting the $dataname property of a field to ioDataObject.$PropertyMethodName, you set it to ioDataObject.iVarName.

The advantages of doing this are:

  1. You don't need to create a property method and $assign method for each property.
  2. You can display list and row variables directly in list field objects.

The disadvantages of doing this are:

  1. You can't intercept getting and setting the data object's properties.
  2. Changing the name of an ivar in your data object will break any GUI objects that were using the ivar name.
Object-oriented purists would argue against directly accessing a data object's variables... and they do so for valid reasons, if you only access and manipulate an object's properties through its interface (public methods) your code will be stronger.