desktop: window server 2003
Assume i have a cmd.sh that echo a message, here i want to run it in anywhere , when i right click the mouse and choose the echo function.
hope for your answer, thanks
Editing the registry as #dbvega indicates works if you always want the same menu item to appear. This is called a static menu. But if you want to do have more control over your menu item, such as changing the visibility, text, and icon depending on various runtime conditions, you need to create a dynamic context menu shell extension, which involves programming a COM object. This MSDN article describes the difference.
Related
If I right-click on the toolbar > click Customize > click Commands tab > then click the Context Menu radio button, there are a rather large amount of choices. Sometimes what I'm trying to find an item to add or remove, I have to wade through a lot of the choices before I finally find the item and looking for (if I even can). Sometimes the groups are not at all intuitive.
Is there any way I can search the available options in all categories? In Visual Studio itself, or even an extension.
Two options I use:
If you're trying to search for something specific, Quick Launch
should be pretty useful to you. CTRL+Q will take you to it or just
type in the text box in the top right of the main VS window.
Another option that comes to mind: go to Tools->Customize and click
on the Keyboard button. That has a search box for commands that
can also be useful. Tip: make the window bigger to make the list
larger.
I am creating a windows using win32:
HWND mainWnd = CreateWindow(...);
Now I can add gui elements as children of mainWnd. However this soon becomes a bit tedious and I want to use the designer built into Visual Studio to help me.
I noticed that under Add Resource there is a Dialog entry. Among the dialogs IDD_FORMVIEW seems the most general so I added one of these. Next I added gui elements to it using the designer.
Now I want to use this as a child of my mainWnd. How do I do this?
I found some examples using DialogBox, but I do not want a separate dialog, I want this window as a child of my mainWnd.
The designer in Visual Studio is appropriate for creating dialog boxes, not arbitrary windows.
That being said, there are a couple of approaches (in increasing order of difficulty):
Make your main window a dialog. Petzold's book has an example of using a dialog as the main window of the program. (If I recall correctly, it's the calculator example.)
Create the dialog and, before you show it, change its style to WS_CHILD, change its extended style to WS_EX_CONTROLPARENT, and parent it to your main window. For all the navigation stuff to work, you'll have to add IsDialogMessage calls in your message pump. This is do-able, but it's likely hard to get everything working well.
A mixture of 1 and 2 where you create one dialog for your main window, then create a second dialog for the content (with DS_CONTROL), and put the second dialog in the first. I've never tried this approach myself, but it seems like it should work.
Write your own code to parse the dialog resource and create the child windows, which is basically re-doing a lot of the work that CreateDialog does for you.
Given your desire to use the GUI to design the UI, I suspect only the first solution is simple enough that you would be interested.
Use the CreateDialog API to create the window from the resource. If you do not want it to look like a dialog then remove the titlebar style from the resource properties.
To use a dialog created from a dialog resource template you have to specify the DS_CONTROL window style in the template.
Read more about dialog boxes here.
Dialog resources are explained here
The right-click context menus of the source editor, the project items and the solution item, is getting ridiculously long, and two of them even have scrolling now on my 1680x1050 screen.
Is there any way for me to hide items on these menus, even if I have to add an event to my Visual Studio macro-system and find and hide them manually?
Here's examples, many of these items I never use:
Edit1: The current answer + comments suggest I should use the Customize menu item in the toolbar context menus, go to the second tab, Commands, and use the Context Menus radio selection and find the relevant menus there.
Here are 3, which are suggested by comments:
As you can see, they're all empty.
Edit2: After clicking the "Reset All" button in that dialog, for the Solution and Project menus, I got items in the dialog, that I could edit, but the changes did not affect the actual context menu on either a project or the solution file. Also, after restarting Visual Studio, the dialog contents for those two were again empty.
In Visual Studio 2010 you can:
Goto Tools->Customize
Select the Commands tab
Select the Context menu radio button
Select the appropriate context menu from the dropdown list to the right, and delete away
I believe Visual Studio 2008 is similar.
You will need to choose the correct context menu in the Customise option.
Go to Tool > Customise,
Then choose the Context menu as you did in your Edit1 screenshots but choose "Editor Context Menus | Code Window" from the dropdown menu instead.
From there you should be able to delete whatever command you don't need from your context menu. Next, for the other commands that can't be found in Editor Context Menus | Code Window (mostly plug-ins or extensions related commands) you will have to go through other categories.
For example, I am using CodeMaid and when I right click a file in Solution Explorer the context menu below are shown
In order to remove the 'Cleanup Selected Code' command I will have to choose the Project and Solution Context Menus | Solution Folder dropdown option.
Added: Here is my sample reduced context menu (removed Copy, Cut, Paste, Outline Menu and Create Snippet...)
Hope this helps =)
Edit: In case you want to add back the commands you removed you can either add them back using New Command... or just press Reset All. Keep in mind the later will restore all the commands. Thus unless you are really having trouble finding the removed command use the first method.
I use 3 VS extensions and these 3 are responsible for polluting the context menu:
VSCommands
Power Commands
Power Toys
Using their own options dialogue, it's possible to subject showing those menus to pressing CTRL (in VS Commands) or completely disable them (the other 2 extensions)
I'd like to know if it ever makes sense to provide some functionality in a piece of software that is only available to the user through a context (right click) menu. It seems that in most software I've worked with the right click menu is always used as a quick way to get to features that are otherwise available from other buttons or menus.
Below is a screen shot of the UI I'm developing. The tree view on the right shows the user's library of catalogs. Users can create new catalogs, or add and remove existing catalogs to and from their library. Catalogs in their library can then be opened or closed, or set to read-only.
The screen shot shows the context menu I've created for the browser. Some commands can be executed independently from any specific catalog (New, Add). Yet the other commands must be applied to a specifically selected catalog (Close, Open, Remove, ReadOnly, Refresh, Clean UP, Rename).
Currently the "Catalog" menu at the top of the window looks identical to this context menu. Yet I think this may be confusing to the users as the tree view which shows the currently selected catalog may not always be visible. The user may have switched to the Search or Filters tab, or the left pane may be hidden entirely.
However, I'm hesitant to change the UI so that the commands that depends on a specifically selected catalog are only available through the context menu.
The Windows User Experience Interaction Guidelines for Windows 7 and Windows Vista states (pg233):
“Don’t make commands only available through context menus. Like shortcut keys, context menus are alternative means of performing commands and choosing options.”
The Apple Human Interface Guidelines states (pg189):
“Always ensure that contextual menu items are also available as [pulldown] menu commands. A contextual menu is hidden by default and a user might not know it exists, so it should never be the only way to access a command.”
In your case, opening and closing the catalogue appears already available through the +/- buttons in the tree itself, so you’re already consistent with the Windows guidelines, if not the Apple guidelines. IMO, the only reason to put them on the context menu at all is if they're the default (double-click) action (which they're not right now). Rename may also already be available by directly selecting the name of a selected catalog, but you may want a pulldown menu item for that any way since that may be no more discoverable than the context menu. The rest of the commands probably belong on a pulldown menu in addition to the context menu.
As far as the Catalog pulldown menu being redundant with the Catalog context menu, you may want to consider organizing your pulldown menus by type of action, rather than class of object, in order to provide an alternative organization. As you’ve realized, context menus already organize commands by class of object. In addition to providing an alternative organization that some of you users may find more intuitive, this may simplify your menubar. For example, rather than a Catalog and Family menus, you can have a single Edit menu with Add, Delete, Rename, Copy, etc. where these commands apply to whatever is selected, whether it be a catalog, folder, or family. If they don't apply to the current selection, they're disabled, but if it makes any sense in your app, make them apply.
BTW, what’s the difference between Add Catalog and New Catalog?
In general, it's a bad idea to have menu items accessible only through a contextual menu. Many users may not think to right click on an item to find out what actions can be performed on an item.
From your description, it sounds like it would make sense to have a 'Catalog' menu that disables menu options that are not currently relevant. For example, if no catalog is open, the 'Close' menu item would be greyed out. Similarly, the 'Open', 'Remove', 'Refresh', etc. items would be greyed out if no catalog is selected.
I suppose this depends on your user base, and who you're targetting your software at. Personally I wouldn't expect the user to be able to deduce what functionality is available when it is essentially "hidden" until they right-click on the correct item.
If it were me, I'd have a toolbar shown with the functionality exposed on there. By default the buttons would be disabled, and clicking on a node would enable the appropriate buttons based on the context. You could have this in addition to your current right-click options.
As a rule, I've always treated right-click menus as a redundant (i.e not necessary for operation of the software) shortcut to functionality for "power users".
I would leave the menu item out because the user doesn't have a way to see what catalog they are modifying if the treeview is hidden which can create problems if they think a different one is being shown.
Though, the accessible solution would be to trigger it with the keyboard also.
Yes. One key feature of UI is "discoverability": can the user find the function?
If you think that having a top-level menu doesn't make sense, based on the context, then you could have a menu button (scroll down) labelled (e.g.) "Actions" at the top of the pane.
I want to add an item into the Desktop context menu (the menu you see when you right-click on an empty space on the Windows Desktop).
Something like Catalyst Control Center in this screenshot:
I know how to add items to files' and folders' context menus through registry, but the Desktop seems to work differently: I didn't even find the text in the registry.
So, how can I add a new item into the Desktop menu and how can I associate some code with it?
I think the solution is language independent, if it's not, I'd appreciate any code that helps.
Such a handler must be registered in HKCR\Directory\Background, instead of usual locations like HKCR\Directory, HKCR\Folder, etc.
Check out Creating Shell Extension Handlers in MSDN.
There's a series of articles on CodeProject that details writing Shell Extensions and is very good:
http://www.codeproject.com/KB/shell/shellextguide1.aspx