I'm not exactly sure what you can (or should) do with *.rc files. Most Win32 example code, including Visual Studio templates, creates the main window programmatically in WinMain. I could create a dialog in the resource script and just show it in WinMain, but I'm not sure if that's the best idea, since dialogs are treated differently than windows. Is there a way to put controls in the main window from a resource script, or should I just create it as a dialog?
The only Win32 API which places controls on a Window are the CreateDialog[Indirect][Ex] family of functions.
The practice of creating a dialog was the root window of the application has been common since 16-bit Windows and even today's 64-bit Windows maintains compatibility with that practice.
Related
I want to add custom actions to every window's title bar context menu. The goal is to add an option like in the task view where you can move a window to a different virtual desktop. I was able to do this with hotkeys using GlobalHotKey and WindowsDesktop packages in C#. But I want to do it in the UI as well similar to some Linux desktop environments.
I know you cannot normally do this with the registry like you can with other context menus. When creating your own application I know you can use GetSystemMenu, AppendMenu, etc. and override WndProc to handle it. But this obviously will not work for what I am intending.
The application Moo0 Window Menu Plus achieves the desired effect but I have no idea how they do it.
I have a feeling the solution is probably somewhat hacky but I would still like to know how it could be done. I am open to using any language to achieve this.
You need to inject into the process, that is the only way to add a menu item.
A shell hook will notify you with HSHELL_WINDOWCREATED when a appropriate window has been created. You can then inject into the process (with another hook type or CreateRemoteThread). Once you have your .DLL in the process you can subclass the window and change the system menu.
You need to create both a 32-bit and 64-bit injection .DLL and I would recommend that you write it in native code, not C#.
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.
I have an application and would like to know what GUI toolkit was used to implement it. The list of DLLs which it uses at runtime wasn't very enlightening, I didn't recognize anything. Tools like Spy++ or UISpy show that the windows have class names like wcl_manager1 (apparently toplevel windows) or wcl_internal_window_class (for anything else). Most of the controls (line edits, check boxes, buttons) don't even have a native window, i.e. no HWND associated.
Does anybody know what GUI toolkit this might be?
Look up ProcessId property and you'll figure it out.
In my case it was CiscoJabber.exe with "20200" window name.
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).
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.