Hello all,
The good news is "I found it"; the bad news is that I'm not sure what
happened.
The short version is that I revisited my app with the automatically
generated GUI. Required modifications included adding some scrolling
decorators (which altered the generator itself) and adding some new controls
(add the meta data and the generator does the rest). The generator ran, and
the result didn't :) There was a problem with the presenter that received
new sub-presenters, and it had something to with the view not being
connected.
Obvious things to think about with a view not being connected are more or
less: names not matching; override of incorrect method, failure to super
send, etc. The generator should take care of all of that, or at least
should botch it uniformly. But, the problem was with one particular
presenter; all of the others worked as before.
My first clue should have been that Browse|References didn't find any
references to the affected presenter class. I didn't pay much attention to
it because the generator uses a large number of class names to allow it to
work whether or not the classes it creates already exist. After some hours
of trying to put a conditional breakpoint in just the right spot, I noticed
that one of the peer classes did have references, and the immediate cause
became clear. Recompiling the method that references the classes fixed the
problem.
I use
#subclass:instanceVariableNames:classVariableNames:poolDictionaries:classIns
tanceVariableNames: to add/modify classes. Is there any danger in that? In
particular, do I need to "bang on the box" afterward?
Have a good one,
Bill
--
Wilhelm K. Schwab, Ph.D.
[hidden email]
Locked
