[Widgetry 1.12] TextEditColumn and line n+1

So I'm messing around some more .-)

I have a Grid with a TextEditColumn

  grid addColumn: (TextEditColumn new
    accessor: #info; editable: true;
    labelString: 'Info'; verticalScrollbar: true;
    staticSize: true; maximumVisibleLines: 3)

After clicking into this column, I enter '1<CR>2<CR>3<CR>' and then
take the attached screenshot. Note the vertical text cursor in front of
the '3'. After entering 4 the field scrolls one line up and everythings
back to normal.

s.

Stefan:

Really, do you guys have to come up with such interesting problems  
just before the weekend????

Kidding!

I'll look at it this Monday. Thanks!

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Stefan,
Attached is an UNREVIEWED fix for your problem. Also fixed in this are the fact
that it needs two clicks to "activate" the text edit in a Grid, and added the
behavior of selecting all when activating the text edit.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Samuel S. Shuster (10.08. 11:41):

Sames,

since you complained bitterly about reporting errors before the weekend,
I've waited until (my local) end of the weekend before commenting on
your fix. [1]

It solved the problem I described above, but it's not the whole story,
I'm afraid. While behavior during entering the text is as expected,
cursor movement after the final <CR> is not.

'1<CR>2<CR>3<CR><UpArrow>' should place the insertion mark in front of
the 3, but puts it in front of the 2. While investigating what's
happening there, I found two items I'd like to point your attention to:

Widgetry.TextEditArtist>>newCharacterBlockFrom:movedByLines: contains
two comparisons "anInteger == -1" and "anInteger == 1", which should be
"anInteger < 0" and "anInteger > 0" IMO, to preserve the behavior
at the text borders if the offset anInteger is larger than 1.

Widgetry.TextDisplayManager>>composeFrom:with: shows some (for me)
unexpected behavior, as the state of the lineTable instance variable
does not coincide with what I would naively expect. I placed a
breakpoint at the beginning and at the end of this method and drilled
down to the lastLine property of lineTable. It does not change if you
insert a <CR> at the end of the TextEdit's text. If you add another
character to the new last line, however, it is incremented by one.

I can't dig further into this now, some other thing came up.

s.

[1] read: this was the first chance I had to mess around with it :-)

Stefan,

>since you complained bitterly about reporting errors before the weekend,
>I've waited until (my local) end of the weekend before commenting on
>your fix. [1]

I was kidding there of course.

Thanks, I'll look into this.

>Widgetry.TextDisplayManager>>composeFrom:with: shows some (for me)
>unexpected behavior, as the state of the lineTable instance variable
>does not coincide with what I would naively expect. I placed a
>breakpoint at the beginning and at the end of this method and drilled
>down to the lastLine property of lineTable. It does not change if you
>insert a <CR> at the end of the TextEdit's text. If you add another
>character to the new last line, however, it is incremented by one.

Yes. This is actually correct. The CR belongs to the line above it. The "blank"
new line that it causes is not a line at all, but actually an artifact that the
TextEdit creates for you. In effect the lines are:

1<CR>
2<CR>
3<CR>

And the TextDisplayManager reflects this.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

On Sun, 12 Aug 2007 14:31:57 -0500
"Samuel S. Shuster" <[hidden email]> wrote:

> Stefan,
>
> >since you complained bitterly about reporting errors before the weekend,
> >I've waited until (my local) end of the weekend before commenting on
> >your fix. [1]
>
> I was kidding there of course.

Me too :-D

While the contents may be three lines of text, the text cursor is after
the end of the third line, so should not belong to line 3 anymore.

So we have:
  before <UpArrow>:  1<CR>2<CR>3<CR>|

3 lines of text, <UpArrow> moves to line 2 of text:
  after <UpArrow>:   1<CR>|2<CR>3<CR>

when it really should be: 1<CR>2<CR>|3<CR>

If TextEdit creates the "empty line" artifact, it should notify the
TextDisplayManager to obey the visual representation.

s.

Stefan,

>It solved the problem I described above, but it's not the whole story,
>I'm afraid. While behavior during entering the text is as expected,
>cursor movement after the final <CR> is not.
>
>'1<CR>2<CR>3<CR><UpArrow>' should place the insertion mark in front of
>the 3, but puts it in front of the 2.

Attached is an UNREVIEWED fix for this problem. Note, this is in addition to the
previous fix.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

On Tue, 21 Aug 2007 14:33:28 -0500
"Samuel S. Shuster" <[hidden email]> wrote:

This works fine for me. Thanks alot.

s.