Changing Views in an application

Further to the discussion in another thread, Andy Blower has confirmed that
what I did, which is effectively to use the CHB view as a template in the VC
to develop my own view, is legitimate. However, what I did was always
intended as just a first step to get me going, because I had so little
experience of developing in Smalltalk. The ultimate intention is to develop
my own view from scratch, though it will look quite a lot like the CHB view
because that is how my system is organised. I am now thinking of doing that
a bit sooner than I first thought, because my present view has too many bits
of its CHB ancestry hanging around, and I think it will be cleaner to design
it from scratch.

Another issue arises because for the first time today I saw my program
running on a wide screen system. I realised then that on systems like that
it would be better to use a layout like the Package Browser, with the
control panes on the left and the tabbed working area on the right. So I
will be developing an alternative view for systems like that.

Two questions arise:

a. How to switch my existing program from the present CHB-derived view to a
new view without fouling up the system. I would like to introduce the new
view as an alternative resource for my top-level presenter, and then delete
the old view when I am happy with the new one. I had a hard time getting the
present view to work in conjunction with the presenter. I remember the
crucial step was to execute a line of the form:
presenter addView: viewClass asResource: resourceName.
Will I have to do that again, and will I have to define my new view as a new
subclass of view?

b. How can I arrange a ToGo executable so that the user can select one of
two alternative views? I know that the View Composer offers two layouts, but
the choice is set outside the VC; can it be done within the application? I
have tried looking at the VC code to work out the trick, but I got lost. I
presume that I will have to use Packaged Class-Based Deployment, with a
Runtime Manager that chooses the appropriate view based on user preferences
(which I suppose I can store in a sort of .inf file which the session
manager reads at start-up). If this works, would it also be possible to
change views 'on the fly' in the program, with the system opening the new
view on the current model and closing the old view?

I know that's more than two questions, but it's really just two areas. I'd
be grateful for any comments, or pointers to available documentation.

Thanks

Peter Kenny

Peter,

Take a look at #show:on:, which allows you to specify the view resource
name.  Also see SmalltalkToolShell class>defaultView, which is a more
"global" way to specify a given view resource.


Have a good one,

Bill

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

"Peter Kenny" <[hidden email]> wrote in message
news:[hidden email]...

> Another issue arises because for the first time today I saw my program
> running on a wide screen system. I realised then that on systems like that
> it would be better to use a layout like the Package Browser, with the
> control panes on the left and the tabbed working area on the right. So I
> will be developing an alternative view for systems like that.

I have done some experiments (which no doubt I should have before I rushed
to post the above) and I think the problem can be redefined. I don't really
need the overhead of two views, because I can change the view
programmatically to achieve the effect I want. All that is necessary is to
find each ProportionalLayoutManager for any container view and reverse the
setting of the isVertical instance variable. I have just done it by
controlling a window from an  inspector, and I obtained exactly the effect I
wanted. It could equally be done for a ClassBrowserShell, which in some ways
is nicer if you want to see the method source for a long method (yes, I know
long methods are bad Smalltalk style!). So the only question on this front
is the mechanics of storing user preferences in a sort of .inf file, so the
user does not need to enter this parameter at each run.

Thanks, and sorry for not trying more before I asked

Peter

"Bill Schwab" <[hidden email]> wrote in message
news:cdm90h$12vo$[hidden email]...
> Peter,
>
> Take a look at #show:on:, which allows you to specify the view resource
> name.  Also see SmalltalkToolShell class>defaultView, which is a more
> "global" way to specify a given view resource.

Bill

Thanks for this; I posted my second message before I read this. I now have
enough to get ahead with what I want.

Peter

Peter,

> I have done some experiments (which no doubt I should have before I rushed
> to post the above) and I think the problem can be redefined. I don't really
> need the overhead of two views, because I can change the view
> programmatically to achieve the effect I want. All that is necessary is to
> find each ProportionalLayoutManager for any container view and reverse the
> setting of the isVertical instance variable. I have just done it by
> controlling a window from an  inspector, and I obtained exactly the effect I
> wanted.

