The standard Windows/MFC ComboBox (dropdown-mode) has an auto-complete feature that I'd like to turn off, but don't know how.
Example 1: Create a ComboBox with the list values "Abc" and "Def". Enter "A" as edit value and use the drop-down-button. "A" will be changed to "Abc".
Example 2: Same start values. Open the drop down, enter "A" as edit value and press TAB. "A" will be changed to "Abc".
These examples even work in the Visual Studio IDE dialog editor test mode. No compiled exe needed.
The change from "A" to "Abc" is probably a feature, but it's not wanted by the customer. Is there any way to prevent it?
You can finetune autocomplete behavior of any Edit control by calling SHAutoComplete. To get a handle to the Edit control part of a ComboBox send a CBEM_GETEDITCONTROL message to the ComboBox control.
To remove the unwanted feature the flags for SHAutoComplete must not include SHACF_USETAB.
It'd be really handy to have collection KVC accessor snippets in xcode, as they're a pain to do by hand. Has anyone who's been using 4 for a while worked out how to add new ones?
(...we're allowed to talk about it now, right?)
Yes, it's quite easy - you just highlight text you want to use as a snippet and drag it into the snippets area (dragging selected text can be difficult, I find it works better if you drag from the left edge of the editor). It brings up a dialog box asking you to name it.
Also, you can have custom parameters in snippets - if you put the text <#paramName#> anywhere in the code you are dragging, when you use the snippet it will come up as a replaceable parameter that you can tab between just like in the official Snippets.
Also make sure to set a completion prefix, which makes it shorter to activate the snippet as you are typing. The nice thing about using Snippets over other solutions like global system text expanders, is that snippets can also be limited to being valid in a certain area of code - so for example a snippet that filled out a string formatting line can be marked as valid only within a block, not outside a method. That way the completion prefix only hits in areas where it's valid to use.
You can edit a snippet by clicking once on it, a box will come up with the snippet text and some other snippet settings you can edit.
A tip to help you drag the code every time, select text then click + hold (do not move mouse) until mouse pointer changes from "I" to pointer. You'll then be able to drag the selected text to the Code Snippet Library.
Drag the highlighted code to the Snippet library. (It can be stubborn and not want to drag. Holding the mouse button down for a moment before dragging seems to help.)
You can use Snippets to manage code snippets in Xcode. Check out this demo http://www.youtube.com/watch?v=il4kE4diy0k
Simply select the code, the press ALT key and drag it into the code snippets library and rename it there, Make sure to press the ALT key, other than this you won'n be able to drag it.
Hey everyone, thanks for all your help so far, I've learned a whole lot in a short amount of time.
What I've done so far is to create a small calculator program and it works nicely. To complete this version of it, what I'd like to do is make my "keys" on the calculator interface accept input from my keyboard presses. So, for example, if I want to add 2 and 4, instead of clicking my "2" and "4" buttons, I can just press them on my numeric keypad instead.
I know it has something to do with giving my buttons focus but I can't figure out how to make them respond to keydown events.
I'm looking around on the apple developer documentation as well, so if I find the answers before you guys can then I'll try what I find out, and if it doesn't work I'll post with my progress.
Again, thanks everyone for your help!
You can set the key equivalent in interface builder. Click on the button in interface builder open the inspector and open it to the first tab. Under the first section there is a Key Equiv: and a gray box you can click on. Click on it and press the key you want to press it.
If you're using interface builder, just set the "Key Equivalent" field to be your number.
I am developing an extension, and I need to read the value
of these two dropdowns, but I don't know what they are called.
Any idea or guess?
alt text http://img97.imageshack.us/img97/992/namea.jpg
How to: Navigate and Search in Visual C# Express in MSDN Library (local) at ms-help://MS.VSCC.v90/MS.MSDNQTR.v90.en/dv_csexpresscon/html/02412643-f727-4960-bf25-7ef80bda8b25.htm
The Navigation bar consists of two combo boxes named Types and Members displayed at the top of the Code Editor...
I don't know the names of the combos but the bar they're both in is called the Navigation Bar I think.
When should I put ... at the end of a menu item? I seem to remember reading some rules but can't for the life of me find them.
For context - I'm adding a properties option to a right click menu and am wondering if it is appropriate to add them.
As I understand it it indicates that the option will ask you something else before actually doing anything. The 3 dots are actually called an ellipsis, and if you check out the English use it kind of makes sense:
http://en.wikipedia.org/wiki/Ellipsis
BTW I've noticed OpenOffice breaks this convention sometimes!
When the option will send the user to some sort of dialog where the user has to do something before a real change is made. Options without the ellipse take effect immediately.
For example, 'Save' doesn't have an ellipsis, while 'Save As...' does because the user has to input the new name/location of the file.
One exception to the first two answers: if the whole point of the menu command is to open a window or dialog, then you don't need an ellipsis. For example, a "Get Info" or "Properties" command shouldn't have it, even though it's opening a window which lets you edit things.
It's only when the menu command's purpose is to do something else, but it needs a dialog or confirmation in order to do it.
It means that there will be another dialog box after you select that option, it won't actually 'do' anything. There will be another prompt.
To be exact, the rule is that if more information is required from the user to complete an action, then include an ellipsis. In the MS Vista User Experience Guidelines, getting a confirmation qualifies as "more information" (see http://msdn.microsoft.com/en-us/library/aa511502.aspx). Commands to show Properties, About, Help, Options do not get ellipsis because no further information is needed to execute the command, which is "Show Properties" or "Show Documentation" or "Show Options." The File Open command gets an ellipsis because additional information is needed to open the file, namely the file name.
If the menu is an action that the user will be doing, but the action won't be completed until we get more information from the user, you show an ellipsis, e.g.:
Format Hard Drive… (we need to know which one, and the file system type)
Save As… (we need to know what filename and type to save as)
Print… (we need to know what printer and quality settings)
Find… (we show a text box asking for the text to search for, and where)
Rename… (rename to what)
As opposed to actions that will happen the moment you click the menu item, e.g.:
Save
Undo
Redo
Select All
Ellipses don't just indicate that a dialog will appear. i.e. if it's not an "action", then there's no ellipses, e.g.:
About Gizmo
Page Setup
Print Preview
Options
File Properties
And asking the user if they want to do something does not count as "getting more information from the user", e.g.:
Delete File
Recycle File
New Text Document
Whenever selecting that item results in another dialog box appearing. For actions that happen immediately (think Save vs. Save As), no ellipsis.
Originally, it meant:
An ellipsis (...) after a menu item means that after the item is chosen, the user will be asked for more information before the operation is carried out. Usually, the user must fill in a dialog box and click and OK button or its equivalent. Don't use the ellipsis when the dialog box that will appear is merely a confirmation or warning (for example, 'Save changes before quitting?').
(Apple Human Interface Guidelines, page 69)
Note that it did not mean "show a dialog box", even though that was often the consequence of this. For example, on Mac OS (not X), the "Options" button in the Page Setup window had no ellipsis, even though it showed a modal dialog box. No ellipsis is used because showing the options window is the operation.
(Tog on Interface, pages 46-47)
Of course, these days nobody cares about such things as human interface guidelines, not even Apple, so you can pretty much do what you want and still be more consistent than most any other application out there.
I've usually seen it in places where more input is required from the user before completing an operation. If your properties dialog is allowing the user to change properties, I would include the ellipses. If it's just displaying the information, don't include it.
It generally means that a Dialog will be shown when the item is clicked.
They usually signify that clicking on that entry will open a dialog window.
You should add ellipses to the end of text only if you're truncating the text (this applies anywhere). You should truncate the text if it's too long to reasonably fit where you're putting it.
Edit: interesting, I never noticed that menus in Windows use the ellipses to indicate truncated text, but also use the ellipses on short text to indicate that more information will be collected before the action is taken. This is inconsistent interface design, but since menus are under the control of individual programmers it's unavoidable.
It usually means it'll take your focus away from the current window. Like for example, notepad has a "Find..." which means you're going to focus on another window (ie dialog box) to enter something. But in firefox, it has just "Find" which then focuses on a text input on the same window.