At Last! A Subsititute for CW_Field.

[davidf(at)dfanning.com (David Fanning)]

Hi Folks,

I've been working on the new XWindow thing, as I've
mentioned. And as it sometimes goes in programming, one
thing has led to another, and then to another, and the
project has become bigger than I ever imagined. But I'm
trying to do this with objects and learn a bit about
some of the advantages of inheritance, etc. In other
words, I'm trying to do it right.

So I came to the point the other day where I needed
a CW_FIELD widget in one of my modal dialogs and I
just couldn't bring myself to use CW_FIELD one more
time. I don't know what it looks like on UNIX machines,
but on Windows machines the text widget part of the
compound widget doesn't look editable. 

This leads to enormous confusion on the part of users. 
Since they get no visual clue that they can edit the 
numbers there, they don't. As a result, programs that use
CW_Field are always returning wrong X sizes or Y sizes
and reading past the end of the file, or not reading
enough data, or whatever.

And a couple of other things annoy me about it.
First of all, you can't attach an event handler
to the darn thing. So you have to futz around
and put them in a base that has an event handler
attached to *it*, but the five compound widgets
I have in the base do different things, and I don't
want to have to sort it out, and... Well, I won't
go on. 

Suffice it to say that it is my opinion
that compound widgets that don't allow you to
attach event handlers to them are not written
properly. 

And then there are aesthetic concerns, which always
seem to fall somewhere pretty far down on RSI's
priority list, it seems to me. But when you are
as anally retentive as I am it's real important--
*REAL* important--that the damn things line up
properly in the damn base! 

So...

I wrote my own program that works the way
I do. I should think there may be one or two of
you who might be interested in it. I named it
Coyote_Field and you can find it here:

   http://www.dfanning.com/programs/coyote_field.pro

For the most part it is a drop-in replacement for
CW_Field, at least if you have been using CW_Field
as I have. One big difference is that Coyote_Field
returns a named event structure. CW_Field couldn't
do that (another bother) because the Value field 
in the event structure is always defined at run-time. 
It can be a string, long, float, etc. I've solved 
the problem by having the Value field
be a pointer to the data. So if you rely on this
part of the event structure, you will have to
modify your code.

I tend to always get the data out of a CW_Field
with the Get_Value keyword to Widget_Control. If you
do this, then you won't even notice a difference.
Except the darn thing will look more attractive. :-)

I've put a little example program at the end of the
code that exercises the compound widget a little bit.
I've tested things, but I'm not ready to declare it
bug free. The number validation code is quite a bit
trickier than I thought it was going to be when I
set out on this mission. :-)

To run the example program, download the Coyote_Field
program, then do this:

   IDL> .compile coyote_field
   IDL> example

There will be three compound widgets. The first is
an INTEGER field and returns events every time you
touch it. The second is a FLOAT field and only returns
events when a CR is hit (not very useful, it seems to
me, but a feature of CW_FIELD that I decided to retain).
The third is a STRING value that you can get and set
the value of with buttons.

As always, I'm interested in testers and suggesters. :-)

Regards,

David

-- 
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155