Mantis - Squeak
Viewing Issue Advanced Details
5711 Morphic minor always 01-08-07 15:03 09-16-14 19:06
nicolas cellier  
resolved 3.9  
none trunk  
0005711: TextFieldMorph changes text position when emptied
Once initialized the TextFieldMorph displays an 'abc' text in the upper left corner. The text can be obviously edited but if you delete all the characters, the Morph changes its color to the default light gray and the text written after that doesnt appear in the top left corner anymore but one line below.
"Sample code"
textMorph:=TextFieldMorph new openInWorld.
"At this point I delete all characters ('abc') mannually and write some new text"
textMorph fit. "After this, text goes to the corner again"

Pressing Alt-0 the new text goes back to the corner as well, but that behaviour should be default. This reported change in text position doesnt happen either if you select the 'abc' initial text and write some replacement, only when the TextFieldMorph is emptied.
 Mantis 0005711 - FixTextFieldMorphLinePosition.1.cs.gz [^] (689 bytes) 08-07-08 04:15
 FixTextFieldMorphLinePosition-M5711-ASB.1.cs.gz [^] (638 bytes) 08-12-08 03:57

Antony Blakey   
08-07-08 00:01   
If you do this:

  textField := TextFieldMorph new.
  textField contents: ''.
  textField extent: 400 @ 40.
  textField openInWorld.

and then this:

  event := KeyboardEvent new setType: #keystroke buttons: 0 position: 0@0 keyValue: $a asciiValue hand: nil stamp: 0.
  textField submorphs first handleKeystroke: event.

then the text is one line down. If you subsequently do this:

  textField append: 'a'.

then the text goes back to the first line. I suspect it has something to do with the null line, that is inserted when the content is empty, being incorrectly processed for keystrokes, possibly an error in an optimization. I am tracing this to find a fix.
Antony Blakey   
08-07-08 04:01   
The bug is in TextComposer>>composeLinesFrom:to:delta:into:priorLines:atY:textStyle:text:container:wantsColumnBreaks:

When the null line is added, it uses "container topLeft", whereas the rest of the code use "container top", which for TextContainer is NOT the same as "topLeft y".

I've attached a changeset containing that fix.

Antony Blakey   
08-12-08 03:57   
Uploaded a properly-named change set after watching Ken Causey's screencast.
08-12-08 22:43   
Excellent catch, Antony! "Etoy" users are greatly affected by this bug, and I'll see to it that your fix gets into the olpc-etoys and Squeakland updates streams asap. Thank you!
08-13-08 01:49   
Actually, though in the image variant I was using I was able to reproduce the bug described above, and to verify that the proposed fix did work, I subsequently discovered that I could not reproduce the symptom in the current olpc/etoys and about-to-be-released squeakland images. So for the moment anyway I won't pursue pushing the change to those update streams. I don't yet understand what change(s) in those systems may have worked around the need for the fix, but I note that it wasn't any change to the method under discussion here...
11-16-08 16:41   
in pharo 10151
nicolas cellier   
09-16-14 19:06   
Fixed in trunk 4.6 [^]

Thanks Antony and Tobias