| Re: object newbie [message #21304 is a reply to message #21141] |
Wed, 16 August 2000 00:00   |
Martin Schultz
Messages: 515
Registered: August 1997
|
Senior Member |
|
|
Chip Sample wrote:
>
> Maybe if I provided a few more details, it would be apparent whether I've
> missed the boat.
>
> I have a widget that is used to read and graph data from a radar model
> written in C. I also use the widget to launch and control runs of this C
> program on many machines across the network (thereby insulating me from
> UNIX), as well as browsing and editing the input files and creating
> additional runs according t a trade space. This all was developed without
> objects.
>
> Based on discussion here a curiosity I decided to begin to "objectify" this
> widget and began with the structure that contains "jobs", i.e. the path/name
> of the executable, the path/name of the target file, the path/name of a dump
> file containing what would normally go to the screen, a list of program
> options, the lun being used, and IDs of some control widgets associated with
> that job. These widgets can be used to kill the remote job, look at the
> dump and output files, and look at a status display containing most of the
> information on the job object. So to pass these fields into the display
> widgets, I need access to most of the field values.
>
> Is this a case where the object is inappropriate, or perhaps a case where I
> simply haven't gone far enough, and more of the program should be
> "objectified" in order to see the benefits.
>
> Chip
>
Hi Chip,
oh yes, I think you are swimming about 50 yards next to the boat -
almost
there but still struggling ;-) As far as I can see from your
description, the
problem is as I said a conceptual one: In objectworld, you don't pass
data to
a widget, instead the object includes the widget. In your case you could
have an
object structure for a single job which might vaguely resemble this:
obj_class = { cs_job, $
exepath : '', $ ; path name of executable
targetpath : '', $ ; target path
dumppath : '', $ ; path of screen dump file
options : Ptr_New(), $ ; program options
tlb : -1L, $ ; widget ID of top level base
idexepath : -1L, $ ; widget ID of exepath text field
... etc.
}
Then you write a method named cs_job::GUI or something similar which
build the widget and
passes it to XManager (with /no_block). Take a look at David's web site
how to best control
widget events (I particularily like the idea of generating messages
which contain the object
reference and method name). If you destroy the widget, you set self.tlb
to -1, and in your
cleanup method, you test IF self.tlb GE 0 THEN widget_control,
self.tlb,/DESTROY. The widget
that this object would build, controls only one job - it could also be a
compound widget
which would then be included in ... see below.
Now, if you want to manage several jobs, you probably want to use a
container object which
you may derive from the original IDL_Container, or you can use my
MGS_Container if you like
to access the jobs by name. You can either write an object that uses a
container, or one that
inherits from a container (I don't have enough experience to favour one
over the other).
This object would also include widget ID's and a GUI method, this time
you build a GUI
which lists all jobs that are currently defined, or all jobs that are
active, etc.
If you proceed this way, the only data that you need to pass from the
individual job objects
to the job container object are the data that you want to display in the
list widget. If you
like to see detailed information about all jobs at once, you can also
have some keyword like
jobdescription in cs_job::GetProperty which would return a string that
is formatted ready
to go into the list widget.
Hope, this helps,
Martin
PS: please take RSI's advice seriously and name all your objects
beginning with your initials
(three letters are best). This tremendously decreases the likelihood of
name conflicts and may
one day lead to a nice collection of objects from various people that
can actually interact
with each other (dream, dream, ...). OK: at least all objects that have
any slight chance to
end up in some library at some point -- and I could conceive job control
being one of these things!
--
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
[[ 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 [[
[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[[ [[[[[[[
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
