locked
Metro TextBox is brain damaged

    Question

  • The Metro-style TextBox is brain damaged. Rather than use the same strategy that every other forms system uses (e.g. HTML5, HTML, WinForms, WPF, ASP.NET MVC), the designers have elected to hard-code the height of the TextBox at 32 pixels. The net effect is that if you have a small font, say 12px, then the TextBox appears far too big. If you have a large font, say 40, then the TextBox appears to be 32px when it first appears, then grows without explanation when you start entering text.

         <TextBox Name="CompanyField" Font="40"/>

    Apparently, the only forms that work are ones that hard-code the TextBox font at 16px (which appears to fly in the face of their Best Practices documents).

    How are we supposed to design forms that involve text entry?  Pre-fill every text box with watermarks or spaces?


    Friday, May 09, 2014 3:58 PM

Answers

  • Thank you for your feedback. This is known behavior. Unfortunately font and fontsize are not sufficient to know how big the text will be in all languages. Better default prediction is being investigated for future versions.

    Since you have more information about your specific app and how it will use the TextBox you can set a MinHeight in the styles you use that have large font input.

    --Rob


    Friday, May 09, 2014 4:15 PM
    Owner

All replies

  • Thank you for your feedback. This is known behavior. Unfortunately font and fontsize are not sufficient to know how big the text will be in all languages. Better default prediction is being investigated for future versions.

    Since you have more information about your specific app and how it will use the TextBox you can set a MinHeight in the styles you use that have large font input.

    --Rob


    Friday, May 09, 2014 4:15 PM
    Owner
  • You can explicitly set the height of the textbox.

    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, May 09, 2014 4:36 PM
    Moderator
  • A.) This is not an answer.  Why do you keep on marking things as answered when they provide no useful information about a work around, no understanding of the problem stated and no acknowledgement that you have a bug?  Shouldn't the determination of whether the question has been answered be peer-reviewed?

    B.) In what universe does the Font Face and Font size not immediately tell you how large the encompassing box will be?  Even iOS gets this right.  The language may change the width of such a box but it has no bearing on the height (by definition, the Font Size fixes the height, there is no ambiguity).

    C.) This is not a feature or behavior that requires investigation.  This is a bug that requires escalation.  Every competitive Form system out there can do this calculation properly, why can't Windows RT?


    Donald Roy Airey


    Friday, May 09, 2014 5:30 PM
  • I can explicitly set the width of the textbox also.  Do you know why we don't?  Because such systems are impossible to design and maintain!

    Donald Roy Airey

    Friday, May 09, 2014 5:32 PM
  • Sorry, but the more I think about this reply, the more confused (read frustrated) I become.  When the TextBox first appears, it has a size of 32 pixels no matter what I do (short of hard-coding the height).  As soon as I type any character, let's say a space character, the TextBox changes to the proper height.  You obviously have all the information you need to calculate the correct height unless you're going to argue that there is property of the space character that provides more information about the font metrics than you had before the user hit the key.

    Donald Roy Airey

    Friday, May 09, 2014 5:47 PM
  • Thanks for the additional info.  I marked it as an answer because it's the answer - there's no other answer which will be correct in this case. Rob said that we already have this issue under review.

    If you are having problems in your application that this issue clearly causes and you cannot work around them we are here to help.  If you simply want to vent, feel free.


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Friday, May 09, 2014 6:32 PM
    Moderator
  • A "Response" is not the same thing as an "Answer".  An answer contains some information that addresses the original question.  My question is, with a fixed size of 32 pixels, how are we to design forms (in a way that doesn't take us back 20 years to when everything in a form was hard-coded)?


    Donald Roy Airey

    Friday, May 09, 2014 7:01 PM