[PL4] STBViewProxy problem

Hi,
    I met the same problem ( STBViewProxy error) when reinstalling my
project into fresh PL4-patched D5 image/XP. This error seemed the same
as what Chris described at the post on 3/20 "STBViewProxy error while
applying PL4 to virgin image..."  ( Walkback dump attached the rear
end).
   The views of the persistent shells in my project could no longer be
edited in the VC after PL4 patched, the error message said " STBFiler
STB contains a version 1 instance of ScrollingDecoratorLayout and is
unable to convert it."
   It is said that there is "a small modification to a number of view
resources, such as the PL4 modification to the default heights of the
text presenter single line views."  
   How could I overcome this condition? Will it work that I first
reconstruct my views with the new modification in the old image before
applying PL4 patch? How to do it manually?
   It is a great suffering if the same condition would hinder my
system  from going updated automatically and smoothly  from D5 to D6,
as before ( D4-> 5). In that case, it will cost me a lot of work in
rewritting the views and manually coding all the codes?

TIA
Francis Kuo

=================================
Here is the walkback dump:
   STBViewProxy(Object)>>doesNotUnderstand:
   CardContainer>>layout
   CardContainer(View)>>validateLayout
   CardContainer(ContainerView)>>validateLayout
   [] in ContainerView>>validateLayout
   OrderedCollection>>do:
   ContainerView>>validateLayout
   [] in ContainerView>>validateLayout
   OrderedCollection>>do:
   ContainerView>>validateLayout
   ProportionalLayout>>layoutContainer:
   ContainerView>>layout
   ContainerView(View)>>validateLayout
   ContainerView>>validateLayout
   [] in ShellView(ContainerView)>>validateLayout
   OrderedCollection>>do:
   ShellView(ContainerView)>>validateLayout
   [] in ViewComposerArena(ContainerView)>>validateLayout
   OrderedCollection>>do:
   ViewComposerArena(ContainerView)>>validateLayout
   [] in ContainerView>>validateLayout
   OrderedCollection>>do:
   ContainerView>>validateLayout
   [] in ScrollingDecorator(ContainerView)>>validateLayout
   OrderedCollection>>do:
   ScrollingDecorator(ContainerView)>>validateLayout
   [] in ContainerView>>validateLayout
   OrderedCollection>>do:
   ContainerView>>validateLayout
   ProportionalLayout>>layoutContainer:
   ContainerView>>layout
   ContainerView(View)>>validateLayout
   ContainerView>>validateLayout
   [] in ContainerView>>validateLayout
   OrderedCollection>>do:
   ContainerView>>validateLayout
   ProportionalLayout>>layoutContainer:
   ContainerView>>layout
   ContainerView(View)>>validateLayout
   ContainerView>>validateLayout
   [] in ShellView(ContainerView)>>validateLayout
   OrderedCollection>>do:
   ShellView(ContainerView)>>validateLayout
   ShellView(View)>>ensureLayoutValid
   ShellView(View)>>wmPaint:wParam:lParam:
   ShellView(View)>>dispatchMessage:wParam:lParam:
   [] in InputState>>wndProc:message:wParam:lParam:cookie:
   BlockClosure>>ifCurtailed:
   ProcessorScheduler>>callback:evaluate:
   InputState>>wndProc:message:wParam:lParam:cookie:

Kuo,

Please see my new post regarding a fix for the Live Update process in
Dolphin 5.1. Hopefully, you have a backup image so you can go back and
apply the new fix and then run the LU procedure again.

Best regards

Andy Bower
Dolphin Support
www.object-arts.com

"kuo" <[hidden email]> wrote in message
news:[hidden email]...
>...
>    It is a great suffering if the same condition would hinder my
> system  from going updated automatically and smoothly  from D5 to D6,
> as before ( D4-> 5). In that case, it will cost me a lot of work in
> rewritting the views and manually coding all the codes?

