View resource problem?

Andy/Blair,

I think I've found a bug.  This came out of more work on my automated code
generator, acting on some of Ian's suggestions.  Knowing that problems could
result, I fiddled a lot with the IDE, and got a walkback.  Just for the DLL
of it, I tried to reproduce the problem using only the development tools,
and was able to do so.  Of course, it's possible that I fried my image a
while ago and it's only starting to show up now.  Howver, I was able to do
the same thing to a PL1 image saved before I had done any auto generation.

Ok, here are steps to reproduce the possible bug:

(1) CompositePresenter - use the CHB to add a subclass called
BugMaybePresenter.
(2) Via CHB ctx menu, open a new view for BugMaybePresenter; leave the VC
open.
(3) Add an iv to BugMaybePresenter; re-accept (in the same CHB).
(4) Save the view in the VC; it will do a save-as, keep the name 'Default
view'; close the VC.
(5) Add BugMaybePresenter to a package; (right click in package manager
classes pane, just in case it matters)
(6) Delete BugMaybePresenter in CHB - walkback.

The problem seems to be with removing the view resource.  Can anybody else
reproduce this?  If so, I'd suggest that you not save the resulting image.

Have a good one,

Bill


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

Andy and Blair,

The time came to remove some things that were being replaced by the
auto-generated code and views.  There were just enough of these things that
it seemed worthy (especially since I'll be changing my mind again many times
before this is over) of a class method that can be invoked to do the
cleanup.

The cleanup method starts with two likely base classes, and then scans their
subclasses for references, skipping any that are referenced.  Despite this
protection, I expected (and think I experienced) problems with view
resources that pointed to the removed classes.

Re deleting the unwanted presenter classes, I found that at least some of
the them complained as I reported before.  I was ready for it, but, not
really expecting to see this because I thought all of the classes/views were
generated before I got far enough to hit the problem scenario.  On a second
try (w/o saving the image after the failures), removing the offending view
resources using the ResourceBrowser seemed to fix it.  After that, the
presenter classes went away quietly.

Then I came to "the" composite presenter.  It was a monster with lots of
tabs (some of which had wizard card containers built into them) and used
reference views to load some of the now removed presenters.  I had commented
out part of its #createComponents method to "release" the other presenter
classes, but, was curious what would happen with the views.  I knew that the
view wouldn't load, but, I wasn't expecting a different problem: I got
walkbacks (almost a recursive meltdown) when trying to add a new view
resource to the class.  Again, removing the view using the ResourceBrowser
_appears_ to have fixed it, but, I haven't done much since that point.

Some of this might be considered an argument in favor of code vs. prototype
objects for view resources.  Not only would the references have detected the
dependence of the remaining presenter's views on the removed classes (I was
aware of it even though Dolphin didn't appear to notice), but, the repair
would be as simple as deleting a method.  Fortunately, the ResourceBrowser
was able to cleanly delete things that had to be removed.  If nothing else,
please consider this a testimonial for the ResourceBrowser :)

Have a good one,

Bill


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

Bill

You wrote in message news:9ilf6q$7ct$[hidden email]...
Thanks for the report. This is a known problem (I believe Ian reported it in
a posting on 26th March and it is recorded as defect 156) that shows up when
a packaged class with resources is deleted and that package is currently
selected in the package browser. Here is my analysis from the bug report:

"This is an event sequencing problem. The Resource Manager responds to the
removal of the class first, and removes associated resources, triggering
further events. The Package Browser responds to these before the package has
been updated, and hence the package is in an invalid state and when the PB
attempts to enumerate the classes, it fails."

To avoid the problem, make sure the package browser is not left open on the
package when one is deleting classes with resources (a rare event
thankfully). Should one forget, then it can be recovered from by using
debug/return to skip out of the package browser's update handling to allow
the event to find its way to the package.

Regards

Blair

Hi Blair,

> Thanks for the report. This is a known problem (I believe Ian reported it
in
> a posting on 26th March and it is recorded as defect 156) that shows up
when
> a packaged class with resources is deleted and that package is currently
> selected in the package browser. Here is my analysis from the bug report:

Thanks to you (and to Ian via email) for confirming that it's not something
weird about my image.


> To avoid the problem, make sure the package browser is not left open on
the
> package when one is deleting classes with resources (a rare event
> thankfully).

That's an Interesting way to look at it; it also summarizes the answer to
"why now?".  This is one of those bugs that seems like it should be
difficult to miss, but, you're right that classes with (complex anyway) view
resources get renamed or moved far more often than deleted.  If I do discard
them, it's usually by saving and then uninstalling a package.  However,
given that I had a tool that was spewing new classes and view resources, and
was using the package browser to round them up for orderly disposal, I fell
right into it.


> Should one forget, then it can be recovered from by using
> debug/return to skip out of the package browser's update handling to allow
> the event to find its way to the package.

Thanks for the tip.

Have a good one,

Bill

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