A couple weeks ago, I wrote a [demo program](http://michaelgalloy.com/?p=9) to view JPEG 2000 images as a “regular” widget program. Now I want to rewrite the same program as an “object widget,” in other words write methods of a class instead of normal functions and procedures. You need to already understand the basics of object-oriented and widget programming in IDL to follow along with this example. The following files are needed for this program: [`mgtilejp2__define.pro`](http://michaelgalloy.com/demos/objectwidget/mgtilejp2__define.pro) (
doc), [`mgobjectwidget__define.pro`](http://michaelgalloy.com/lib/widgets/mgobjectwidget__define.pro) ( doc), [`mg_object_event_handler.pro`](https://github.com/mgalloy/mglib/blob/master/src/widgets/mg_object_event_handler.pro) , and [`mg_object_cleanup.pro`](https://github.com/mgalloy/mglib/blob/master/src/widgets/mg_object_cleanup.pro).
This new program will have exactly the same functionality as the old program. So what are the advantages of writing the program as an object? Of course it’s a matter of preference and some will already have a preference to use or avoid objects. Here are my thoughts about the advantages of this approach:
1. Cleaner: state/pstate doesn’t need to be passed around.
2. Better encapsulation when multiple programs are interacting with each other and passing messages to each other. In other words, one program doesn’t need to know internal details about the other program in order to pass a message to it.
### New architecture ###
There are several techniques to make “object widgets.” I found the following technique simple yet still has the advantages of object-oriented programming. The steps to making a simple object widget:
1. The member variables of the object hold what used to be in the `state` or `pstate`.
2. The `init` method is the widget creation part of the program. One important item: place `self` in the `UVALUE` of the top-level base. This will make our scheme for event handling work.
3. `XMANAGER` can’t call a method for an event handler or cleanup routine, so we will trick it. Instead write a simple two line event handler which pulls out the `UVALUE` of the top-level base (which is our object widget reference) and calls the real event handler method of the object. This will mean that our object widget will only have a single event handler that handles all events (but possibly dispatches events to other routines). The same must be done for the cleanup routine.
Once you’ve done this, it’s fairly easy to modify the structure a bit for your own purposes.
### Code changes ###
Here’s what I had to do to make `MG_TILEJP2` into an object widget:
1. Change the names of the routines from
mgtilejp2::init. Make sure to change it to a function and return 1.
2. Add `MGTILEJP2__DEFINE` that simply names the class, inherits from `MGObjectWidget`, and creates the member variables with the same name and type as the fields of the old state variable.
3. Convert creating `pstate` and putting it into the `tlb`’s `UVALUE` into putting `self` into the `tlb`’s UVALUE. Get rid of
widget_control, event.top, get_uvalue=pstate
in event handler.
4. Fix up passing around `pstate` since it’s no longer needed. Fix `(*pstate).owindow` to `self.owindow`.
5. Added a `cleanupWidgets` method, fixed up `cleanup` method, and `MG_TILEJP2_EVENT` to `mgtilejp2::handleEvents`.
See [previous post](http://michaelgalloy.com/?p=9) about tiling JPEG 2000 images with `IDLgrImage`.
UPDATED 10/25/13: Updated links of library source code.