| At Last! A Subsititute for CW_Field. [message #17881] |
Thu, 18 November 1999 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
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
|
|
|
|
|
|
| Re: At Last! A Subsititute for CW_Field. [message #17952 is a reply to message #17881] |
Fri, 19 November 1999 00:00  |
m218003
Messages: 56
Registered: August 1999
|
Member |
|
|
In article <38350CE8.E398D39@mpi-hd.removethis.mpg.de>,
Amara Graps <Amara.Graps@mpi-hd.removethis.mpg.de> writes:
> Struan Gray wrote:
>>
>> David Fanning, davidf@dfanning.com writes:
>>
>>> What, no Cheerios!? My family and I are currently in
>>> the processes of planning a summer trip to Germany.
>>> We may have to re-think it with this news. :-)
>>
>> If cheerios are what I think they are (biscuits with a cream
>> filling),
>
> No no, cheerios are the cereal, right David? I've not seen
> them here, but will Kelloggs Corn Flakes do? :-)
>
> ( don't forget the beer ;-) )
>
> Amara
>
Oh yes: Cheerios are the cereal! Corn Flakes are nice, too, but nothing
compared to these little donut shaped unsweetened crispy things (lucky
I've had breakfast already ;-). True: the chocolate is really worth going
(back) to Germany -- although you can get Lindt in the States as well
now (at least on the East Coast).
David: if you're coming next summer - will you stop by in Hamburg?
Best regards,
Martin
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ Dr. Martin Schultz Max-Planck-Institut fuer Meteorologie [[
[[ Bundesstr. 55, 20146 Hamburg [[
[[ phone: +49 40 41173-308 [[
[[ fax: +49 40 41173-298 [[
[[ martin.schultz@dkrz.de [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
|
|
|
|
|
|
| Re: At Last! A Subsititute for CW_Field. [message #17974 is a reply to message #17881] |
Thu, 18 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Martin Schultz (m218003@modell3.dkrz.de) provides a few
suggestions for improvement, then asks this:
> Third: why is this not an object? ;-) Indeed it would make sense to provide
> the functionality of this thing as object, so you could for example extend
> the "heart" of it (the validation routine) to allow for hex numbers or
> number ranges, etc.
Yes, indeed, it definitely *should* be written as an
object. But my original goal was to create a drop-in
replacement for CW_FIELD. I thought that was an hour
job, and it turned into something approaching three days
and two VERY late nights. Have you ever tried to decipher
RSI-supplied code. :-(
But you are correct, that validation routine is the heart
of the matter and it would be a whole lot easier to
extend it if it was an object method.
> Then again: with an object you would require two files:
> coyote_field.pro
> and coyote_ofield__define.pro
> so people wouldn't be able to get it running ;-)
I woke up this morning thinking about this. (Do you
have any idea how depressing it is to be this much in
love with a *programming* language, for God's sake!)
Anyway, I think the thing to do is to leave the user
interface alone, so it *can* be a drop-in replacement,
but turn the heart of the program into an object. The
outside world could get access (should they want or need it)
to the object nature via a GetGuts keyword. (I'd probably
spend an hour thinking of a better name, but that's what
comes to mind at the moment.)
It just all required more effort than I was ready to
give at 2:30 AM. :-)
> And this brings up the point how to best link objects and ignorant users.
> Should one provide a default object in the widget function and allow for
> a predefined object to be passed as a substitute? Hence,
> wID = coyote_field(...)
> would use the coyote_ofield object with the functionality as present,
> whereas
> wID = coyote_field(...,object=obj_new("hex_field"))
> would pass responsibilities on to this other thing.
No, I think the point of objects is that they will behave
in a particular way unless you override that behavior by
writing replacement methods, for example. You must just
supply the user with opportunity and clear instructions
for how to do so.
> Cheerios, (I love them and haven't found them over here)
What, no Cheerios!? My family and I are currently in
the processes of planning a summer trip to Germany.
We may have to re-think it with this news. :-)
Cheers,
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
|
|
|
|
|
|
| Re: At Last! A Subsititute for CW_Field. [message #17998 is a reply to message #17881] |
Mon, 22 November 1999 00:00 |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
Ben Tupper (Ben_member@newsguy.com) writes:
> I've often wondered why the Type declaration keyword for CW_FIELD is not defined
> as an alternative to declaring the data type with a keyword similar to
> COYOTE_FIELD DataType keyword. I guess I was thinking that it would nice to be
> able to declare the field type on the fly by passing along the TYPE index
> (returned by the SIZE function) to CW_FIELD (or COYOTE_FIELD) rather than
> specifying "/Float",... Is it possible to have each type of keyword (a string
> "DataType" and and integer "Type")competing to define the field type?
Well, this is exactly the kind of thing (declaring field type
on the fly) that is trivial to do if the program was written
as an object. It is much harder to do written the way it
is currently. I'll leave it up to you to turn it into an
object and send me the result. :-)
Cheers,
David
P.S. Don't forget to include Struan's request for
floating value formatting. :-)
--
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
|
|
|
|
| Re: At Last! A Subsititute for CW_Field. [message #17999 is a reply to message #17881] |
Mon, 22 November 1999 00:00 |
Ben Tupper
Messages: 186
Registered: August 1999
|
Senior Member |
|
|
>
> As always, I'm interested in testers and suggesters. :-)
>
David,
This looks great!
I have a specific suggestion regarding the DataType declaration keyword.
I've often wondered why the Type declaration keyword for CW_FIELD is not defined
as an alternative to declaring the data type with a keyword similar to
COYOTE_FIELD DataType keyword. I guess I was thinking that it would nice to be
able to declare the field type on the fly by passing along the TYPE index
(returned by the SIZE function) to CW_FIELD (or COYOTE_FIELD) rather than
specifying "/Float",... Is it possible to have each type of keyword (a string
"DataType" and and integer "Type")competing to define the field type?
Thanks for all the great tools!
Ben Tupper
PemaquidRiver@tidewater.net
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
