IDL Programming: Object-Oriented programs.
Object-Oriented programs are the most sophisticated type of program within IDL. Using objects lets you:
IDL Objects compared to Compound Widgets:
IDL widget-based Objects share many similarities with IDL's Compound Widgets. Both of them:
The main differences between an Object and a Compound Widget are:
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:
Actually, all of the items above except for the Definition subroutine are methods. Not coincidentally, Compound Widgets have a similar set of subroutines:
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:
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:
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:
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.