comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » At Last! A Subsititute for CW_Field.
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: At Last! A Subsititute for CW_Field. [message #17974 is a reply to message #17881] Thu, 18 November 1999 00:00 Go to previous messageGo to previous message
davidf is currently offline  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
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Color Tables for Use with Chromatek Glasses
Next Topic: CW_Field Done as the Full Monty

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 20:06:08 PDT 2025

Total time taken to generate the page: 0.01366 seconds