Resource D5 -> D6 migration

Hi all,

 I re-read the newsgroup in search of clues about migration of
resources from D5 to D6. The conclusion I came now, beside it is
probably the most expensive part of the migration, is that one should
be prepared to deal strong with STB filing mechanism if wants one's
resources to be imported to D6.

 Right now, as a STB begginer, I have two questions:

A) It is possible to upgrade a resource that cames in a D5 .pac wich
it's load in D6 throws an error of this kind:"!STB  contains a version
9 instance of EmbeddedTextEdit and is unable to convert it." ?

B) If it is posible I guess one have to customize certain STB parts to
archieve the resource intantiation, what would you recomend as a start
in this regard?

 Any help would be appreciated,

 thank you,

Sebastian
PD: the error I've mentioned appears when loading a view that has a
listView with editable list view columns. I know this is not D6
standard (in fact is in a port of a goodie from Jhon Aspinall's site)
but that package is allready loaded and the resource is still not
loading. Even with the class shape wich is envolved is not changed at
all. I think the problem could be in the blocks, but I don't really
know what to do in that regard. The solution I'm trying to make is
about teaching D6 to upgrade automatically this kind of resource
because I have lot's of them (too much to be made by hand).

Sebastián,

> PD: the error I've mentioned appears when loading a view that has a
> listView with editable list view columns. I know this is not D6
> standard (in fact is in a port of a goodie from Jhon Aspinall's site)
> but that package is allready loaded and the resource is still not
> loading. Even with the class shape wich is envolved is not changed at
> all.

There are some problems loading and using ELV caused by the way that John has
(correctly IMO) side-stepped the normal STB path in some cases.  For instance
EmbeddedTextEdit overrides stbSaveOn:

=====================
stbSaveOn: anSTBOutFiler

 "If the receiver is unrealized (i.e. just exists in the spec of a column in
 the view composer), save as a plain object"

 handle isNil
  ifTrue: [anSTBOutFiler saveObject: self]
  ifFalse: [super stbSaveOn: anSTBOutFiler]
=====================

The idea is that in the case where an instance is being used as a mere "spec",
it doesn't STB itself via an STBViewProxy (since they "know" that their views
should be restored as Windows objects when they are de-STBed).  (Arguably, it
would have been better to use a custom proxy class instead of using STB "raw"
in this case).  All the Embedded* classes use the same technique.

That causes problems when one of John's Embedded* classes is de-STBed in D6.
The version number for View (and so on) has changed, so (unlike when using D5)
the STB conversion code is invoked.  And that's where the problem is -- View's
"know" that they are STB-ed via the STBViewProxy mechanism, and so they don't
provide a normal implementation of version updating (arguable an omission from
View), and so the resources from the D5 packages won't load.

As a workaround, if you add:

=====================
stbConvertFrom: anSTBClassFormat
 "answer a Block that will convert an old version repesented as an Array to the
 current version"

 "generic implementation that will just result in default values in any missing
 slots and which assumes instances never shrink as versions increase"
 ^ [:slots || new |
  new := self basicNew.
  1 to: slots size do: [:i | new instVarAt: i put: (slots at: i)].
  new].
=====================

to the class-side of each of the Embedded* classes, then the resources will be
converted automatically.  NB: that is /only/ a hack -- a proper solution would
require more thought (though, after some thought, it might turn out that the
hack was adequate ;-)

You can, I think, add those methods in D5 before loading John's stuff into D6.

BTW, a couple of other changes have to be made:
+    all occurrences of:
            self largeImageExtent
      should be replaced by:
            self largeIconExtent
+    all occurrences of:
            self smallImageExtent
      should be replaced by:
            Icon smallExtent

There is also a problem with selection -- since the ListView stuff has changed
its approach to multiple-selection completely, John's stuff (like my
TreeListView, unfortunately[*]) should be redesigned in tandem.  I haven't
attempted to do that, but making one change, replacing the literal 0 in
EditableListView>>handleSingleSelection: to
    self noSelection
will at least stop one category of walkbacks.

    -- chris

[*] There are so many breaking changes in D6 that it looks as if updating my
stuff will take a great deal of work -- I'm currently putting that off[**], and
it may be months before I get around to committing to D6, and it's only then
that I'll start the porting process.  If anyone wants to distribute updated
versions of anything of mine in the meantime, then please feel free.

[**] Indeed I'm even questioning whether it's actually worth my while to switch
to D6 at all.

Chris,

  first of all, thank you very much for your detailed response.

  After some frustation (even with your support) to get loaded those
resources automatically and still having to resolve the situation, I
came to the conclusion that those controls doesn't worth to be
migrated. So I have "open my hand" on them. I have do that because I
found that they are easily replaced by simple standard presenters. For
example an editable record in a list can be replaced by a sequence of
prompters or checkboxes by icons representing state. Is not so fashion
as one wants today but it works flawlessly, all indicates that future
maintenance would be cheaper and compatibility is guaranteed.

 So I've counted exactly how many resources do I actually have in D5
and happily found that, on the contrary of I was thinking before, there
was only a few. So I've simply deleted the editable lists in them and
resaved the packages.

  Then I've imported them flawlessly. Now I can freeze my D5 develops
and keep a backup for reference and get all the efforts turn to D6.

  Best regards, and thank you again,

Sebastian