SmalltalkSystem options

Andy/Blair,

I've been having a look into replacing an existing tool with one that adds a
bit of extra functionality, ViewComposer in this case. I added my new VC
subclass then sent a message to SmalltalkSystemShell>>viewComposerClass:
passing over the name of my new class.

I thought the idea then was that if I then used any of the existing methods
of opening up the ViewComposer that they would start up my new class
instead?

What happens is that starting the VC from a toolbar icon starts up my new VC
but using either the Tools menu or the big icon in the System Folder will
still start up the original VC. These two methods both route through
SmalltalkSystemIcon>>openIn: whose openBlock contains a hard reference to
ViewComposer.

Ian

Ian

You wrote in message news:9200i2$b0k$[hidden email]...
> ...
> I've been having a look into replacing an existing tool with one that adds
a
> bit of extra functionality, ViewComposer in this case.
>....
> What happens is that starting the VC from a toolbar icon starts up my new
VC
> but using either the Tools menu or the big icon in the System Folder will
> still start up the original VC. These two methods both route through
> SmalltalkSystemIcon>>openIn: whose openBlock contains a hard reference to
> ViewComposer.

Indeed. Try:

ViewComposer uninitialize.
IansVC initialize.

The icons in the system folder (and therefore the dynamically generated
tools menu) will always be associated with the tool as originally
registered. This may not always be what one wants, but on the other hand one
may still want access to both tools. I think perhaps that the
<installableSystemTool> protocol needs expanding to include a message such
as #isDefault: (and probably some supporting stuff for a default
implementation) to inform a tool class that its status as the default tool
is changing. This will allow it to completely supplant the existing tool
should that be desirable.

Regards

Blair