Programmatic saving of view resources

Andy/Blair,

I have some view resources that hold objects of my own, and it sometimes
becomes necessary to change the instance variable layouts.  STB conversion
methods take care of it, but, the problem is that without resaving all
affected views, the STB conversion methods run every time one of the views
is opened.  It's easy enough to open/save each view, but, it's even easier
to miss some of them :)

For some time now, I've wanted a way to programmatically save view
resources.  Facing yet another iv layout change, I took another look at the
problem, and finally realized (well, convinced myself anyway) that it would
be necessary to open the view.  That sounded a lot like a poor-mans's view
composer, so why not use the real thing:

   | vc |
   vc := ViewComposer show.
   vc openOn:( ResourceIdentifier class:QuickCodeShell name:'DefaultView' ).
   vc viewSave.
   vc exit.

Is this legal?  Should there be any use of deferred actions or other
measures to avoid gottchas?

Have a good one,

Bill

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

Bill

You wrote in message news:99qd7g$29l2d$[hidden email]...
> ....
> For some time now, I've wanted a way to programmatically save view
> resources.  Facing yet another iv layout change, I took another look at
the
> problem, and finally realized (well, convinced myself anyway) that it
would
> be necessary to open the view.  That sounded a lot like a poor-mans's view
> composer, so why not use the real thing:
>
>    | vc |
>    vc := ViewComposer show.
>    vc openOn:( ResourceIdentifier class:QuickCodeShell
name:'DefaultView' ).
>    vc viewSave.
>    vc exit.
>
> Is this legal?...

We do it in a very similar way, using this utility method in fact:

resaveAllViews
 "Private - Load all view resources into the ViewComposer and resave them

 self resaveAllViews
"

 | vc |
 vc := Smalltalk developmentSystem openViewComposerEmpty.
 SessionManager current resourceManager allResourceIdentifiers do: [:rid |
  vc openOn: rid; fileSave.
  MemoryManager current collectGarbage; administerLastRites ].
 vc exit.
! !

The explict garbage collection is a hang over from the days before the
finalization queue had a high-water mark. In those days this method would
have quickly exhausted all resources on a Win95/98 box.

>...  Should there be any use of deferred actions or other
> measures to avoid gottchas?

Only the same caution that one sees before TV programs that include
stroboscopic lighting effects :-).

Regards

Blair