ShellView name

I'm trying to find a way at runtime to distinguish between multiple views on
the same Shell presenter.  For example, let's say I have a "Basic view" and
a "Default view" as the resource name strings.  At runtime, after the views
have been created, this information is not there.  I tried assigning a value
to the name aspect in the VC to each view, but that information is not
retained because it seems you can only assign a name to a subview, the
view's name being held in the parent view, and a ShellView's parent view is
DesktopView which doesn't hold this information.  I tried using the caption
as an id, but this too has its drawbacks, for example, DocumentShell changes
the caption to 'Untitled' in onViewOpened, and that's essentially where I
want to take action, after the "super onViewOpened" message send.

I've written an Ini class which provides a wrapper around the Windows
read/write profile string functions, and developed a framework for saving
and restoring view and presenter state in ini (text) files and it works fine
except for when there are multiple views on a presenter where it runs into
collisions because of the above problem.  The only way, or perhaps I should
say the cleanest way, I've found to access a unique name is by adding a line
of code (that captures the resource name string) to a couple of creation
methods (in Shell and Presenter) but I really really really hate to change
system methods.  Did I mention I really hate to change system methods?

Thanks for any help or ideas on this.

Louis

Louis Sumberg <[hidden email]> wrote in message
news:9c4uu9$bvlv6$[hidden email]...
> I'm trying to find a way at runtime to distinguish between multiple views
on
> the same Shell presenter.  For example, let's say I have a "Basic view"
and
> a "Default view" as the resource name strings.  At runtime, after the
views
> have been created, this information is not there.  I tried assigning a
value

I am not sure how "clean" this is, but you could use an invisible StaticText
with a standard name and the text attribute set to the view name.  I don't
think the visible attribute is available in the aspect editor, but you could
send the hide message to it via the aspect workspace.  I suppose you could
also make the extent = 0@0.  This does not seem that clean or generic, since
you would have to add this invisible StaticText you want to use.

I can see how it might be useful to have the original view name information
in the view instance.

Chris

Christopher J. Demers <[hidden email]> wrote in message
news:9c518n$c5b4l$[hidden email]...
> I can see how it might be useful to have the original view name
information
> in the view instance.

Actually I think I may have stumbled into a way to do what you want.  It
looks like RefferenceView _might_ solve your problem.  You could just use
the resourceIdentifier message perhaps.  This is rather speculative since I
only just started looking at RefferenceView myself.

Just thought I would mention it...

Chris

Chris, thanks for both suggestions, I appreciate that.  Unfortunately, I
think the first (adding an invisible control), while it would probably work,
is a bit heavyhanded as a solution.  I don't want to be saying "Hey, I got
this nice framework that lets you easily save and restore view state, and
all you have to do is add a control to your view and add some code to make
it invisible".  Kind of takes away from the simplicity of it all if you know
what I mean.  As for the second suggestion, I looked at definitions of and
references to #resourceIdentifier but it seems they are all in classes where
the resource is accessible, hence #resourceIdentifier can be easily sent, so
that won't work (unless I'm missing something, which is more than possible).
Good try, though.

To give you an idea what I mean by clean and simple, this thing is currently
set up so that for ANY application, if you add a method #iniEnabled that
simply returns true, it will save and restore view state, such as topview
position and size, listview column order and widths, widget arrangements
(where a splitter exists), and the selected tab (for card views) --
essentially, non-presenter-related view aspects.

-- Louis

Louis,

I don't think it's possible to access the resource name after a view has
been loaded and associated with a presenter. Offhand, I think you're going
to have to modify a system method (and, yes, you did say how much you don't
like to modify system methods). Perhaps the best way would be to replace
Shell>>createView: and then use #propertyAt:put: to save down the resource
name string as a property attached to the shell. You can later retrieve this
using #propertyAt:.

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

"Louis Sumberg" <[hidden email]> wrote in message
news:9c5abv$c286o$[hidden email]...
> Chris, thanks for both suggestions, I appreciate that.  Unfortunately, I
> think the first (adding an invisible control), while it would probably
work,
> is a bit heavyhanded as a solution.  I don't want to be saying "Hey, I got
> this nice framework that lets you easily save and restore view state, and
> all you have to do is add a control to your view and add some code to make
> it invisible".  Kind of takes away from the simplicity of it all if you
know
> what I mean.  As for the second suggestion, I looked at definitions of and
> references to #resourceIdentifier but it seems they are all in classes
where
> the resource is accessible, hence #resourceIdentifier can be easily sent,
so
> that won't work (unless I'm missing something, which is more than
possible).
> Good try, though.
>
> To give you an idea what I mean by clean and simple, this thing is
currently
> set up so that for ANY application, if you add a method #iniEnabled that
> simply returns true, it will save and restore view state, such as topview
> position and size, listview column order and widths, widget arrangements
> (where a splitter exists), and the selected tab (for card views) --
> essentially, non-presenter-related view aspects.
>
> -- Louis
>
>

Louis,

> I'm trying to find a way at runtime to distinguish between multiple views
> on the same Shell presenter.  For example, let's say I have a "Basic
> view" and a "Default view" as the resource name strings.  At runtime,
> after the views have been created, this information is not there.

