Hi,

Yes I can reproduce this. It's the same as in OOo 1.x version.
reassign to fs because he is responcible for the component.

Bye Marc

accepting

A dedicated multi-line input control in the table view is on the wish
list for quite a while ... Would need some design how to present this
to the user ...

Hi Frank,

I now understand you point of view with regards to simply accepting 
that the data source window for memo or text fields does not do 
multi-line input and the only way to do this is via a Text Box set 
to multi-line.

As you also now appreciate from a users point of view, I did not 
expect this behaviour.

In MS Access I am used to seeing a memo/text field as being able to 
have line feeds in them.

I don't know if this is true of all database formats.  I certainly 
never thought this was true of dBase text fields even though OO 
allows this.

Using a Text Box set to single line also destroys the line feed 
information of the memo/text field if the content is edited.

The question then becomes what is right. Obviously both are right.  
However the OO approach causes data loss and I think that is the 
real problem.

Whilst I believe you already know the following, I thought I would 
make the effort to document how I think the data source, Table 
Control and Text box should work.


There are two possible approaches (and there are probably others).

Also some method of handling the line termination is also desireable 
as mentioned for MS Access in issue 13497.

The issue here however is how to present the information to the user.

First approach which is not preferred but would be acceptable:-(

Treat the memo/text field as one continuous line (in data source, 
Table Control and Text Box set to single line) but display line 
feeds as unprintable characters wich typically show up as black 
squares or vertical lines in the data source windows for a memo/text 
field.

Multi-lines to display in the Text Box with multi-line set to Yes as 
they currently do. 

This means we can press Enter in a data source, Table Control or 
Text Box (single line) memo/text field and a representation of Enter 
would be inserted.  Enters could also be deleted as they are visible.

Second approach which is preferred.

Not only is this approach preferred, it is more natural to the user 
and does not end up with characters on the screen that don't make 
sense to the user.


If there is multi-line text in any of the data source, Table 
Control, Text Box (single or multi-line) then I would expect 
something like the following behaviour to occur.

In all but the multi-line Text Box, given there is only room for a 
single line to display  I only really expect one line to show.


If the line is wider than the column width, the text should scroll 
once the cursor hits the right end by pressing the right arrow as it 
does now.

If the cursor hits the end of the line, but not the end of the text, 
then it should move to the next line and operate on that line as it 
did for the first. (Left arrow should obviously perform the opposite 
to the right arrow.)

Other keys and these mimic MS Access and also largely how the Text 
box currently works.

Home: Start of line
End: End of line
Up arrow: Up one line
Down arrow: Down one line
Page Up: Up one line
Page down: Down one line
Control+Home: Start of memo text
Control+End: End of memo text

The other trick which would be handy is how pressing Shift+F2 in MS 
Access provides a pop up window to view and edit the text.  This 
could be some other unused Key combination. It could also be right 
click then zoom edit.

For Text Box multi-line input the current approach is fine.

I hope these thoughts help.

Kelvin

thanks for the ideas, Kelvin.
I certainly agree that something like "edit" or "zoom" in the context
menu of an text field in the table view is very usefull, and this at
least is something we will do (I think :).

I am not sure if line-wise display of text is a good thing, because
unexperienced users may simply think there's nothing more than this,
until they (by chance) travel behind the last character of the
currently visible line.

Admittedly, I also do think that the linebreak-with-placeholder
approach is somewhat ugly, and looks unprofessional (okay, you could
argue better unprofessional than data-loss :).

I could also imagine that when the user enters the field (by regular
means: by cursor or tab), then a small floating window for multi-line
input pops up automatically. Closing this floater would be done by
Escape, CursorRight behind the last character (or CursorLeft before
the first), and Tab. Just a quick idea, not sure how feasible this is.

I am pretty sure there is a lot of room for discussions when it comes
on implementing this ...

Hi,

Just thought I would let you know the line wise display of text with 
the cursor movement is the way MS Access currently does it in the 
raw view of the table like the data source.

Although with the MS Access Form each row can be expanded in height 
which allows the text box to be expanded and thus the user can see 
more text is possible. Although if only a single line is allows this 
is how it is shown.  At report time the report can grow fit all the 
information.

I'm not certain how if you move into a mult-line line field in the 
data source or Table control and the window expanded how that would 
feel.  But it is a good idea.

I can't also help feeling the existing method in OO is also valid.  
If a field should not be allow to have multi-line then the current 
approach in OO is better than the MS Access and I would not like to 
lose that.

Perhaps allowing the person to right click on the column heading in 
the data source or the Table Control and selecting multi-line Y/N 
should be considered.

Even though I consider the current losing of data as corruption, it 
is no longer corruption if I have made the choice to limit a field 
to multi-line=No as then that is my problem in the way I set the 
field.

I only consider the problem as data corruption now because I as the 
user can't make the choice and the line feeds are lost in the data 
source window.

From what I have observed the Text Box multi-line=Yes/No approach I 
think is very good.

If I say No then I can't enter line feeds.  If I say Yes then I can 
enter line feeds.  That gives me better control over what the user 
enters.

If I want a mult-line=Yes but shrink it down to one line in height 
it gives me the type of box like how I think the data source should 
work.  If I turn vertical scroll bar on this gives me indication 
that multi-line text is allowed even though the arrows are a bit 
squished. Now if I also had a zoom field capability I would then be 
happy.  (Well are we ever really happy).

To state what I am saying in a different way, I actually think the 
Text Box does practically everything that I want to do except the 
zoom feature.  So if this applied to the data source and Table 
Control as well with multi-line=Yes/No and zoom then that would be 
good.

With regards to server versus clients as I don't do any real server 
work these considerations don't enter into my thought processes.  
Sorry I can't help more in that area.  I tend to see everything from 
the client computer perspective.

Hope these thoughts help.

Kelvin

*** Issue 20607 has been marked as a duplicate of this issue. ***

change subcomponent to 'none'

marking as blocking issue 20316

fixed in CWS dba09

fixed in CWS dba09

fs->msc: please verify in CWS dba09 (spec for this is
http://dba.openoffice.org/specifications/forms/multiline_line_ends.sxw)

fixed in CWS dba09

verified in CWS dba09

seems to have made it into the master