Cannot save package

I tried saving a package that I've been working on and have saved before in
D5 and I get a dialog box with title "Cannot save package [My Package]" and
then takes me to the pre-reqs.  I don't think I've introduced any cyclic
dependencies, but who knows.  In the treeview for package prerequisites, I
checked each major subnode, looking at the rightmost column in the listview
below (i.e., Prerequisite Object) for My Package, but it wasn't there, which
I think means it should work.  Any ideas?

-- Louis

Louis,

> I tried saving a package that I've been working on and have saved before
in
> D5 and I get a dialog box with title "Cannot save package [My Package]"
and
> then takes me to the pre-reqs.  I don't think I've introduced any cyclic
> dependencies, but who knows.  In the treeview for package prerequisites, I
> checked each major subnode, looking at the rightmost column in the
listview
> below (i.e., Prerequisite Object) for My Package, but it wasn't there,
which
> I think means it should work.  Any ideas?

Depending on what you mean, you might have to drill down further - some
other package further down the line might cycle back  If it is a cycle, I'd
be interested in knowing whether Migrate's cycle detection catches it (see
my post on April 8th).  So as to not imply any false promises, all Migrate
can do is tell you there is a cycle and which packages are involved - it
doesn't make an effort to find the cause.  Probably the most common way that
I introduce cycles is in writing test cases, and the new behavior for
packaging of methods dropped on a class is likely to cause cyclic chaos
(IMHO).

Have a good one,

Bill

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

Bill,

> <snip> the new behavior for
> packaging of methods dropped on a class is likely to cause cyclic chaos
> (IMHO).

That was it.  I I had created a new presenter class and dragged over a few
methods from Presenter in order to override them.  The new methods were
packaged as loose methods in the Dolphin MVP Base package rather then in the
new presenter class.  I discovered this through the Source Browser.  I don't
like this new behavior so much -- I know there's been discussion on this but
I haven't followed it closely enough to really make more of a comment -- I
suppose I'll get used to it if it stays.

I'd like to give Migrate another try, but I'll admit it's not high on my
(rather large) todo list.  In this particular case, it sounds like I
wouldn't have gotten information any more specific than the Package Browser,
i.e., something's wrong with XYZ package, but not pinpointing what.

As an added note, thank you, Blair, for implementing the full categories
list when showing inherited methods.  I found it very handy with the new
presenter, e.g., looking at initializing and then dragging over a couple of
methods from Presenter, overriding them in the new class, looking at event
handling and doing the same, etc.  This approach makes it easier to identify
what methods I need to override in the new class, ensures that they're in
the proper category, and is a great way to browse a class' full behavior by
category.  (Of course, due to the above problem/issue, I suppose drag and
drop needs to be accompanied by a package change on the method or, instead
of drag and drop, doing a cut and paste into the new method.)

-- Louis

Hey Louis,

Read the messages, will ya!

> <snip>.  (Of course, due to the above problem/issue, I suppose drag and
> drop needs to be accompanied by a package change on the method or, instead
> of drag and drop, doing a cut and paste into the new method.)

Ok, ok, I just saw Blair's explanation of what'll be in the final release
and it looks like this won't be an issue.  Hurrah!!!

-- Louis