How about keeping track of the view used when the shell is opened. You have
to know which view is being used at that stage, even if it is the default,
so just remember it is a property.

s := MyShell show.
s propertyAt: #currentView put: MyShell defaultView

or

s := MyShell show: 'Another shell name'.
s propertyAt: #currentView put: 'Another shell name'.

You can then get the name back at any stage by using ...

s #propertyAt: #currentView

<Warning> Those of a nervous disposition might prefer to close their eyes
while reading the rest of this post </Warning>

This also works (for ClassBrowserShell at least) but I shall say no more <g>

c := ClassBrowserShell show: 'Default view'.
(SessionManager current resourceManager resourcesForClass:
    ClassBrowserShell) associations detect: [:each |
        each value load allSubViews size = c view allSubViews size].
Answers ....'Default view' -> a ViewResource

c := ClassBrowserShell show: 'Basic class browser'.
[&etc]
Answers .... 'Basic class browser' -> a ViewResource

c := ClassBrowserShell show: 'Moening class browser'.
[&etc]
Answers .... 'Moening class browser' -> a ViewResource

Ian

Andy, thanks for the suggestions.  I wasn't aware of properties, but I am
now *s*.  I found a couple of references in DSDN as well as the writeup in
the Education Center.  It may well be that properties are less intrusive
than what I currently have, if one is to change a system method.  I'll take
a closer look.  As for Shell>>createView:, at the time I first wrote this
mechanism (a couple of months ago) it seemed like I actually had to go into
both Shell>>create: and Presenter>>create:on: because, as I recall, those
are the two creation methods that all or most of the other creation methods
go through.  I guess I'll check that again.

Regarding changing system methods, has there been a discussion of this?  For
example, I don't even know how I'd go about packaging something that has
changed system methods.  If I were to create an Ini package, I assume it
would have to include the changed create methods.  If someone were to
install the package, then uninstall it, it would delete the creation methods
from the image, wreaking subsequent havoc.  Perhaps here's where the
preinstall and so forth scripts come into play, though I haven't dealt with
them at all to date.

Thanks again.

-- Louis

"Andy Bower" <[hidden email]> wrote in message
news:9c5uv5$bu1bj$[hidden email]...
> Louis,
>
> I don't think it's possible to access the resource name after a view has
> been loaded and associated with a presenter. Offhand, I think you're going
> to have to modify a system method (and, yes, you did say how much you
don't
> like to modify system methods). Perhaps the best way would be to replace
> Shell>>createView: and then use #propertyAt:put: to save down the resource
> name string as a property attached to the shell. You can later retrieve
this
> using #propertyAt:.
>
> Best Regards,
>
> Andy Bower

Louis,

> Regarding changing system methods, has there been a discussion of this?
For
> example, I don't even know how I'd go about packaging something that has
> changed system methods.  If I were to create an Ini package, I assume it
> would have to include the changed create methods.  If someone were to
> install the package, then uninstall it, it would delete the creation
methods
> from the image, wreaking subsequent havoc.  Perhaps here's where the
> preinstall and so forth scripts come into play, though I haven't dealt
with
> them at all to date.

You might want to try Migrate, which is one of the goodies on my web site.
Please note that Migrate is provided without warranty of any kind, so make a
backup before you use it, just in case.

One of its tricks is to allow you to mark with one of two selectors you
specify, and to file these out independent of how they are packaged.  The
point of having two selectors is to distinguish between things that are
probably safe to file in, and things that might require some thought; you're
free to use only one selector if you wish.

In addition, Migrate will help you build a new image from packages by saving
a file describing all packages loaded into your current image.  That file
can be read into a copy of Migrate installed in your "next" image, after
which it can load all other packages.

Package scripts would probably also work.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill, thanks for the tip.  I installed the Migrate package but couldn't run
it, getting an stb version walkback (below).  This was in a fresh 4.01.1
image.

-- Louis

2:10:25 PM, Wednesday, April 25, 2001: 'Index 18 is out of bounds'
Array(Object)>>errorSubscriptBounds:
Array(Object)>>errorAt:
Array(ArrayedCollection)>>at:
Array(SequenceableCollection)>>replaceFrom:to:with:startingAt:
TabView class(IconicListAbstract class)>>stbConvertFromVersion9:
TabView class(IconicListAbstract class)>>stbConvert:fromVersion:
TabView class(View class)>>stbConvertProxy:
STBViewProxy>>stbFixup:at:
STBInFiler>>basicNext
STBInFiler>>readObjectOfClass:
STBInFiler>>basicNext
STBInFiler>>readObjectOfClass:
STBInFiler>>basicNext
STBInFiler>>readObjectOfClass:
STBInFiler>>basicNext
STBInFiler>>readObjectOfClass:
STBInFiler>>basicNext
STBInFiler>>readObjectOfClass:
STBInFiler>>basicNext
STBInFiler>>next
ResourceSTBByteArrayAccessor>>loadWithContext:
ViewResource(Resource)>>loadWithContext:
ResourceIdentifier>>loadWithContext:
Migrate class(Presenter class)>>loadViewResource:inContext:
Migrate class(Shell class)>>create:
Migrate class(Presenter class)>>show:

Louis,

Sorry about the problems.  I've emailed you something that might do better,
and if not, I'll have a look at it later.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]