From - Wed Jun 10 12:00:16 1998
Return-Path: <richard.schwartz@gsfc.nasa.gov>
Received: from sunspot.ssl.berkeley.edu by apollo.ssl.berkeley.edu (SMI-8.6/SMI-SVR4)
	id LAA14971; Wed, 10 Jun 1998 11:42:06 -0700
Received: from hxrbs.gsfc.nasa.gov by sunspot.ssl.berkeley.edu (SMI-8.6/SMI-SVR4)
	id LAA01992; Wed, 10 Jun 1998 11:42:05 -0700
Received: from hxrbs.gsfc.nasa.gov by hxrbs.gsfc.nasa.gov (5.65v3.2/1.1.10.5/15Apr98-0408PM)
	id AA14984; Wed, 10 Jun 1998 14:39:38 -0400
Sender: richard@hxrbs.gsfc.nasa.gov
Message-Id: <357ED2E9.15A48C83@gsfc.nasa.gov>
Date: Wed, 10 Jun 1998 14:39:38 -0400
From: Richard Schwartz <richard.schwartz@gsfc.nasa.gov>
Reply-To: richard.schwartz@gsfc.nasa.gov
Organization: HESSI DAC at GSFC
X-Mailer: Mozilla 4.05 [en] (X11; I; OSF1 V4.0 alpha)
Mime-Version: 1.0
To: Andre Csillaghy <csillag@ssl.berkeley.edu>
Subject: Re: Pointers or not pointers
References: <357ECA34.850A8809@ssl.berkeley.edu> <357ECD2F.B76A8155@gsfc.nasa.gov> <357ED264.98E55E54@ssl.berkeley.edu>
Content-Type: multipart/mixed; boundary="------------24A31A563D683B6B28EEAB13"
Content-Length: 2913
X-Mozilla-Status: 8013

This is a multi-part message in MIME format.
--------------24A31A563D683B6B28EEAB13
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Andre Csillaghy wrote:

> Richard Schwartz wrote:
>
> > Pointers may be a useful technique within some of the utilities that handle the event lists.
> > Any of the difficulties that Ed has discussed should be buried within a module so that the
> > user need only be concerned about accessing the items of interest without worrying about the
> > burdensome details.
>
> I agree that pointers should not be used "freely".
>
> > So instead of the seminar, perhaps you'll give Kim and me a private
> > tutorial.
>
> That will be fine.
>
> I should say that "buried in a module" as well as "without worrying
> about the burdensome details" invokes to me the concept of object. I
> could imagine an object (that is, a module) "EventList" with its
> associated methods (that is, the utilities). With these objects, it
> seems to me that the largest difference with "ususal" programming is the
> naming. I could extend the tutorial to this theme if you want.
>
> Best regards,
>         -- Andre

  Ah,

So that is what objects are about.  We have several places in the software where the result may
be obtained by different methods that are more or less hidden from the caller.  So the tutorial
may need this expansion.  And you won't be in Berkeley next week?

Richard

the new restore_plotvar has been installed in the real $SSW and should propagate.  I've attached
it for your convenience so you can  use it in coordination with my installed version of
set_utaxis.



--------------24A31A563D683B6B28EEAB13
Content-Type: text/plain; charset=us-ascii; name="restore_plotvar.pro"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="restore_plotvar.pro"

;+
; PROJECT:
;	SDAC
; NAME: 
;	RESTORE_PLOTVAR
;
; PURPOSE:
;	This procedure reloads system variable structures from stored values.
;
; CATEGORY:
;	Graphics, Utplot
;
; CALLING SEQUENCE:
;	Restore_plotvar
;
; CALLS:
;	STORE_PLOTVAR
;
; INPUTS:
;       none explicit, only through commons;
;
; OPTIONAL INPUTS:
;	none
;
; OUTPUTS:
;       none explicit, only through commons;
;
; OPTIONAL OUTPUTS:
;	none
;
; KEYWORDS:
;	none
; COMMON BLOCKS:
;	STORE_PLOTVAR_COMMON
;
; SIDE EFFECTS:
;	none
;
; RESTRICTIONS:
;	none
;
; PROCEDURE:
;	none
;
; MODIFICATION HISTORY:
;	Version 1, ~1990
;	Version 2, Documented, richard.schwartz@gsfc.nasa.gov, 23-mar-1998.
;	Version 3, richard.schwartz@gsfc.nasa.gov, 10-jun-1998.
;		Ensure variables in common are defined prior to usage.
;-
pro restore_plotvar

@store_plotvar_common

if not keyword_set(store_bangx) or not keyword_set(store_bangy) or not keyword_set(store_bangz) $
	or not keyword_set(store_bangp) then store_plotvar

!x = store_bangx
!y = store_bangy 
!z = store_bangz 
!p = store_bangp 

end

--------------24A31A563D683B6B28EEAB13--