Sometimes, things like this require a small nudge with the layout and/or
view contents.  If you have problems, you might start looking at
#invalidateLayout and #invalidate.  Based on a quick look at
#layoutManager:, I suspect you will _not_ have problems.


 > It could equally be done for a ClassBrowserShell, which in some ways
> is nicer if you want to see the method source for a long method (yes, I know
> long methods are bad Smalltalk style!).

IMHO, that depends on whether one is emulating Bach or Rachmininoff -
the latter is pointless without attention to phrasing, and that requires
a running start (or in code, "long methods").  No offense to Bach; both
styles have their places and merits.



 > So the only question on this front
> is the mechanics of storing user preferences in a sort of .inf file, so the
> user does not need to enter this parameter at each run.

You might want to look at my RegistryAspects package.  However, I always
seem to eventually regret doing anything "Microsoft's way", and using
the registry might turn out to be the most recent example.  I have a
program that refuses to run for restricted users, and guess what the
lead theory is ;)

With that said, the package is available to use if it meets your needs.
  I know you know this, but please be warned that editing the registry
can completely fry your windows installation, so please do not use
RegistryAspects if you are not comfortable with RedEdit, and just in
case, formatting hard disks, booting from CDs, etc.



> Thanks, and sorry for not trying more before I asked

We'll skip the court martial - this time :)

Have a good one,

Bill


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

"Bill Schwab" <[hidden email]> wrote in message
news:cdmhd6$rga$[hidden email]..
>
>  > So the only question on this front
> > is the mechanics of storing user preferences in a sort of .inf file, so
the
> > user does not need to enter this parameter at each run.
>
> You might want to look at my RegistryAspects package.
<snip>
>but please be warned that editing the registry
> can completely fry your windows installation, so ..

Bill

Thanks for the offer. However, since it would not be my registry that would
be fried, but that of my potential client, I would rather not risk it. I
will focus on producing a 'mini-registry' of my own to record the
preferences and set-up requirements of the individual user.

BTW, as you thought, switching the orientation of a proportional layout
seems to provoke a redraw in the new orientation without a nudge. Since two
changes are needed to produce the effect I want, however, I hide the view,
make the changes and show again with the new  view complete.

Peter

Hi Peter,

> ... storing user preferences ...

Might an ini file work for this?  I use ini files for app/user
options/preferences (avoiding the registry).  If so, there are at least two
ini wrappers out there that I know of.

-- Louis

"Louis Sumberg" <[hidden email]> wrote in message
news:[hidden email]...
> Hi Peter,
>
> > ... storing user preferences ...
>
> Might an ini file work for this?  I use ini files for app/user
> options/preferences (avoiding the registry).  If so, there are at least
two
> ini wrappers out there that I know of.
>
> -- Louis

Louis

Thanks for this. I realise that when I referred to .inf files in my exchange
with Bill, I really meant .ini files. What you describe sounds exactly what
I want. I had thought of having some kind of Smalltalk LookupTable recording
all the user preferences etc., which could be saved between sessions either
as Smalltalk code or as STB and read in at start up by the session manager.
However, if there is an .ini file system out there which provides this
ready-made I would like to try it. Could you give me a reference for the
systems you mention?

Many thanks

Peter.

Peter,

> However, if there is an .ini file system out there which provides this
> ready-made I would like to try it. Could you give me a reference for the
> systems you mention?

Take a look at the "Ini Files" link via
http://www.mindspring.com/~lsumberg/Dolphin.  There's a quick start section
to get you up and running, um, quickly, and there's a developer guide that
goes into detail regarding why and how I put the package together.  Any
questions, just ask.

I know someone else has also written a wrapper around the same Windows API,
but I don't remember who.

-- Louis

"Louis Sumberg" <[hidden email]> wrote in message
news:[hidden email]...

