Add menu item to windows context menu only for text selection - windows

Someone know where can I add registry key for add some function to the right-click menu only when some text is selected?
Such as copy,paste,cut function
Thanks :)

As per the last comment by #zionpi and the specification by #Math1000 stating "Specifically looking to convert LaTex to plain text", I am assuming that the OP is looking to add an option in the context menu for all strings(or text) displayed(or presented) by all and any applications running in the system, which allows the user to, as per the original question, open that particular selected string in explorer if it is a valid path in the system or, as per the added specification, convert that particular selected string to plain text if it is a valid LaTex code (by copying the converted LaTex code to clipboard, perhaps?).
While the validation of the selected text (to check whether it is a valid directory or LaTex code) and implementation of the operation succeeding the validation can be feasibly implemented without any difficulty, the context menu option requiring to be available for "ALL" texts displayed by "ALL" applications in the system is impossible to implement. This is because there is no way to alter the context menus of individual 3rd party applications as their context menus are regulated and controlled by the application itself by the nature of their source code during development and would require APIs released by the concerned application developers themselves to facilitate this demand.
One infamous application that allows the implementation of such behaviors is Office, for which you can build add-ons to customize certain aspects of the application (whose tutorials can be found here and here (for .NET interoperability)) to implement said requirements.
While irrelevant to the original requirement, it is worth looking into the shortcut menu handlers of the shell extension development process here as it is a better and a much more elegant way of adding/implementing right-click context menus in comparison to the way mentioned in the OP's question i.e. by editing the registry.

Related

How can I register my app for “Open with” (File Type associations) in context menu on Windows 11?

We are trying to update our application to be available by default when clicking "Open With" in Context Menu on Windows 11 for some file types after it was installed.
The doumentation is really poor at the moment. The only place where I found this is mentioned is:
https://blogs.windows.com/windowsdeveloper/2021/07/19/extending-the-context-menu-and-share-dialog-in-windows-11/
In this blog, in Context Menu Best Practices chapter they wrote this phrase without giving an actual example:
---“Universal openers,” like technical text editors, should register to handle * so they will always be offered as an “Open with” option. They should also explicitly register for any filetypes they are optimized to handle.---
Does anyone implemented this or found some better documentation?

How to uniquely identify a control within a window?

I write some automation software. I want to be able to send a message to a particular control of an application. I can find an application, but I need HWND of the control. How can I tell my software to pick that edit over here or that button over there, for example? I inspected several controls with Spy++, but I found no unique persistent properties, see images below:
The only idea I have now is to check control position, but even this is not 100% reliable, since several controls on different tabs of a tab view may have the same position!
What else could I do? How do GUI automation test suits solve this task?
pywinauto automation framework is able to identify control by index like app.SomeDialog.ChildWindow(class_name='Button', ctrl_index=0).ClickInput() which is persistent for each concrete moment if test sequence is deterministic. Also it allows more complicated matching criteria: app.SomeDialog.ChildWindow(title='&Next', class_name='Button', parent=SomeViewContol, predicate_func=SomeFunc).ClickInput().

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.

Controlling multiple Internet Explorer windows?

We've got several web-based applications that are launched from our ERP system (SAP R/3 in this case, but since we're using ShellExec, I don't consider this a SAP issue). The problem is that we can either set the IE to "open every URL passed from the ERP system in a new window" or to "reuse any one of the existing IE windows" (same problem with tabs). Both settings are not acceptable for our users: one of the web applications is a rather bulky medical image viewer applet that wreaks havoc if invoked multiple times. The other option is a no-go either because this way opening the image browser for a patient automatically displaces the lab result display for the very same patient and vice versa.
I'd like to have some control over which window may or may not be reused. My idea would be a kind of "window tag" and a helper program that checks if a window with that tag exists - if it does, reuse it, if not create it. So basically
IELauncher SEARCH http://www.google.com
would open a new window and tag it as SEARCH.
IELauncher DEVEL http://stackoverflow.com
would open a second window, tagging it as DEVEL. Then
IELauncher SEARCH http://www.wikipedia.org
would replace the contents of the first (google) window only.
Is this possible at all? Do you have any pointers for me where to start? I don't even know what to look for...
I had to resort to some rather ugly methods - dynamically assembling a HTML page that uses JavaScript and window.open() to open and access a window by name, then close the page executing the JavaScript. Ugly, but at least this way you get the additional benefit of being able to control certain aspects of the browser window like switching of the menu bar, toolbar and location bar.

Is there a simple way to change the text of the 'Open' button on the windows file dialog to 'Select'?

We're using the file picker dialog to allow users to add documents into our application. The word 'Open' doesn't make a lot of sense in this case.
Thanks.
I would browse the code found here, which shows how someone extended the OpenFileDialog. Admittedly, this is overkill for you. But I think there is code within to change the button label.
Not really no.
Given the standardization of this dialog it's extremely likely that your users will have used it many times in the past to "add" files to applications. The chances are they will be quite familiar with the implications of the word, changing it may be more confusing to them.
The standardness of the dialog is why it's called a "Common File Dialog". If you want to change it for your app, you'll have to write your own dialog.
Having said that, there are apps out there that can pull a form out of a DLL, modify it, and stick it back in. However, this is a per-machine hack and downright bad form.

Resources