|
|
Pax,
> If you have dealt with DeafObjects and views, I would love to hear
> about it as it may help solve the current issues I am facing.
Only a little, I'm afraid. And I doubt if this will help much...
As far as I know live Views shouldn't normally hold a reference to a (or
rather "the", since there's only one) DeafObject.
Deaf objects are used as placeholders for Views while an MVP triad initialises
itself. First the Presenter is created and connected to a (possibly
pre-existing) model, and then the Views are created and linked in. Also, when
a Presenter is told that its View has been destroyed, it replaces its #view
with a reference to a DeafObject. So, although Presenters often have
references to DeafObjects, Views don't usually have them.
The only place I know of where a View /should/ hold a reference to a DeafObject
is after it has been destroyed (see View>>wmNcDestroy:wParam:lParam:), where it
sets its #presenter, #creationParent, and #interactor to DeafObject current.
One possibility (rather remote, I admit) is that as the EmbeddedDateTimePicker
executes #createEmbeddedIn: it is doing something which causes the control (or
some parent ?) to rebuild itself. Normally, when a View has to change some
aspect of itself which it isn't sure that the underlying Windows control can
change on-the-fly, it just saves its state, kills the current Windows control
(and subviews too, I think), then recreates it from the saved state. The
reason that /might/ be relevant is that #recreate causes
#wmNcDestroy:wParam:lParam: to be invoked when the View is temporarily
destroyed. /If/ something has gone wrong with the #recreate method, so that
for some reason it hasn't set the #isStateRestoring flag while it does this
stuff, then the code in #wmNcDestroy:wParam:lParam: will throw away the
reference to #presenter, #creationParent, and #interactor. So if you stepped
over that change, those three fields would suddenly be set to a DeafObject.
That's rather unlikely, since it depends on "something" having gone wrong with
#recreate. But, fwiw, I did once break #recreate myself accidentally (by
defining a useful "new" aspect called #placement and not noticing that it
overrode an important system method...). Also I think the code in View using
#recreate has changed a bit between D5 and D6, so it may be that something that
would have worked with D5 no longer works with D6.
-- chris
|
Locked
