Does STBInfiler destroy schematic wiring?

I have just spent several hours finding a way round a problem in an app I am
developing. The job is being done using the MVP framework (I hope!), and I
have a 'createSchematicWiring' method in the presenter to create links
between model and view. I have used STB to file out the entire model between
sessions - I intend to be able to choose between several alternative models
when starting a session. If I have not filed in a model in a session, but am
creating a new model from scratch, all the events in the model trigger
changes in the view as required. However, if I have filed in a model nothing
is triggered. I tried sending 'createSchematicWiring' to the presenter
again, and the triggering worked again.

So I have worked round my problem. I just include 'self
createSchematicWiring' as the last line of the method which reads in the
model using STBInFiler, and all is well. My question is: should I have known
this in advance? I have looked around the documentation on STB and I cannot
find anything relevant. Is this a known feature of Dolphin? (I am using DVE
5.1.4)

Thanks for any help

Peter

Peter

Yes, what you have seen is by design. No events registrations are saved
by the STB out filer (hence none are restored). Chris Uppal explains
the reasoning behind this quite well in this newsgroup posting pulled
from Google groups:

http://groups.google.com/groups?q=dolphin+STB+events&hl=en&lr=&ie=UTF-8&
selm=WYqdnQcPNebnYh3dRVn-hw%40nildram.net&rnum=1

A bit more detail is given by Blair in this post:

http://groups.google.com/groups?q=dolphin+STB+events&hl=en&lr=&ie=UTF-8&
selm=b160p2%24vkm54%241%40ID-50941.news.dfncis.de&rnum=3

Best regards


Andy Bower
Dolphin Support
www.object-arts.com

Peter,
I've just thought of a bit of extra info that might be useful to you.
Overriding #createSchematicWiring is only really intended for event
registrations between the presenters themselves. If you want to hang
off events triggered by the model then you should perform the
registrations in the presenter's #model: method after the new model has
been assigned to the presenter.

Best regards


Andy Bower
Dolphin Support
www.object-arts.com

"Andy Bower" <[hidden email]> wrote in message
news:[hidden email]...
> Peter

Thanks for this. I am still coming to terms with Smalltalk, so this is part
of the education process. If I can, there is a supplementary idea which I
thought of just after my previous post. If I filed out the essential parts
of the model (which means just a text title and an OrderedCollection of
components), presumably filing those in would replace just those parts of
the model, not the whole thing, so the previously established events would
not be upset. In other words, my problem was caused by my laziness in not
typing two nextPut:s rather than one. I haven't tried this yet (supper break
since my last post!), but would it work?

Thanks

Peter

Peter,

> Thanks for this. I am still coming to terms with Smalltalk, so this is part
> of the education process. If I can, there is a supplementary idea which I
> thought of just after my previous post. If I filed out the essential parts
> of the model (which means just a text title and an OrderedCollection of
> components), presumably filing those in would replace just those parts of
> the model, not the whole thing, so the previously established events would
> not be upset. In other words, my problem was caused by my laziness in not
> typing two nextPut:s rather than one. I haven't tried this yet (supper break
> since my last post!), but would it work?

I suspect that my server is not carrying everything (or perhaps I'm just
being dense).  The following are some random thoughts that might be of
benefit, or simply confusing, depending on what you are trying to
accomplish.

You might take a look at DocumentShell which might either solve your
problem or give you some ideas.

Generally, I consider the failure to serialize events to be a feature
rather than a limitation - though I admit it does not seem that way when
one first notices it :)

Depending on what you are doing, you might want to override
#stbFixup:at:.  In one situation, I replace a mutex that (at least in
older versions of Dolphin) didn't work after being reloaded, and do some
cleanup after STB conversion.  I use very typical STB conversion
methods, but need to access objects that are not necessarily accessible
at the time of conversion.  A workable solution is to use STB conversion
methods to get the instance variables in order, and then use
#stbFixup:at: to lazily "repair" the newly converted objects.  No harm
comes to objects created at the latest STB version.

<shamelessPlug>If your problems are in user interfacing and
DocumentShell is not a good answer, you might want to take a look at my
Pane Holders package.</shamelessPlug>

Does that help?

Have a good one,

Bill

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

"Bill Schwab" <[hidden email]> wrote in message
news:cc24d5$1466$[hidden email]...
> Peter,
<snip>
Bill

Thanks. I guess I am not yet thinking in Smalltalk. What I had not realised
is that making a new assignment to a model destroys all event registrations
attached to the previous model. I still don't quite see it, especially as
Chris Uppal (in the thread Andy cited) says events really belong to the
observer (i.e. my presenter in this case). However, I don't want to worry
too long over STB, because it is something I am using as a temporary measure
while I am prototyping my app - the intention is to use something like
OmniBase for handling larger datasets in the final version. For now, I have
found that the solution is to file out the instance variables of the model
(only two that matter!), since filing them in again restores the state of
the model before saving without disturbing the event registrations.

Re interfaces, I found the variety of design ideas available very confusing.
What I hit on was that there is quite a close analogy between the way I want
my app to work and the use of the class hierarchy browser. I am therefore
modelling my design on that, using a modified version of the CHB default
view as my view and copying over modified versions of the CHB methods as
required. Right now I wonder whether I have made things too complicated for
myself, but I am so far down that road that I want to continue for a bit
longer and see if I can make it work. Thanks for your 'shameless plug',
which I interpret as a helpful suggestion; I may try your idea for my next
project.

Thanks again. Everyone in this group is so helpful!

Peter

Peter,

> Thanks. I guess I am not yet thinking in Smalltalk. What I had not
> realised is that making a new assignment to a model destroys all
> event registrations attached to the previous model. I still don't
> quite see it, especially as Chris Uppal (in the thread Andy cited)
> says events really belong to the observer (i.e. my presenter in this
> case).

Remember that a variable in Smalltalk is not like in other langauges. A
Smalltalk variable is just a "slot" where a pointer (I don't like to
use that word for fear of C connotations) to an object can be stored.

So you have your "model" slot holding a pointer to object, Model1, say.
You set up some trigger wiring by sending #when:send:to: to this
object. This means that a registration for Model1 is held somewhere in
the event system. Next you decide to reassign your "model" variable
slot to a new object, Model2 but it is the Model1 *object* for which
events are registered not the "model" variable. Hence you now have to
send #when:send:to: to the object in the model variable again (now
Model2) to make receive the events from this new object.

Does this make sense? I always found this notion of Smalltalk variables
being "slots" helpful when I was starting out.

Best regards,

Andy Bower
Dolphin Support
www.object-arts.com

"Andy Bower" <[hidden email]> wrote in message
news:40e581a3$[hidden email]...
> Peter,
<snip>
>
> Does this make sense? I always found this notion of Smalltalk variables
> being "slots" helpful when I was starting out.
>
> Best regards,
>
> Andy Bower
> Dolphin Support
> www.object-arts.com

Thanks Andy - that helps a lot. I am getting there slowly!

Peter