Category "Objects"

Templates are tools for creating text output reports. The beauty of templates is that they allow a separation of the code that generates/calculates information from the code that produces the output. The template code produces the output and is done in plain text in the type of output desired with a few directives that are used to insert the real information, check conditions, do loops, include other files, etc. This article will demonstrate more features than [my original post about templates]( The demo program [``]( ([docs]( uses three templates to create its output: the [main template](, the [header](, and the [footer](

The files needed to use the template are the [`MGffTemplate` class]( (docs) and the [`MGffTokenizer` class]( (docs).

Continue reading "Report generation: more about templates."

Template classA class similar to `MGffTemplate` is used in IDLdoc to produce all its output. When I changed from a bunch of print statements scattered over various methods of a class to templates where all the output is in a template file, it was a lot easier to focus on the content of the output. If you need to generate text-based reports (HTML, XML, LaTeX, DocBook, etc.) from IDL, I would suggest using this class.

The files needed to use the template are the [`MGffTemplate` class]( (docs) and the [`MGffTokenizer` class]( (docs).

Continue reading "Template class."

Screenshot of JPEG 2000 viewer A couple weeks ago, I wrote a [demo program]( 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: [``]( (doc), [``]( (doc), [``]( , and [``](

Continue reading "Object widgets."

One area that is sorely missing in IDL's library is more flexible collections. Sure, arrays are extremely powerful in IDL and we should try to use them whenever possible. But sometimes arrays are just not the right tool for the job. There are two main cases which arrays don't handle well:

1. Arrays can't have zero elements.
2. Adding an element to an array by concatenation repeatedly is *extremely* inefficient.

`MGArrayList` solves both of these problems. This is one thing in my library that I use on nearly every project.

I have a class on RSI's User-Contributed Library called `Array_List` which has most of the same functionality, but I wanted `MGArrayList` to have exactly the same interface as `IDL_Container`. So `MGArrayList` should do everything `IDL_Container` does, but for all types instead of just objects.

[Source code]( and docs for `MGArrayList`, its iterator, and parent classes. I intend to implement other collection classes such as hash tables, sets, and trees over the next few weeks.

« newer posts