Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

Switching between Landscape/Portrait = Screwed up Table Views

It seems that text is not properly reformatted when the application switches between landscape and portrait mode. I put together a very small sample app (~100 lines of code):
http://pastie.org/1054148

To see what I mean, just fire up the code and do the following:

  1. In Tab1, switch to landscape mode (command + left arrow).
  2. Then move to Tab2, and notice that the text has not been reformatted.
  3. While still in Tab2, switch back to portrait mode (command + right arrow)
  4. Move back to Tab1, and notice the text is also screwed up there

I am using 1.3.2 and iPhone SDK 4.0. Could someone else please confirm the problem? Is it a bug, or am I incorrectly specifying the table layout?

— asked July 21st 2010 by Mike Dosey
  • 1.3.2
  • 4.0
  • iphone
  • landscape
  • mobile
  • portrait
  • table
  • view
0 Comments

4 Answers

  • Just dropped your code in and have seen this behavior as well. I created a Lighthouse ticket to track it here. Thank you for providing the test case, the developers will have a much easier time reproducing and fixing.

    — answered July 21st 2010 by Kevin Whinnery
    permalink
    0 Comments
  • Argh, I can't believe no one has touched this bug in Lighthouse since it was created 5 months ago. Are people not supporting landscape view in their Titanium apps? How could this not be important enough for 1.5?

    — answered December 11th 2010 by Mike Dosey
    permalink
    0 Comments
  • I removed the widths on lines 49 and 83, as instructed, and it does not correct the problem.

    — answered December 13th 2010 by Mike Dosey
    permalink
    0 Comments
  • Repeating what I said on the LH ticket:

    My apologies for not looking at this earlier. It's actually due to the sample code requesting two conflicting widths. That is, there's the width set to 'auto', which instructs the text field to stretch as far as it can horizontally to hopefully fit the text in one line. But there's also the fact that the containing row has a fixed width, and the label wants to have left and right margins of 10 within that.

    It's not straightforward, and we still need to work on both ensuring the algorithm is the right behavior to go, and if so, educating people on it. 'Auto' can be misleading as it's meant for 'Size to fit my contents, regardless of the parent's bounds,' and it sometimes feels like 'Do what I mean.'

    Either way, if you remove the extra autos (Lines 49 and 83), which undoes the conflicting widths issue, you'll get the desired effect.

    — answered December 12th 2010 by Blain Hamon
    permalink
    0 Comments
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.