Last updated at 11:01 pm UTC on 22 February 2017
(moved from PluggableTextMorph)
Question From: Ken Causey 20 January 2004
I'm working on adding some status feedback to BFAV2. Right now simply in the form of a new small pane at the bottom that contains a PluggableTextMorph .
Answer From: Ned Konz
Is the status feedback coming from the UI thread? If not, you will have to use addDeferredUIMessage:.
Question I'm finding that requesting an update of the get selector is not resulting in the PluggableTextMorph being redrawn and showing the new text. I hunt and hunt and find that in PluggableTextMorph>>update: a change of appendEntry forces a refreshWorld but a change of the get selector does not.
Answer You should not have to send refreshWorld. The ordinary invalidation should handle that.
Question What is the logic here? Is there some good reason why one does the refresh and the other does not? Assuming there is, should I be myself forcing a refresh when I know that the text has changed and should be redrawn?
Question I find refrences to stepping and addDeferredUIMessage: in the archives but that all seems 'out of model' when we are talking about a simpletext display widget that should immediately reflect changes in its model.
AnswerYou could use an UpdatingStringMorph for such a thing; its stepping polls a pluggable selector.__
This exchange from the squeak list about the various Pluggable... classes and events may be of some use:
Question Martin Drautzburg Wednesday 27 March 2002, wrote:
[There are no] View superclass for morphs. There are Classes like PluggableListView that inherit from View. Still understandable. But there is also a PluggableListMorph, that inherits from Morph. But Morph does not implement an update: method and with single inheritance I cannot additionally inherit from View. So how does a Model inform a Morph about changes ? Do I just roll my own update: Method for the morph ?
Answer: From: Ned Konz
The Pluggableclasses were (AFAICT) designed to port the MVC programming tools over to Morphic. So a parallel set of view objects were developed that could be connected to the same models (browsers, etc.)
All of the PluggableMorphs and all of the PluggableViews implement update:
Morph itself doesn't need to implement update: in general. If you want to use the MVC pattern with Morphs and models you build, just add an update: method to the Morphs.
Or you can use the more powerful and lighter weight event notification scheme that is accessed with #when:send:to: and #trigger and their friends. (The #trigger methods are changing names in 3.2 soon, and have already in 3.3). These let you connect events to actions without the target object (the View, in MVC terms) having to provide any code to handle the events (no update: methods required).
There is another mechanism that is used in Morph for updating; this is the #step method. Your Morph can have its step method called periodically and can do whatever is necessary to update itself. This may be more appropriate for some uses.