Before this idea gets finalized

Andy,

Appologies for posting this too soon, but, I'm afraid that I lose track of
it if I wait to clean it up.

BACKGROUND, ETC.
================
My pen-based app has been in "kinda-sorta-production" for almost a year now,
and has been used steadily by some users for well over six months.  We've
pounded out various problems and have improved the user interface (well, all
except for one recent change, I'm told<g>), etc..  Now I'm trying to get it
ready to face large numbers of less experienced users =:0

This gizmo does a lot, and users tend to interact with it intermittently,
but, with a purpose, especially just before completing their work.  It got
into a little trouble just this past week, and something about it made me
think of delayed finalization - well, finalization occuring too late to do
any good with respect to GDI resources.

Ironically, a brief misdiagnosis on my part got me to look in the right
place to see that I was stranding large number of Region instances, and LOTS
of brushes.  So, I've been going on a somewhat fun (not sure why, but, it
is) hunt for the offending parts of the system.  I realize that explicitly
#free-ing things that might be captured and used elsewhere is a shortcut to
disaster; but, the code that I'm changing really can (and should) clean up
after itself.


SHELLS AND VIEW COMPOSER
=========================
In the course of all of this, I've come to suspect (things behave
differently when I edit views than show them, hence the suspicion) that the
view composer strands some regions; perhaps this is the cause of some
problems that I've had with it on really complex views????   If the number
of finalizable regions is related to the number of sub views, that might
explain what I saw.

The other half-baked item I have for you is this: I've noticed that Shells
seem to discard an icon almost immediately after they are displayed.  It
seems highly unlikely, but is there a missing reference to them?  Most
likely, they are copied (with Windows keeping the copy) and the original
correctly discarded, but, it might be worth a quick look.

Have a good one,

Bill

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

Bill,

> In the course of all of this, I've come to suspect (things behave
> differently when I edit views than show them, hence the suspicion) that
the
> view composer strands some regions; perhaps this is the cause of some
> problems that I've had with it on really complex views????   If the number
> of finalizable regions is related to the number of sub views, that might
> explain what I saw.

Hmm.. are you saying that the View Composer gradually loses region handles
as it is used? I don't see any reason why this should be (naturally,
otherwise we would have fixed it before now). In the development system,
Regions are only used by the View Composer and only for the selection
handles. One region is used for all of the handles currently displayed. That
is, in a steady state (after finalization has been allowed to run) you
should only have one Region instance per invocation of the View Composer.

I've just tried a simple test and the number of Region *instances* doesn't
appear to grow even when editing some fairly complex views. Are you losing
Region instances (i.e Region allInstances sizes continues to grow) or are
you looking in the Windows GDI (is it?) heap and seeing the number of
regions handles increase? Have you a snippet of code (or better still an
SUnit test) that exhibits the problem?

> The other half-baked item I have for you is this: I've noticed that Shells
> seem to discard an icon almost immediately after they are displayed.  It
> seems highly unlikely, but is there a missing reference to them?  Most
> likely, they are copied (with Windows keeping the copy) and the original
> correctly discarded, but, it might be worth a quick look.

Once again, have you a code snippet that demonstrates this?

Best Regards,

Andy Bower
Dolphin Support
http://www.object-arts.com

---
Visit the Dolphin Smalltalk WikiWeb
http://www.object-arts.com/wiki/html/Dolphin/FrontPage.htm
---

Andy,

> Hmm.. are you saying that the View Composer gradually loses region handles
> as it is used? I don't see any reason why this should be (naturally,
> otherwise we would have fixed it before now). In the development system,
> Regions are only used by the View Composer and only for the selection
> handles. One region is used for all of the handles currently displayed.
That
> is, in a steady state (after finalization has been allowed to run) you
> should only have one Region instance per invocation of the View Composer.

I'm not saying that they are lost, only that they are left for finalization
instead of being explicitly freed.  If you use something like

GraphicsTool>>finalize
 "Notification signal: 'Finalizing ', self printString."
 KernelLibrary default outputDebugString:self printString, String
lineDelimiter.
 self free

then open a VC and choose, for example, the new dialog view command, you
should see some finalized regions, quite a few brushes, and the a couple of
shell icons (as mentioned below).  I'm finding that this kind of thing
requires care on Win9x, because problems might start before finalization has
a chance to free the objects.  So, *if* the number of regions that are
finalizable depends on the complexity of the view, this and/or the brushes
might explain some of the VC crashes that I've seen over time.  Please
understand that this is NOT a continuing problem; there have been a few
isolated (but reproduceable) crashes with complex views, and there's always
been a way to work around it.

Of  course, not all finalization is bad, and freeing things that might end
up being used elsewhere is a great way to get into trouble.  I've been going
over my code to free things that I know are never going to be used again.

One thing that strikes me about this is that it might be nice to have a new
Color subclass that answers stock brushes in response to #brush - that would
allow things like the control color messages to work safely but (I think)
reduce the resource consumption and avoid the need for calls to free the GDI
objects, since stock objects don't own their handles.  I'd gladly evaluate
expressions in a workspace to get the benefit.


> > The other half-baked item I have for you is this: I've noticed that
Shells
> > seem to discard an icon almost immediately after they are displayed.  It
> > seems highly unlikely, but is there a missing reference to them?  Most
> > likely, they are copied (with Windows keeping the copy) and the original
> > correctly discarded, but, it might be worth a quick look.
>
> Once again, have you a code snippet that demonstrates this?

In this case, I seriously doubt that anything is wrong, but, it struck me as
odd, so I thought I'd mention it.

Have a good one,

Bill

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