I understand the process needed to customize a right click menu going through the regedit etc. However I need to the ability to go multiple levels such as in applications like WinZip. Here's a picture for clarification of what I need
alt text http://img14.imageshack.us/img14/9658/multiplemenus.jpg
You need to write a Shell Extension; there is a guide for writing one in managed code (C#) here. It will involve doing a bunch of interop and implementing COM interfaces that the windows shell will consume, namely IShellExtInit and IContextMenu.
However, one could argue that writing a Shell Extension in managed code is not advisable; it will force windows explorer to load the CLR, (or any app that uses the standard windows 'Open File' dialog) - native code (C++) would be a better choice for this.
Related
I have an old DOS application which accepts some files as input, does some calculations and saves results into file system. This app uses terminal as sort of GUI, where you can choose input files, types of calculations to perform and choose where to save the result. I don't know the logics behind calculations and am not able to reuse them in a new project.
The problem is that the users of this app want a modern looking GUI which will be easier to work with.
That is why, I have an idea to create an adapter which will translate button clicks into commands in DOS and grab text output to show in modern GUI.
Is it possible and where should I start from?
It is possible. How to start from depends on your programming Tools. If you use a RAD tool like Delphi or Lazarus or Visual Besic or ... then make your GUI design first and define Events after. For a Button click it is ButtonXClick(); In the RAD tool you will find a object inspector with properties and ther values and Events and their values. Go to Events page there, look for onClick-event. Double click there in the value line and you will get an empty Event handler, wehre you can write your Code for your application.
If you dont have or use such RAD tool, take a GUI Framework for DOS. Create your frontend and write your Code which is to call in Dependance of your button clicks.
I know it's possible to take a dialog that you built yourself and parent it on another form. But is it possible to parent a standard Windows system dialog on a form that you designed?
Specifically, I'm trying to set up a form with multiple tabs that provide different ways to obtain a reference to data used by the program. One of those tabs should represent the file system, and the ideal way to do this would be with the standard Open dialog that can be instantiated with the COM identifier CLSID_FileOpenDialog.
Is there any way to take a system dialog and cause it to appear parented on another window, without the border, title bar, etc?
There are ways to use a hook, either via SetWindowsHookEx() or SetWinEventHook(), to grab a system dialog's HWND, then you can do whatever you want with it, such as call SetParent(). But just because you CAN does not mean you SHOULD. System dialogs are designed to run as their own windows, not embedded in someone else's window. A better solution might be to use the same Shell display components that are used by Windows Explorer (and system dialogs) via IShellFolder::CreateViewObject() or SHCreateShellFolderView(), or find a third-party solution that does the hard work of interacting with the Shell for you.
Is there anyway to extract text from application UI by using C++ or C# (lets say like the text on the UI of steam launcher ) ? I need extract the text in order to do some automation of the application.
Have a play around with spy++, it's a tool that comes with Visual Studio. If spy++ can dig down to see the UI elements then you can build a program that does the same.
You can do it winth winapi, there are scripting languages that makes it easier:
http://www.autoitscript.com/site/autoit/
Basicly you should locate somehow your control you want to read, spy++ is a good example, then read it either using its order in window hierarchy or class name.
I'm trying to create a software in VB.Net as my uni project to disable the following from a Windows 7 pc. I think they have to be disabled from the context menu of the Windows Registry, but instead of disabling the whole context menu, I'd like to disable the following individually.
Cut, copy, paste, rename, delete, open, print, share, create shortcut, open with, send to, new, properties.
I want to give users the option of disabling them selectively/individually via checkboxes so those options will be disabled in the right-click of a mouse.
My problem is I don't know which is the right key to disable as the registry is so huge & some keys are similiarly named.
Could anyone help me to say what are the exact key locations of the above-mentioned right-click functions in the Windows Registry or how to go about this ?
The deep flaw in the assumptions made in this question is that the context menu is configured by registry entries. It is not. Windows allows modifying a window's context menu by sending the WM_CONTEXTMENU message. Code, not config. If you are not happy with the default implementation of that message then you subclass the window procedure and provide your own message handler for that message so you can display your own context menu. This is core to the way Windows works.
Modifying the context menu of a program you didn't write is possible too but much more complicated. You use SetWindowsHookEx() to inject a DLL into the other process. You cannot write a DLL like that in VB.NET, it requires native code. Because that process won't have the CLR loaded to run your managed code.
How do tools like SVN and Git attach themselves to Windows Explorer, such that they add options to the right-click menu as well as adding the tick/exclamation mark based on whether a file has been edited?
(I'm not after Git or SVN-specific information - I just used them as examples)
What you want is called Shell Extensions, are in-process COM objects which extends the abilities of Windows operating system.
(source: csscript.net)
you can see these links
The Complete Idiot's Guide to Writing Shell Extensions - Index
Registering Shell Extensions
Bye.
Explorer allows DLLs to register as shell extensions. A shell extension can provide context menu items, icon overlays and numerous other features. It does this by exposing certain COM interfaces which Explorer calls e.g. prior to displaying a menu or icon. Here's the MSDN home page for shell extensibility -- though oddly enough the stuff about context menus and icon overlays no longer seems to be there -- you may have to try the offline SDK under Win32 and COM Development | User Interface | Windows User Experience | Windows Shell | Shell Developer's Guide | Integration of Applications into the Shell.
Depending on the shell extension you want, they can be QUITE complex to implement. I don't know what you're looking for, to quickly write a nice extension, or to get in to the nitty-gritty and learn all the hands-on of it all.
If you aren't as concerned with the how, and just have some ideas you want to implement, check out this library for writing shell extensions...
EZShellExtensions MFC
EZShellExtensions.NET
There are a lot of different types:
- Context Menus
- Property Pages
- Icon Handlers
and many more...
They also have another library for writing namespace extensions (things that show up in the tree pane of Windows Explorer).