Bug 3529 - MultilineElement and StyledMultilineElement have formatting issues
Summary: MultilineElement and StyledMultilineElement have formatting issues
Status: RESOLVED DOWNSTREAM
Alias: None
Product: iOS
Classification: Xamarin
Component: MonoTouch.Dialog ()
Version: 5.2
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
: 4132 19303 ()
Depends on:
Blocks:
 
Reported: 2012-02-17 23:37 UTC by timothy.risi
Modified: 2018-03-24 00:57 UTC (History)
7 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Sample project showing described formatting bugs (1.31 MB, application/zip)
2012-02-17 23:37 UTC, timothy.risi
Details
patch for most of the issues mentioned (2.56 KB, application/octet-stream)
2012-03-28 20:37 UTC, Sebastien Pouliot
Details
This project will demonstrate the issue. Run in iphone ios 7.0 on 3.5 inch retina. (1.49 MB, application/zip)
2014-04-18 16:39 UTC, Sam Christiansen
Details
screen shot demonstrating issue (171.35 KB, image/png)
2014-04-18 16:42 UTC, Sam Christiansen
Details
Updated initial test case (4.45 KB, application/zip)
2016-02-11 14:46 UTC, Rolf Bjarne Kvinge [MSFT]
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED DOWNSTREAM

Description timothy.risi 2012-02-17 23:37:00 UTC
Created attachment 1379 [details]
Sample project showing described formatting bugs

There appear to be several formatting issues in with MultilineElement and StyledMultilineElement in the built-in MonoTouch.Dialog.

MultilineElement:
1.  With the caption is multiple lines, it sometimes cuts off the last line.
2.  If there is a blank caption (empty string) with a string for the value, the     cell is shrunk down to minimum size and the value extends past the borders of the cell.
3.  If the value is more than one line long, it gets cut off and ends with ...
4.  If the caption takes up multiple lines and there is a value set, the value isn't shown.

StyledMultilineElement:
1.  If there is a blank caption (empty string) with a string for the value, the cell is shrunk down to minimum size and the value extends past the borders of the cell.  If the value is multiple lines, only the last line is visible.
2.  If there is a caption and the value field is multiple lines, it shows all of the lines, but doesn't extend the cell so the value extends past the borders of the cell.
Comment 1 Sebastien Pouliot 2012-03-28 20:37:10 UTC
Created attachment 1596 [details]
patch for most of the issues mentioned

Bug #4132 contains some fixes, i.e. Caption text should be completely shown (whatever the orientation or device being used).

It's not clear what [Styled]MultilineElement should do if both Caption and Value are multi-lined. Right now MultilineElement accept only single-line Value, while StyledMultilineElement accept multilines.

The attached patch includes the fix from bug #4132, fix the empty Caption condition and multiline Value. However it does not change the existing behaviour when both Caption and Value are too long to fit on a single line.

It mostly works (except for StyledMultilineElement when you have a Caption and a long Value since the Width of each control is not know at that time) and respect the current behavior.

Miguel ?
Comment 2 Sebastien Pouliot 2012-03-28 20:37:34 UTC
c.c. Miguel
Comment 3 Miguel de Icaza [MSFT] 2012-03-28 21:19:25 UTC
Patch looks good to me.

Mind applying the patch?   You have write permissions
Comment 4 Sebastien Pouliot 2012-03-29 10:31:42 UTC
MD.D: 03966b49606e7f1a3cc6a4e8f97c7ba12f5e160c
master: c6b9d056bc403f0c374760e70ac3309df872283a
5.2-series: 608d534658c04420ef2b76ba1e9eb138c683f2e7

should we document StyledMultilineElement with long Caption + long Value as an undefined behavior ? (i.e. it needs to be subclassed if a need a specific behavior)
Comment 5 Sebastien Pouliot 2012-03-29 10:32:41 UTC
*** Bug 4132 has been marked as a duplicate of this bug. ***
Comment 6 PJ 2013-11-19 17:05:52 UTC
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?

If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
Comment 7 PJ 2013-12-05 18:36:20 UTC
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.

Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.
Comment 8 Sam Christiansen 2014-04-18 16:29:41 UTC
I'm still seeing a bug where the last line of text is cut off.  This is as of version:

$ /Developer/MonoTouch/usr/bin/mtouch --version
mtouch 7.2.0.2 (58c3efa)

All I'm doing is "new MultilineElement(str)"  -- I will create a simple test case and attempt to attach it.

thanks,
sam
Comment 9 Sam Christiansen 2014-04-18 16:39:05 UTC
Created attachment 6612 [details]
This project will demonstrate the issue.  Run in iphone ios 7.0 on 3.5 inch retina.

Here is a sample project demonstrating some text that is cut off.
Comment 10 Sam Christiansen 2014-04-18 16:42:50 UTC
Created attachment 6613 [details]
screen shot demonstrating issue

here are 3 screen shots demonstrating this issue.  Shot on far left is the first time a cell is created.

Second shot shows that text is properly fitting if the cell has been recycled (if i scroll off and then back to the description field, it looks correct).

Third shot shows the same text running in the sample project I just attached.  As you can see it is cut off as it is in screen shot #1.
Comment 11 Mikayla Hutchinson [MSFT] 2014-04-29 11:33:44 UTC
*** Bug 19303 has been marked as a duplicate of this bug. ***
Comment 12 Rolf Bjarne Kvinge [MSFT] 2016-02-11 14:46:16 UTC
Created attachment 15000 [details]
Updated initial test case

I can't see any issues with the second test case from comment #8 (but then the 3.5'' simulator is not available anymore, so it might have only been a problem on that screen size). Thus I'm marking those attachments as obsolete.

However I can still reproduce rendering issues with the initial test case, so this bug is still not fixed.

I'm attaching an updated test project, based on the initial sample project (which doesn't build anymore due to other changes).
Comment 13 Alex Soto [MSFT] 2018-03-24 00:57:33 UTC
Hello Guys, I gave this a try on the native side, so to summarize a little, we use the native UITableView cells that comes from UIKit using UITableViewCellStyle.Default or UITableViewCellStyle.Value1 depending if a `Value` was given to the StyledStringElement , these objects are pre autolayout, they have been with us forever (since the release of iOS 2) and they do have some layout issues when it comes to use the default cells from UIKit.

I gave this a try in the native side and ended in the same spot when doing large captions and large values like this one:

> new Section ("Multiline Caption and Value") {
>	new MultilineElement("This is a longer caption.  This one will take up multiple lines and break.",
>						"This is a longer caption.  This one will take up multiple lines and break.")
> }

so having the same setup results in the same UI overflown situation since it seems that the cell was not designed for this kind of scenario. Even I tried to fix it by adding the constrains myself but I could not make a one size fits all using the default cells.

I think that the best approach for this MultilineElement with a huge Caption and a Huge value you need to roll your own element that uses a custom cell class since the out of the box ones simply are not for this kind of behaviours. 

I am closing this as Resolved Downstream because this is really an issue on Apple's default cells implementation and to be honest I don't think this is something they care about since the introduction of UICollectionView which seems that even Apple is trying to move away from UITableView (https://twitter.com/BunuelCuboSoto/status/818169193073934337).