Tansel,

Somebody used the sledge hammer for removing ScrollController from
ParagraphEditors superclass chain. If you look at Smalltalk>>discardMVC
you'll find:

	"Get rid of ParagraphEditor's ScrollController dependence"
	#(markerDelta viewDelta scrollAmount scrollBar computeMarkerRegion) do:
			[:sel | ParagraphEditor removeSelector: sel].
	ParagraphEditor compile: 'updateMarker'.
	ParagraphEditor superclass: MouseMenuController .

This last statement is ... ugh, how do I put this?! ... sort of an
experiment for testing whether we really need any of the sometimes
complicated mechanisms for doing class reshapes ;-)

[Side note: if you think about it in a deeper way it's *amazing* that it
worked at all before. What you've seen is just the top of the iceberg -
since ScrollController has instVars recompiling any method that accesses an
instVar will go gaga (wrong offsets since ScrollController has silently gone
away). Not even talking about sends to super, possibly broken lookups in the
method cache etc... so yes, there *is* a reason for the class reshape
mechanisms, at least we learn this ;-]

Here's a quick hack that does the right thing for changing the superclass:

	Compiler evaluate: (ParagraphEditor definition copyReplaceAll:
'ScrollController' with: 'MouseMenuController').

So if you replace the #superclass: call with the above then everything
should be all right.

Cheers,
  - Andreas

> -----Original Message-----
> From: squeak-dev-admin at lists.squeakfoundation.org
> [mailto:squeak-dev-admin at lists.squeakfoundation.org]On Behalf
> Of Editor
> - Squeak News
> Sent: Monday, August 06, 2001 8:01 PM
> To: squeak-dev at lists.squeakfoundation.org
> Subject: [BUG]SystemDictionary>>discardMVC breaks editing
>
>
> In 3.0 and 3.1alpha if one discards MVC and then touches the
> TextMorphEditor code then strange things start to happen.
> For instance:
>
> Take a virgin 3.x image
> discard MVC
> then edit the mouseDown: method of TextMorphEditor, just add
> a line or a character, then accept it.
>
> Every mouseDown to a text window after accept causes a walkback.
> There are variations of this bug that can be created by
> various means this is only one way of creating it.
> As of now I don't have a solution to it.
>
> Cheers
>
> Tansel
>
>
>
>