In moving from D5 -> D6 there will be an automatic conversion of old view
resources as in the past. However because of the change to full lexical
closures the bytecode set has been changed. In order to support the
conversion of old format methods in resources (usually present because of
blocks such as the getText/Image blocks of ListViews, etc), and other STB
files, D6 includes a rewriter which interprets the D5 bytecodes and rewrites
them as a D6 method. The rewritten method will preserve the block semantics
of D5. This means that rewritten blocks will not be as efficient as those
compiled directly in D6. It also means they will not benefit from D6's
closure semantics, such as the lifetime of block arguments being limited to
an individual block activation. Lastly this rewriting is done as an
on-the-fly STB conversion, and takes time, making the views slower to open.

In order to perform a more satisfactory conversion of views into D6 format
it is necessary to "upgrade" them. In most cases this can be done by loading
them into the view composer and resaving them, or by using the new
"Upgrade/Resave" command in the Package Browser's resources pane. The
"upgrade" process will attempt to recompile any blocks held in the
resources, but in some cases it will not be able to do this. Examples are
where the blocks assign to block arguments (a common workaround for the
problem of the Smalltalk-80 style blocks retaining a reference to the last
argument values passed in), which is illegal in D6, or where the source of
the block is not available (e.g. where the block was returned from a
method). In these cases manual intervention will be required to recreate the
block, although the resource would still be usable with the rewritten block
which will be created during the upgrade process if recompilation is not
possible.

As usual in our major releases, there are also some breaking changes in D6
that may require changes to applications so that they continue to work. We
don't believe that it is appropriate to maintain complete backwards
compatibility in major releases, because to do so tends to stifle the
product. Instead we try to maintain backwards compatibility except where we
believe the design must change to correct past mistakes and improve the
product. The release notes will detail all such breaking changes that we are
aware of, though there may be other effects that we could not anticipate.
Either way support will be available via this newsgroup in the normal way.

I know this information is not directly relevant now, but I thought it might
be useful to let people know what can be expected when migrating packages to
D6.

Blair

Blair McGlashan wrote:

> The rewritten method will preserve the
> block semantics of D5. This means that rewritten blocks will not be as
> efficient as those compiled directly in D6. It also means they will not
> benefit from D6's closure semantics, such as the lifetime of block
> arguments being limited to an individual block activation. Lastly this
> rewriting is done as an on-the-fly STB conversion, and takes time, making
> the views slower to open.

If you aren't doing so already, if might be worthwhile writing a message to the
Transcript when this happens, identifying (not entirely trivial, iirc) the
block that's being munged.  Or at least have an option to do so.

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Blair McGlashan wrote:
>
> > The rewritten method will preserve the
> > block semantics of D5. This means that rewritten blocks will not be as
> > efficient as those compiled directly in D6. It also means they will not
> > benefit from D6's closure semantics, such as the lifetime of block
> > arguments being limited to an individual block activation. Lastly this
> > rewriting is done as an on-the-fly STB conversion, and takes time,
making
> > the views slower to open.
>
> If you aren't doing so already, if might be worthwhile writing a message
to the
> Transcript when this happens, identifying (not entirely trivial, iirc) the
> block that's being munged.  Or at least have an option to do so.

It would have to be optional I think, otherwise one will get a flood of
information one doesn't necessarily want. For example my image contains a
number of third-party add-ons, such as DSDN, that have D5 format views in
them. I prefer to leave these unchanged, so I don't really want to be told
that the STB conversion is occurring.

Its easy to locate old format blocks in resources anyway, by browsing for
resource references to the MethodContext class, which is still present in
the image in stub form to assist loading of old resources. New resources
will not contain any MethodContext instances.

Regards

Blair

On Mon, 05 Apr 2004 16:07:13 +0800, I <[hidden email]> wrote:     The problems were soleved.
     I started from a new fresh PL4 patched image and loaded
prerequisited packages step by step. It turned out that some reference
views of my my persistent  views could not be converted while opening
in VC.  
    Further workups showed that I versioned my package without notice
that some reference views in it were not packaged and  thus remained
**unpackaged** .
   When I reloaded that package via STS project edition bowser, those
supposed referenced views  had problems in conversion ( due to status
of being **unpackaged**) , causing later VC errors consequently.
    Now, my system is running again stably.

Thanks.
kuo