Skip to content

Desktop Object

The object nesting topic explains how an application’s object structure is determined by the placement of its objects. All objects that you declare must be placed inside of other objects.

To enable you to declare objects outside any other object declarations, a special outermost wrapper object is created for you automatically when an application is initialized. This is called the desktop object. This object, based on the cDesktop class, contains all of the objects you create.

When an object is not placed inside of any other object, it is still inside of the desktop object. This is sometimes referred to as placing an object “on the desktop.” Objects placed on the desktop are direct children of the desktop object. Objects placed inside of other objects are still descendants of the desktop object (grand-child, great grand-child, etc.). Therefore, messages sent to any object are able to delegate to the desktop. For more information, refer to the section on delegation.

Desktop Methods

The desktop object is derived from the cDesktop class. To create methods for the desktop object, you must use the keyword Desktop in the method declaration. For example:

Procedure DesktopProcedureName Desktop integer iParam string sParam

The Desktop keyword signifies that the method is added to the cDesktop class and is therefore understood by the desktop object. It does not matter where this method is defined; if the Desktop keyword is used, it is placed in the desktop object.

Messages for the desktop methods can be sent to the current object and resolved via delegation, or they can be sent directly to the desktop object:

// resolve the message via delegation
Send DesktopProcedureName iParam sParam

// send message directly to the desktop (preferred)
Send DesktopProcedureName of Desktop iParam sParam

If you know that the message will be resolved at the desktop, you should use the of Desktop syntax as this ensures that the method will not be understood and intercepted by some other object in the delegation path, and it better shows the programmer’s intent.

Considerations for Desktop Methods

Desktop methods should not be overused. Care should be taken when creating methods for the desktop object:

  • Because desktop objects are accessible by all objects, they can defeat the purpose of encapsulation.

  • Desktop methods can be scattered all over your code, making them more difficult to maintain. This is another reason why they should not be overused.

  • You should never augment or replace an existing desktop method.

  • If you need to create a library of methods that can be used by all objects, it is usually better to create objects on the desktop that contain those methods and send messages to that object.

Ambiguous Desktop Methods

All procedures and functions defined outside of all other objects should be designated as being Global or Desktop. Prior versions of DataFlex supported a syntax where an outer procedure/function designation was unspecified. This is referred to as an Ambiguous Desktop method. You should never create an Ambiguous Desktop Method.