One of the parameters of the Win32 API function FindWindowEx is the Class Name of the window. For example, the Class Name of Microsoft Word is "OpusApp".
If I have developed my own application, what is going to be the Class Name of the windows of the app?
Can I set this Class Name to whatever I want?
You didn't notice when you created your window, that you had to call RegisterClassEx (or plain RegisterClass)? ;)
Each window has a class. When you create your own, you specify its class.
*Edit: given your ambiguous tagging, I'm not really sure how you wrote your app. If you're using .NET then you obviously didn't have to manually call the C++ function RegisterClass.*
Regardless, when created, each window is associated with a "class", which describes certain common properties for all windows belonging to that class.
Related
I'm writing a regular class library in .NET Framework (Windows). When someone is calling a certain method in that class library, I want to move the caller's main window (if any) on top of other application's windows (although not permanently).
At first I assumed I could use the Application class to get the main window (Application.Current.MainWindow) but the Application class seems not available...?
Is there a way to do what I want without resorting to native P/Invoke calls? If not - what can be done with P/Invoke when all I know is my current thread?
I have a problem with a window class name, which I get by window's Win32 method - GetClassName.
My application is in .NET, C#. When I run my application for the first time, the class name is WindowsForms10.Window.8.app.0.2dac507_r13_ad1. Then I close the application and my settings are saved in user.config (it's very important). When I run application for the second time, the class name is WindowsForms10.Window.8.app.0.338574f_r13_ad1. Then I close the application and run it again, the class name will be always the same. But when I restart my PC, the process is repeated, it means that the class name as when the application is run for the first time. Why ? Why isn't the class name the same every time I run the application?
I need it to get a window of another application. I'm trying to get it by the method FindWindow. It is true that we can use the title of the window for this method, but I need a class name, too.
It is important to mention that in case of other applications, which do not save settings, the class name is always the same, after each execution.
So, where is the problem ?
Thank you.
I am developing a (in-process) plug-in to application and as part of my plug-in I want to replace the application's tool-tips with my own. However, there is no API available for me to do so, so I've decided to go low-level.
I know the window class of the tool tip, but the question is, how do I detect it being created and how do I close it afterward?
Here's what I thought to do so far:
Create a system-wide hook on WM_CREATE
When caught, check the class and the process of the WM_CREATE target
Verify it is indeed the window I care about:
If the process is the one my plug-in is sitting in
And if the class is of the correct type
And if the correct application is in focus (in case of multiple applications)
Send a WM_DESTROY to the created window and create my own window at its position instead
How does it sound? Assuming there is indeed no API to handle the tooltips, is there a simpler way for what I need?
Thanks!
P.S Tagged as C++/C# as I intend to write it in these 2 languages (C++ for system-wide hook, C# for everything else)
If you know the type of the window you want to block, you can simply subclass it and handle the destruction in your own WndProc. Use GetClassLongPtr() with GCL_WNDPROC on the tooltip class, use SetClassLongPtr() with GCL_WNDPROC to set your own WndProc and have it call DestroyWindow() on WM_CREATE and call the old WndProc for the rest..
This won't work. Consider the view of the application that you're replacing the tooltips of and assuming that you could tell it to destroy windows. What will happen when the app decides that it needs to close the tooltip? It doesn't have the handle of your new window, it has the handle of the old window, which you've destroyed. Time for things to go wrong.
Your plugin system needs to explicitly support replacing the tooltips if you want this to work smoothly. Perhaps an optional part of the plugin framework could be a RequestTooltip function. If it doesn't exist, or returns null, or whatever then the default tooltips are used, otherwise your plugin provided ones are used.
I'm trying to show hidden form in process1 from another one was called by :
Process.Start(#"F:\MyOtherFormPath\MyOtherForm.exe",this.Handle.ToInt32());
As you can see i passed the handle number of the hidden form ,which i'm calling the "MyOtherForm" from, and i used this number to get a handle and show the hidden form from my "MyOtherForm" like this :
Form newFrm = Form.FromHandle(new IntPtr(long.Parse(handleNumberOfMyHiddenForm)));
newFrm.show();
But it didn't work, any way to do this .
P.S: it didn't throw any exception .
thanx in advanced ..
What you are trying to do is not possible, it is a miracle that you didn't get an exception. A window handle is valid between processes, as long as they run in the same session. But Control.FromHandle() can only find controls that were created in the process from which it is called. In your case it should return null.
Making the form in the other process visible is actually possible, you'll have to P/Invoke ShowWindow() using SW_SHOWNORMAL. Visit pinvoke.net for the declaration. Use Handle.ToInt64() so it will work properly on 64-bit operating systems.
The handle that you pass is not valid in the other process.
In order to accomplish what you would like to do you will have to use some way of inter-process communication. In .NET this can be handled e.g. using WCF or .NET Remoting.
Another way to control other application would be using P/Invoke or user interface automation (System.Windows.Automation namespace).
I have written an Office shared Add-in with C# and .NET 2.0. It uses the same COM Shim for all office apps. Currently, every instance creates its own instance of my class -- they have no knowledge of the fact that the add-in is running on another application.
Is it possible to make it so that, say, when the Word add-in launches it can detect that the Excel add-in is already running? Can they communicate between each other?
Let's say my dll is called Addin.dll. When, for example, Word opens, it runs the code in Addin.dll that implements the IExtensibility interface, and creates a class, let's call it WordAddin. When Excel opens, it also runs the code in Addin.dll, and it creates an instance of ExcelAddin. Now, suppose that Word is running and WordAddin exists. When Excel is opened, Addin.dll is loaded into a different AppDomain. It has no knowledge that WordAddin exists. I want ExcelAddin to have know WordAddin exists, and be able to communicate with it, perhaps through a parent class that creates both.
Anyone know how to do this?
You could do this using a Microsoft Message Queue (MSMQ): Use Microsoft Message Queuing in C# for inter-process communication
This code project article shows how to detect a running instance and how to copy command line parameters between them:
Single-Instance C# Application - for .NET 2.0
Not quite what you are asking but might be of interest: Detecting a running instance of a program and passing it information
I ended up using named pipes to communicate between processes
I have in fact done exactly what you're asking about. I went for old fashioned windows messages. Nothing fancy - so it will just work! :-)
Let your addin create a "window" using the NativeWindow class and give it a predetermned, unique name. Then search for another instance of such a window using GetWindow and GetWindowText when your addin launches. Communicate using SendMessage or PostMessage. Easy as that.