When you click on item on Activity bar, that item window is opened in Side bar. For example: SearchViewletVisible and ExplorerViewletVisible for Explorer and Search resp. There are other items on my activity bar, like extensions, debugger, outline e.t.c, How can I get their names?
activeViewlet: "workbench.view.debug"
and the same for the others, like
activeViewlet: "workbench.view.extensions"
You can check these for yourself by using the Developer: Inspect Context Keys command and then searching for debug for instance to see if you get anything promising.
See https://stackoverflow.com/a/62202897/836330 for how to use the Context Keys command.
And https://stackoverflow.com/a/62523863/836330 on how to use these values in a keybinding.
#mark's answer above worked nice, but people who are new to vs code (like me) would not understand where to search for the item name, so for those people:
To find out the name of activeViewlet or focusViwlet or any other thing, Toggle developers options from ctrl+shift+p, and search for your item in the last item of the console in developers options.
Related
In Visual Studio 2015 "Find and Replace" window, you can freely type anything you want into the "Look in" field:
The preset dropdown values are things like:
Current Window
All open documents
Entire solution
etc.
What is the purpose of allowing typing in this field? What could I possibly type in here which would make any sense?
And if I do type something like "foo bar" in there, what is the behavior when one of the "Find..." buttons is clicked? It seems to just search normally - maybe in the current solution (??).
Note - it even seems like mistaken entries can get stuck in there.
That allows one to specify directories. Or even multiple directories. Or even combinations of built in locations and directories. Separate each location with a semicolon.
Example:
Entire Solution;C:\Source\18.1
Then to remove an entry, click on the ... button. This will bring up a dialog box titled "Choose Search Folders". Then on the right hand side, selected the entry you wish to remove and then click on the button that looks like a less- than, or left-angle bracket. This will remove the entry.
I am implementing my own language handling to be able to switch language of my OSX-application at runtime without restarting.
All menus have been changed so far, my own using tags and the system generated ones I removed (special characters and dictation).
So what is left is the search menu under the help menu. Can this be changed.
As far as i can see it is not a menu item and does not appear show up in the fast enumeration of items.
In Xcode, how can I find all caller functions of a specific function?
Xcode 4.5 (in beta) has this functionality. when you highlight say... a function, you can check the "caller" and "callee"
edit i believe it's located at the top left of the file panel for that file... so double click on the function to highlight it, and you click on on the file panel options (the one that has the "open recent, open unsaved...etc" drop down
EDIT #2
here's a picture to clarify (since i dont know what this menu button is called):
ALSO - XCode 4.5 is no longer beta, i believe, and is actually out in public
EDIT #3
also note that this caller thing does NOT search for being called under the performSelector method, as in, the particular caller that has this performSelector won't show up if you had done something like:
[self performSelector:#selector(checkIfShouldStopMovement) withObject:nil afterDelay:0.25];
In Xcode, the quickest method is this:
Select method in code (double click or mark using your mouse cursor)
Press Ctrl+1
Select "Callers" from the pop-up menu.
This is the shortcut for going View -> Editor -> Show Related Items in Xcode's menu.
use ⌘+Ctrl+Shift+H key combination on Xcode 7 onwards.
This can also be accessed via the assistant editor, as shown in the screenshot below. Whichever method you have the insertion point in in the main editor on the left will have its callers displayed in the assistant editor. I've found this to be the best way of looking through each caller in succession, since once you have "Callers" selected, you can then select the next caller via the next pop-up menu to the right in the jump bar.
In Xcode-7 you have the functionality of getting call-heirerchy. Right-click on the function and click "Find Call Hierarchy":
image reference:
Xcode 10 upwards seems to have made it easier. Just Command Click on the function and you should see it in the drop down.
Press ⌘+Ctrl+Shift+H shortcut when a method of interests is selected (with a mouse or cursor). (as per #uiroshan 's answer)
But you can also specify any another shortcut in XCode -> Preferences -> Key Bindings
Use Find in Project as Text or as Symbol.
AFAIK, there's no equivalent to e.g. Call Hierarchy known from Eclipse or NetBeans.
Strangely the refactoring tool can detect all method calls but not the search.
So I simply use it to rename my method to a unique name (eg. reset to resetPlayer) and then use the new name in a regular textual search.
1.) Menu > Edit > Refactor... > Rename to unique name
2.) search for the new name
The functionality is available in XCode 4.4.1, see this: http://smilingfinney.blogspot.de/2012/09/method-callers-in-xcode-44.html
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.
In pretty much all applications that have a menu bar, some of the items have an ellipsis (...) after them, and some don't. Is there a well known convention on when to put that ellipsis there and when not to? When do you do it? Do you do it?
I have looked at various windows applications, and this is what I have come to:
Ellipsis
Menu items which opens a form that require user input to do something (Replace, Go to, Font)
No ellipsis
Menu items which just does something (Cut, Paste, Exit, Save)
Menu items which opens a form that does not require user input (About, Check for Updates)
But then there always seems to be menu items that doesn't follow this rule. For example the Help items (How do I, Search, Index) and the Find and Replace (Quick Find, Find in Files, Find Symbol) in Visual Studio.
So after thinking about it a bit more I now think this might be the thing:
Ellipsis
Menu items that will definitely open a modal window.
No Ellipsis
Menu items that opens a non-modal window.
Menu items that doesn't open any window.
Menu items that most likely won't open a modal window (Like Save, which does open a modal window if you haven't saved before or something like that, but otherwise don't)
What do you guys think?
The crucial factor is whether the menu option requires additional information (input or a selection) before it carries out the operation. So Help-About doesn't require an ellipsis, but File-Open does. That's what the Microsoft, Apple and KDE guidelines say anyway.
Microsoft Windows applications are supposed to follow Microsoft's "User Experience Guidelines". Here's what they say about ellipses on menu items.
While menu commands are used for
immediate actions, more information
might be needed to perform the action.
Indicate a command that needs
additional information (including a
confirmation) by adding an ellipsis at
the end of the label.
This doesn't mean you should use an
ellipsis whenever an action displays
another window—only when additional
information is required to perform the
action. For example, the commands
About, Advanced, Help, Options,
Properties, and Settings must display
another window when clicked, but don't
require additional information from
the user. Therefore they don't need
ellipses.
David's answer cites the KDE 3 user interface guidelines,
Notice that every item in a menu that
first opens a dialog requiring
additional information must be
labelled with a trailing ellipsis
(...) (e.g. Save As..., Open...).
There's no space between the menu item
and the "...". A simple confirmation
dialog is not considered a dialog that
requires additional information.
The Apple Human Interface Guidelines say:
Append an ellipsis to a menu item’s label when people need to provide additional information before the action can complete. The ellipsis character (…) signals that another view will open in which people can input information or make choices.
Old versions of the HIG went into greater detail, and gave examples:
When it appears in the name of a
button or a menu item, an ellipsis
character (…) indicates to the user
that additional information is
required before the associated
operation can be performed.
Specifically, it prepares the user to
expect the appearance of a window or
dialog in which to make selections or
enter information before the command
executes. Because users expect instant
action from buttons and menu items (as
described in “Buttons” and “Menu
Behavior”), it's especially important
to prepare them for this alternate
behavior by appropriately displaying
the ellipsis character.
As far as I understand this, (...) a the end usually means that user will be asked for some input. And no (...) means that no input is needed.
You're right, that about sums it up. If you want to know more, you can find a list of User Style Guides here: http://www.experiencedynamics.com/science-usability/ui-style-guides
I'd agree, that matches my own perception of when to include the ellipsis fairly well.
I guess the point of the ellipsis is to "warn" the user, so that she can understand that a certain choice is safe to explore, it won't immediately do something without asking for more information through a dialog.
In some programs, like (at least older version of) Autodesk's Maya (a high-end 3D modelling package), the ellipsis was actually a small dialog-icon. You could click the icon, in the menu, to get the icon, or click the rest of the menu item (the text) to repeat the command with the same settings as last time, or something like that. It seems that idea didn't catch on and become mainstream.
This is a very tricky question indeed. At first had it might seem obvious but there are many actions that fall between the categories. It is interesting to see that Microsoft themselves violate this practice.
Example from Vista
In Computer Management menu File - Options... has ellipsis
In Computer Management / Users and Groups / Users. Right-click a user. The New user... action has ellipsis but Rename does not although it requires extra actions to actually rename the account.
In Micrsoft SQL Server Management Studio menu File - Print has Properties... button with Ellipsis.
This is just after 5 minutes of investigating. There are plenty more examples.
You can argue for both conventions for both these actions. You can't actually change any properties or options without doing some extra actions in the dialog that is displayed which assumes that ellipsis should be used. However you might just be interested in viewing what options or properties that are defined and that would assume that no ellipsis is used. Microsoft also acknowledge that there are instances when there is ambiguity
"In case of ambiguity (for example, the command label lacks a verb), decide based on the most likely user action. If simply viewing the window is a common action, don't use an ellipsis." However based on this it would make more sense to have ellipsis for Options and Properties as it is probably more likely that you want to change a property that just view it.