Custom Title Bar Context Menu Actions - windows

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#.

Related

How do I let glade define a GtkDialog's transience

I'm trying to create dialogs that 'lock' the parent window, but without touching the gtk_window_set_transient_for function.
I notice that Glade allows me to set Transient For and Attach To values, but if I connect those with my parent window (defined in the same glade file) and run the program, it is not transient.
Do I need to do anything else? Does this way even work?
So it does work. I didn't fully realize however that the a locking dialog also needs to be set to be modal.
So to solve my issue I had to also tick the Modal property.
Furthermore, it's also important that both the dialog and the window are loaded from the same builder instance.

Handle GUI window changes

I'm doing an automation script for installation wizards using AutoIt. I'm trying to handle window changes in some way.
Can some one explain how these GUI's work?
When I click on the Next button it looks just like the components in the GUI is beeing changed. Is this tha case? Or is a new window created and the old destroyed?
I've noticed that the process ID is the same for all windows.
I'm sure there is some way to know which "state" the GUI is in, or which step?
By the way. All the windows has the same title.
Thanks
/Anders
This will be dependant on the program you are automating.
The easiest approach would be to look at what changes in the GUI between stages, likely candidates are if there is a label that is giving instructions for that step, or a button that has text changing (e.g. if the button says "Finish" then you know your at the end).
Most installer programs have child windows for grouping the controls of each stage. These are typically implemented as dialog resources (as can be seen when using something like reshacker on them). So although the window remains the same, the panels are being created/destroyed as appropriate. This is a very neat method of doing it, for the obvious reason that you don't need to have to code to create/destroy a lot of controls. Resource created dialogs don't have nice class names like windows sometimes do though, so this may not be a reliable way to check the state.

Is there a way to parent a standard Windows dialog inside another form?

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.

Applications hook

I would like to make some hook in windows programs. For instance, Vodafone application have some MSN like popup that can't be hiddent. So, in that way, I would like to create my option to hide or not this popups. Can anybody tell me some tutorials (basic first) how to do that?
Thanks in advice.
You have to create system wide windows hook with SetWindowsHookEx with first param WH_CBT. You can hook on HCBT_CREATEWND event and return non zero value and window will be destroyed, but first you have to somehow recognize that this is right window, maybe according to window title or something inside that title.
Another thing is that you can't use managed code and C# for system wide hooks, since you have to make unmanaged dll in witch hook will reside. So you have to use C++ or Delphi, and if you are not experienced in win32 programming that would probably be very complicated task.

How to disable cut, copy, paste, rename, etc from the Windows Registry?

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.

Resources