>
> Take a look at the "Ini Files" link via
> http://www.mindspring.com/~lsumberg/Dolphin.  There's a quick start
section
> to get you up and running, um, quickly, and there's a developer guide that
> goes into detail regarding why and how I put the package together.  Any
> questions, just ask.
>
Louis
Thanks - just downloaded it and it looks great. Your description of the
objectives matches exactly what I am trying to do.
Peter

Peter, Bill

> > but please be warned that editing the registry
> > can completely fry your windows installation, so ..
>
> Thanks for the offer. However, since it would not be my registry that
> would be fried, but that of my potential client, I would rather not risk
> it.

I don't understand this.  The /point/ of the registry is to store user
preferences (and other data) in a way that is quick and easy to access.
Dolphin's built-in access is even simpler, and /very/ handy.

It is certainly possible to write crap data to your registry, or to overwrite
important existing data -- but that's a /development/ issue.

Put it this way: if you daren't use the registry, then what about all the other
apps that do use it ?  And if they are all wrong, then there wouldn't be any
application data in the registry -- in which case why worry about frying it ?

    -- chris

Peter Kenny wrote:

> a. How to switch my existing program from the present CHB-derived view to
> a new view without fouling up the system. I would like to introduce the
> new view as an alternative resource for my top-level presenter, and then
> delete the old view when I am happy with the new one. I had a hard time
> getting the present view to work in conjunction with the presenter. I
> remember the crucial step was to execute a line of the form:
> presenter addView: viewClass asResource: resourceName.
> Will I have to do that again, and will I have to define my new view as a
> new subclass of view?

I don't know if this is still puzzling you, but for the record.

The only time when you need to use

    presenter addView: viewClass asResource: resourceName

is when you have defined a new /kind/ of View -- a new View class -- and you
want to add it to the corresponding Presenter class(es).  In by far the most
typical situation you don't do that because you are defining new view
/instances/ by assembling existing View resources into new combinations and
saving the new compound object as a new View Resource.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...

> I don't know if this is still puzzling you, but for the record.
>
> The only time when you need to use
>
>     presenter addView: viewClass asResource: resourceName
>
> is when you have defined a new /kind/ of View -- a new View class -- and
you
> want to add it to the corresponding Presenter class(es).  In by far the
most
> typical situation you don't do that because you are defining new view
> /instances/ by assembling existing View resources into new combinations
and
> saving the new compound object as a new View Resource.
>
>     -- chris
>
Chris
I can't say that it is still /puzzling/ me, in that I have achieved what I
set out to do when I asked these questions (i.e. I have a working view to my
new design). I am still at the stage where many things I do in Smalltalk are
'magic incantations', as one contributor put it, rather than things whose
effects I understand and can predict. But it is gradually getting clearer,
and this explanation adds a bit more to the picture, so thanks. My one minor
puzzle on this front is that I have finished up with a now redundant view
resource in my image, and despite searching all the menus I can't find how
to delete it. I'm sure it's obvious when you know, and it's not much of an
overhead in a 7MB image, but I would like to understand more what I'm doing.
Thanks

Peter

Peter Kenny wrote:

> and this explanation adds a bit more to the
> picture, so thanks.

You're welcome...

> My one minor puzzle on this front is that I have
> finished up with a now redundant view resource in my image, and despite
> searching all the menus I can't find how to delete it.

<chuckle/>

For some reason deleting Views is not a well-supported operation from the
Dolphin IDE; it is only available in one place, and that is a tool that you
hardly ever have to use /except/ to delete View Resources.

If you open the "Resource Browser" from any IDE tool (it's the toolbar button
that resembles a white US-style power plug, or a shaver plug), then you'll get
a list of View Resources.  From here you can delete or repackage whatever
Resources you need to.

(Incidentally, the resource "toolbox" that you select from when you are
assembling View Resources in the View Composer is the same tool with a
different front end implemented as a different View.  Which may be a source of
ideas or examples if you want to take your multiple-view design forward.)

    -- chris

Chris,

Agreed, but any time I point someone to my registry packages, I give the
"you can fry your machine" warning.  It just seems the fair thing to do.

Have a good one,

Bill


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