Re: error codes and editMethods


Subject: Re: error codes and editMethods
jeff@abisource.com
Date: Mon Apr 24 2000 - 19:25:39 CDT


On Mon, Apr 24, 2000 at 01:48:37PM -0500, sam th wrote:
> On Mon, 24 Apr 2000 jeff@abisource.com wrote:
>
> <lots of interesting details snipped>
>
> well, my basic philosophy was that we shouldn't be throwing data way
> needlessly, because someone might want it. i hadn't actually thought too
> much about who, but upon quick reflection, one example would be the very
> eventual abisuite scripting language, which would want to be able to
> access methods such as fileSaveAs() Now, I'm not sure if it would be
> better to do this with an externally abstracted funtion that
> Defun1(fileSaveAs) calls, or by extending EV_EditMethod. I'm sure you
> have more insight on this than i do.

i'm not sure it matters one way or the other.

when you start looking at it from a scripting language
point of view, you probably want to have "dialog-free"
and "message-box-free" versions of the edit methods
or something equivalent -- or something that may need
to have a different interface (take a pathname, for
example). but then i haven't given it much thought.

one thing to think about is if we want to be able to
have named script functions/macros that we can then
bind key/mouse/menu/toolbar events to. [one of the
reasons for the [complicated] method invoking technique :-]

[then if we'd get the binding table shortcuts that were
talked about last week [and a way to dynamically load
them from the profile [and ... :-]]]

as i said, i'm not sure it matters. none of the
current callers would use them if presented with
them, so i'm inclined to say let's wait until the
scripting interface is ready and let's see what
it dictates.... i think it would be fine to extend
the interface, i'm just not sure we need to at this
point in time.

hope this helps,
jeff



This archive was generated by hypermail 2b25 : Mon Apr 24 2000 - 19:25:39 CDT