It's the "easiest" control to use in REALbasic -- the StaticText. You drag one onto the window, position it where you'd like and you're done ever thinking about it.
It's also one of the most important controls you'll ever use when designing an application. It's the only control that lets you give information to the user about what's going on. How else will the user know what that EditField means? Or a ListBox? Or just about any control aside from button-like objects for that matter.
Since it's such an important piece of UI, I think it warrants a bit of discussion.
What's the point?
As I've said before -- it provides a description. However, let's be clear about the control. It's a read-only control that does not allow selection of any kind. In fact, it does not ever interact with the mouse. That's a bit harsh, but true because technically, there's a hyperlink control on some OSes that you're supposed to use instead. However, if you want to use your StaticText as a hyperlink in REALbasic, I think that's acceptable (assuming you give proper UI feedback to the user, such as changing the mouse cusor). The only interaction is should provide is a keyboard mnemonic for some platforms which allows the user to press a key combination (Alt+ the mnemonic) to access the next field in the tab order.Where does the StaticText go?
It goes directly to the left of the item which it describes when it is a single line of descriptive text (such as "Port:", "Address: " If you are going to use a single line of text and want it above the field, then you should consider using a GroupBox instead. If you want multiple lines of descriptive text, then it should go directly above the descripted control. If you choose to do this, you should not have any other controls to the right of the description.What should the text be?
Generally speaking, labels should be short and descriptive instead of superfluous. The message should be brief; so instead of "in many cases", you should put "often." Furthermore, you should not put a contraction between the subject and its verb. So instead of saying "The company'll do this or that" you should say "The company will.." Because you want the label to be brief, be sure to remove any words which don't add meaning to the content. You should never have terms in there like "actually", "basically" or "more or less" because that's just fluff. One big thing that a lot of people tend to miss is that you should always use the plural form of words when the label describes a "one or many" situation. So you don't use "File(s): ", you'd just use "Files: " instead. You'll notice that my examples always end in a colon. That's because the colon helps the user to realize that the label is describing the item next to it. Furthermore, it helps screen readers recognize that the label is a descriptor for an object. You should put the colon in your text only if you're using a single-line description to the right of the descripted object.What's a keyboard mnemonic? What's the AcceleratorKey event for?
I lumped these two together because the topics are releated. A keyboard mnemonic is the letter which is underlined in a StaticText by using the & character before it. So if you make the label's text be: "&Foobar" then it will be displayed as "Foobar" and the user can hit Alt+F to fire the AcceleratorKey event. This event has one purpose, and only one purpose. If you're using it for something other than this purpose then you have a bug in your application. It sets the focus to the control immediately after the StaticText in the control order. This control should always be the one that the StaticText is describing. Big Hairy Note: If you have a keyboard mnemonic for your label, you must implement the AcceleratorKey event. Failing to do so will cause your users a lot of grief because they think they can use the mnemonic, but it really does nothing. If you have any StaticText with a mnemonic and it does NOT have its AcceleratorKey event implement, then you have a bug in your application.I hope to see this change for a future release of REALbasic since I feel that there's no reason to make the user implement this event themselves. It's always the same outcome every time, and it's something that the framework can easily take care of for you. But that's in the future, and this is now -- implement that event.
What about font and colors?
These controls follow the same rules as every other control when it comes to font and color. You should always try to use the System font with them because UI consistency is very important. So set the font to System and the size to 0 so that the control is displayed properly on the system you're deploying to. Do not resize your text or use the bold/italic/underline styles to draw attention to it since this will throw off the UI consistency. Instead, use colors to draw attention to the control. But always keep in mind that not everyone sees colors the same way, so you may want to avoid this tactic for that reason. Also, remember that multiple colors on the screen at the same time can confuse the user by drawing their attention to multiple places. So use color sparingly and only when appropriate (such as hyperlinks, or denoting areas which need more user input).How does text alignment work?
This is one area that I see many people get incorrect, and for good reason. Mac behaves differently than Windows in this regard. On the Mac, all label text is right-justified and each field is meant to line up on the right. On Windows, it's the opposite. All label text is left-justified and the fields line up on the left.For more information about how StaticTexts should appear, please check out these resources:
Visual Design of User Interface Text on Windows
Menus, Controls and Toolbars on Windows
Text Controls for the Aqua Interface Guidelines
I believe I've covered all the major topics regarding how to properly construct a StaticText, but if there are things you have questions on, feel free to ask me. I've got one question for you -- these concepts all apply when in a language that uses left-to-right reading habits. Do you feel the UI should change for users who read from right-to-left, such as Arabic languages?
Interesting to read.
I never remember Windows keyboard mnemonics since that is not a feature that I use when I work on a PC. I am glad that you are encouraging its use.
I do find it odd that if the AcceleratorKey event is suppose to set the focus to the next control order control that it doesn't do it automatically. Seems a big shame that we have to implement it manually right now.
You may be right about the Left-Aligned thing too, but I personally always prefer to have my control labels Right-Aligned. This is not so much of a Macintosh thing (to me) as it is a Graphic Design thing... would it be too big of a deal for me to break this "rule"? Or would it really piss off Windows users? =)
I am parting with one other tip that I like about StaticText controls, which goes along with your set-it-and-forget-it theme... but your constant StaticText controls in a Control Array. Doing so reduces the Window Control clutter and improves the speed of the REALbasic IDE when editing the Window (at least in 5.5).
I agree 110% -- there should have never been an AcceleratorKey event in the first place. Unfortunately, we can't just remove it because people's code may break. However, we may end up giving it a return value and making it do the right thing if you don't return true. And if you've implemented the event, we may change your code for you so that it returns true (only the first time you launch the new version with that project though).
As for text alignment -- I don't think you'll piss anyone off with it like you would many of the other things. But you won't look "normal" which is a very bad thing. People may not be able to put their finger on what about your application is strange. But when people feel too strange, they ditch and go for something else. For example, any time I see an application with a Windows 3.1 open or save dialog, or installer, I bail out and never touch it again.
The control array tip is a good idea, but keep in mind that almost every static text should have a mnemonic and you have to implement those currently. So it may cause more hassle than it's worth. Remember, keyboard mnemonics are a Good Thing. They keep keyboard people happy, and they make your application more accessible to people with handicaps.
I agree that the RB framework should do this for you.
StaticText should be selectable on OS X though, it is in Cocoa applications (and most likely Carbon apps, but I don't have OS X in front of me to check). It's very useful to have in cases (msgbox's and messagedialogs should be selectable as well).
I'll check for a feature request for the above.
-- SirG3
Wait -- define "Selectable" because I'm not certain I understand what you mean by it. It should receive keyboard focus? Assuming that's correct, what would keyboard focus on a StaticText do? When I have full keyboard access on, I do not ever get any static text with focus on OS X. Also, what does it mean to have a "selectable" MsgBox?
I'm sure I'm missing something obvious.
Selectable in the sense you can select text in the StaticText control and copy it. Like a read only editfield.
-- SirG3
Ah, I see! You can make a StaticText behave that way on Windows as well by setting the styles correctly. But it's not exposed to the user in RB in any way.