IDL Programming: Object-Oriented programs.

Object-Oriented programs are the most sophisticated type of program within IDL. Using objects lets you:

• Recycle the same program many times.
• Have access to all of the data analysis and processing programs of the object. These are called methods.

IDL Objects compared to Compound Widgets:

IDL widget-based Objects share many similarities with IDL's Compound Widgets. Both of them:

• Can have many independent instantiations of the same basic object (or CW) within the same program.
• Can have their own data processing routines.
• Can store data so it is hidden from other programs.
• Can store information about their own properties or "state".
• Can be placed into a parent widget, a parent object, or a parent CW.

The main differences between an Object and a Compound Widget are:

• A CW must always be widget-based, whereas an object may or may not incorporate a widget.
• A CW must always have a parent widget (even if the CW appears freestanding), whereas an Object can be a top-level program.
• A CW usually has a single value or parameter that is meant to be changed, whereas an object can have many changeable parameters.
• A CW is generally used for a smaller, specific task where the goal is to change or retrieve a single item (filename, filename list, color table, scalar value, location coordinates, etc.), whereas an object is more appropriate to a larger task that may have several goals or purposes.
• It straight-forward to communicate changes made within a CW to the parent event-handler, via the normal event-handler mechanism. A somewhat contorted path is required to communicate changes made within an Object to it's parent Object or widget (if any).
• The properties of a CW are stored in a structure that is in turn typically stored in the UVALUE of one of the widget-bases of the CW, whereas the properties (data) of an Object are an integral part of the Object itself. The data structure of an Object cannot be nested (i.e. have a structure within a structure), but any of the methods can easily access the Object's data. Accessing internal data is sometimes complicated for a CW.
• It is harder to write an Object than a CW, but it is easier to write a bad CW than a bad object. This is partly because there are a few more requirements and guidelines for an Object.

Introduction to Objects

If you have heard of IDL's Objects before, it is probably because you are interested in IDL's Object-oriented Graphics. This approach to graphics utilizes a large number of individual Objects. At first, you probably found the new syntax so confusing that you decided that maybe the older Direct-graphics were not so bad after all (as I did!). However, there are many benefits to using Object graphics. These benefits become much greater as the complexity of your display increases, for instance if you want to create a 3D view of some item. RSI (the company that makes IDL) has a manual that does a pretty good job of explaining about Objects. It is a training manual called: "Advanced Application Development with Object Graphics".

Every IDL Object is composed of a number of subroutines. The subroutines you interact with as a user are called methods. There are also some other subroutines that are necessary for the Object to work properly. The following list shows the types of subroutines that are needed for a robust Object:

• Definition: defines all possible parameters, data, widgets, etc. used by the Object.
• Initialization: sets parameters to initial user-defined values.
• Cleanup: destroys the Object, cleaning up any pointers or objects owned by the Object.
• Set Property: lets the user alter or set various properties of the Object.
• Get Property: lets the user retrieve or view the current properties of the Object
• Methods: subroutines that do most of the work.

Actually, all of the items above except for the Definition subroutine are methods. Not coincidentally, Compound Widgets have a similar set of subroutines:

• Definition and Initialization: usually combined into the same program, named as the CW itself.
• Cleanup: only needed if the CW has created it's own pointers or objects.
• Set_Value: allows WIDGET_CONTROL to set the value of the CW.
• Get_Value: allows WIDGET_CONTROL to retrieve the value of the CW.
• "Methods": the internal subroutines that perform any needed tasks.

Basic Object Syntax

The basic syntax for communicating with an object looks confusing at first glance, but is actually quite simple. There are generally three (3) things you will do with an object:

• Create it.
• Work with it through its methods.
• Destroy it when you are done.

Let's suppose we have an object called "My_Obj". To create an instance of this object, you would type:

this_obj = obj_new('My_Obj')

The "this_obj" is simply a name and can be anything, but the rest of the phrase must be exactly as above, including quotation marks. The variable "this_obj" now contains a reference to your new object. Suppose this is some sort of object that displays an image. There are two ways to pass the image to the object:

• When creating the object: this_obj = obj_new('My_Obj', IMAGE=img)
• After creating the object: this_obj ->SetProperty, IMAGE=img

You must have access to a description of the object that tells you what the Keywords (like IMAGE) are and how to use them. The second method above uses a method called "SetProperty". This illustrates the standard way of communicating with an object through its methods. In general, the syntax looks like:

this_obj -> Method

You are calling one of the methods associated with the object, but more importantly you are associating the method with a particular object, "this_obj". This is important, since this is how/why you can have multiple independent objects all working at the same time. You can pass data or parameters to a method using normal parameters or keywords:

this_obj -> Method, parameter1, parameter2, KEYWORD1=parameter3, /KEYWORD2

The method will then do whatever it is supposed to do (we hope!) and normally will not return anything. If you want the Object to return something, you must tell it where to send its result. Suffice it to say for now that this can get complicated.

When you are all done with the Object, you must destroy it:

obj_destroy(this_obj)

This calls the cleanup routine within the widget that is responsible for destroying and mopping up all of the object's internal pointers and objects. The obj_destroy program then deletes the object from IDL-land. If there were widgets associated with the object, they are also destroyed at this point.

Most people place a series of object commands into a file and interact with the object via a program, which may or may not include a widget GUI. However, it is entirely possible to interact with your object from the IDL command line. As a matter of fact, most Object commands are terse and easily typed, so if you are a command-line person this is an ideal program structure for you.

Questions or comments? Terry Oakes: troakes - at - wisc.edu

Back to Spamalize.