Develop Reference

C# FindWindowEx - I Can't Find Teamviewer Panel

I have a program running on my PC that controls another machine via TeamViewer. It all works fine except that sending a mouse click requires TeamViewer to be in the foreground. I have code that sends mouse clicks to programs like Notepad where the edit panel is called "Edit." But the TeamViewer panel is called TV_REMOTEDESKTOP_CLASS and FindWindowEx fails to find its handle.
Here is my code:
IntPtr handle = WinGetHandle("axie_machine");
if (handle != IntPtr.Zero)
{
var panel = FindWindowEx(handle, IntPtr.Zero, "TV_REMOTEDESKTOP_CLASS", null);
PerformRightClick(panel, new Point(200, 200));
}
Here is the image of Spy++ showing the details of the panel
FindWindowEx returns 0x000000.
Can anyone see what I am doing wrong with FindWindowEx and point in the right direction?

Assuming by WinGetHandle("axie_machine"), you're getting the handle of the TeamViewer window using (part of) its title, then, you're actually getting the handle of the top-level window which your target window whose class is "TV_REMOTEDESKTOP_CLASS" is not a child of. It is one of its descendants, but not a direct child. There's one parent window in between as you can see here:
So, change your code to get the parent window of your target "panel" and then use that to get to the target. The code should looks something like the following:
IntPtr tvWindowHandle = WinGetHandle("axie_machine");
if (tvWindowHandle != IntPtr.Zero)
{
var panelParent = FindWindowEx(tvWindowHandle, IntPtr.Zero, "ATL:03B8D350", null);
if (panelParent != IntPtr.Zero)
{
var panel = FindWindowEx(panelParent, IntPtr.Zero, "TV_REMOTEDESKTOP_CLASS", null);
PerformRightClick(panel, new Point(200, 200));
}
}
Note: You might want to double-check the class of the parent window. It was "ATL:03B8D350" in my version of TV but it might be different for you if you're using another version.

Redirect Direct2D rendering to a WPF Control

I'm developing a drawing application in Visual C++ by means of Direct2D.
I have a demo application where:
// create the ID2D1Factory
D2D1CreateFactory(D2D1_FACTORY_TYPE_SINGLE_THREADED, &m_pDirect2dFactory);
// create the main window
HWND m_hwnd = CreateWindow(...);
// set the render target of type ID2D1HwndRenderTarget
m_pDirect2dFactory->CreateHwndRenderTarget(
D2D1::RenderTargetProperties(),
D2D1::HwndRenderTargetProperties(m_hwnd, size),
&m_pRenderTarget
);
And when I receive the WM_PAINT message I draw my shapes.
Now I need to develop a WPF control (a kind of Panel) that represents my new render target (therefore it would replace the main window m_hwnd), so that I can create a new (C#) WPF project with the main window that has as children my custom panel, while the rendering part remains in the native C++/CLI DLL project.
How can I do that? What I have to set as my new render target?
I thought to use the handle of my WPF window:
IntPtr windowHandle = new WindowInteropHelper(MyMainWindow).Handle;
But I need to draw on my panel and not on my window.
Please note that I don't want to use any WPF classes for the rendering part (Shapes, DrawingVisuals...)

You have to implement a class that hosts your Win32 Window m_hwnd. This class inherits from HwndHost.
Moreover, you have to override the HwndHost.BuildWindowCore and HwndHost.DestroyWindowCore methods:
HandleRef BuildWindowCore(HandleRef hwndParent)
{
HWND parent = reinterpret_cast<HWND>(hwndParent.Handle.ToPointer());
// here create your Window and set in the CreateWindow function
// its parent by passing the parent variable defined above
m_hwnd = CreateWindow(...,
parent,
...);
return HandleRef(this, IntPtr(m_hwnd));
}
void DestroyWindowCore(HandleRef hwnd)
{
DestroyWindow(m_hwnd); // hwnd.Handle
}
Please follow this tutorial: Walkthrough: Hosting a Win32 Control in WPF.

I'll try to answer the question as best I can based on WPF 4.5 Unleashed Chapter 19. If you want to look it up, you can find all information there in the sub-section "Mixing DirectX Content with WPF Content".
Your C++ DLL should have 3 exposed methods Initialize(), Cleanup() and Render().
The interesting methods are Initialize() and InitD3D(), which is called by Initialize():
extern "C" __declspec(dllexport) IDirect3DSurface9* WINAPI Initialize(HWND hwnd, int width, int height)
{
// Initialize Direct3D
if( SUCCEEDED( InitD3D( hwnd ) ) )
{
// Create the scene geometry
if( SUCCEEDED( InitGeometry() ) )
{
if (FAILED(g_pd3dDevice->CreateRenderTarget(width, height,
D3DFMT_A8R8G8B8, D3DMULTISAMPLE_NONE, 0,
true, // lockable (true for compatibility with Windows XP. False is preferred for Windows Vista or later)
&g_pd3dSurface, NULL)))
{
MessageBox(NULL, L"NULL!", L"Missing File", 0);
return NULL;
}
g_pd3dDevice->SetRenderTarget(0, g_pd3dSurface);
}
}
return g_pd3dSurface;
}
HRESULT InitD3D( HWND hWnd )
{
// For Windows Vista or later, this would be better if it used Direct3DCreate9Ex:
if( NULL == ( g_pD3D = Direct3DCreate9( D3D_SDK_VERSION ) ) )
return E_FAIL;
// Set up the structure used to create the D3DDevice. Since we are now
// using more complex geometry, we will create a device with a zbuffer.
D3DPRESENT_PARAMETERS d3dpp;
ZeroMemory( &d3dpp, sizeof( d3dpp ) );
d3dpp.Windowed = TRUE;
d3dpp.SwapEffect = D3DSWAPEFFECT_DISCARD;
d3dpp.BackBufferFormat = D3DFMT_UNKNOWN;
d3dpp.EnableAutoDepthStencil = TRUE;
d3dpp.AutoDepthStencilFormat = D3DFMT_D16;
// Create the D3DDevice
if( FAILED( g_pD3D->CreateDevice( D3DADAPTER_DEFAULT, D3DDEVTYPE_HAL, hWnd,
D3DCREATE_SOFTWARE_VERTEXPROCESSING,
&d3dpp, &g_pd3dDevice ) ) )
{
return E_FAIL;
}
// Turn on the zbuffer
g_pd3dDevice->SetRenderState( D3DRS_ZENABLE, TRUE );
// Turn on ambient lighting
g_pd3dDevice->SetRenderState( D3DRS_AMBIENT, 0xffffffff );
return S_OK;
}
Lets move on to the XAML code:
xmlns:interop="clr-namespace:System.Windows.Interop;assembly=PresentationCore"
<Button.Background>
<ImageBrush>
<ImageBrush.ImageSource>
<interop:D3DImage x:Name="d3dImage" />
</ImageBrush.ImageSource>
</ImageBrush>
</Button.Background>
I've set it as background of a button here, using an ImageBrush. I believe adding it as background is a good way to display the DirectX content. However, you can use the image in any way you like.
To initialize the rendering acquire a handle to the current window and call the Initialize() method of the DLL with it:
private void initialize()
{
IntPtr surface = DLL.Initialize(new WindowInteropHelper(this).Handle,
(int)button.ActualWidth, (int)button.ActualHeight);
if (surface != IntPtr.Zero)
{
d3dImage.Lock();
d3dImage.SetBackBuffer(D3DResourceType.IDirect3DSurface9, surface);
d3dImage.Unlock();
CompositionTarget.Rendering += CompositionTarget_Rendering;
}
}
The CompositionTarget.Rendering event is fired just before the UI is rendered. You should render your DirectX content in there:
private void CompositionTarget_Rendering(object sender, EventArgs e)
{
if (d3dImage.IsFrontBufferAvailable)
{
d3dImage.Lock();
DLL.Render();
// Invalidate the whole area:
d3dImage.AddDirtyRect(new Int32Rect(0, 0, d3dImage.PixelWidth, d3dImage.PixelHeight));
d3dImage.Unlock();
}
}
That was basically it, I hope it helps. Now just a few important sidenotes:
Always lock your image, to avoid that WPF draws frames partially
Dont call Present on the Direct 3D device. WPF presents its own backbuffer, based on the surface you passed to d3dImage.SetBackBuffer().
The event IsFrontBufferAvailableChanged should be handled because sometimes the frontbuffer can become unavailable (for example when the user enters the lock screen). You should free or acquire the resources based on the buffer availability.
private void d3dImage_IsFrontBufferAvailableChanged(object sender, DependencyPropertyChangedEventArgs e)
{
if (d3dImage.IsFrontBufferAvailable)
{
initialize();
}
else
{
// Cleanup:
CompositionTarget.Rendering -= CompositionTarget_Rendering;
DLL.Cleanup();
}
}

It would be possible with WINFORMS probably, but not with WPF.
Here is a documentation talking about how WPF uses HWNDs:
How WPF Uses Hwnds
To make the most of WPF "HWND interop", you need to understand how WPF
uses HWNDs. For any HWND, you cannot mix WPF rendering with DirectX
rendering or GDI / GDI+ rendering. This has a number of implications.
Primarily, in order to mix these rendering models at all, you must
create an interoperation solution, and use designated segments of
interoperation for each rendering model that you choose to use. Also,
the rendering behavior creates an "airspace" restriction for what your
interoperation solution can accomplish. The "airspace" concept is
explained in greater detail in the topic Technology Regions Overview.
All WPF elements on the screen are ultimately backed by a HWND. When
you create a WPF Window, WPF creates a top-level HWND, and uses an
HwndSource to put the Window and its WPF content inside the HWND. The
rest of your WPF content in the application shares that singular HWND.
An exception is menus, combo box drop downs, and other pop-ups. These
elements create their own top-level window, which is why a WPF menu
can potentially go past the edge of the window HWND that contains it.
When you use HwndHost to put an HWND inside WPF, WPF informs Win32 how
to position the new child HWND relative to the WPF Window HWND. A
related concept to HWND is transparency within and between each HWND.
This is also discussed in the topic Technology Regions Overview.
Copied from https://msdn.microsoft.com/en-us/library/ms742522%28v=vs.110%29.aspx
I would recomend you to study a way to keep track of your render area and maybe create a "hideous" child window in front of it.
Other research you can maybe do is to try and find/get WPF graphics buffer and inject your rendered scene directly into it using pointers and some advanced memory programming.

https://github.com/SonyWWS/ATF/ might help
This is a level-editor with an direct2d view included

Hide parent window, but show child window

I'm working on an application that should do the following on start-up:
Connect to an external application using COM (AutoCAD).
Send message to the application to run some DLL code (opens a window).
Hide AutoCAD's window, but keep the DLL's window visible.
I've successfully completed the first 2 steps, but the third is giving me some issues.
I do not know if it is possible to make a child window visible while it's parent is not visible. Every time that I make the child visible or make it the top most window, AutoCAD becomes visible as well.
My objective is to run my DLL code, but keep AutoCAD running in the background, completely invisible to my users. The DLL must be loaded, through AutoCAD, because it allows me to work with AutoCAD's .NET interface as opposed to COM.
In any case, I'm curious if what I'm trying to do is possible, perhaps through some Windows API calls or perhaps something in .NET.
PS: I'm unsure if this window relationship is really a parent-child one. I'm assuming it is though because my window belongs to the AutoCAD application instance due to the DLL loading.
Any help is greatly appreciated. Thanks! :)
EDIT:
DLL Code to create a window.
//CommandMethod is an AutoCAD attribute for entering into the DLL. This code is called
//when the user attempts the command "AUTOCADCOMMANDNAME" or can be done by simulating
//the command programmatically.
[CommandMethod("AUTOCADCOMMANDNAME", CommandFlags.Session)]
public void CommandEntry()
{
MainWindow mainWin = new MainWindow();
mainWin.ShowDialog();
}
Main Application Code
public static void Main()
{ //Use a utility class to create a connection to AutoCAD via COM
AcadApplication acadApp = ACUtil.GetAcadInstance(out createdNewInstance);
acadApp.Visible = false;
//Irrelevant code omitted...
acadApp.ActiveDocument.SendCommand("AUTOCADCOMMANDNAME");
acadApp.Quit(); //Exit AutoCAD application
//Note: doesn't quit until mainWin closes because of ShowDialog()
}

Can't be done. Parent windows control child window visibility.
Your best alternative is to make the DLL window a top-level window (but owned by the AutoCAD window).
Note that the DLL window will still be part of the AutoCAD thread.

What you want can be achieved, despite what others may think. You just need to think about the problem in a different way. Don't think about parent and child Windows... instead, think about a splash screen Window.
Typically, splash screens appear before the main application Window, but does that make them the parent? No, it doesn't. Normally, they'd be closed after the main Window has opened, but there is no reason why you couldn't hide it instead of closing it.
To find out how to do this in WPF, please refer to my answer from the How to open a child Window like a splash screen before MainWindow in WPF? question, here on Stack Overflow. Extending that answer a little bit, I should point out that you won't need to use a Timer. Instead of the code from the linked page, you could do something like this:
private void OpenMainWindow()
{
autoCadWindow.Visiblity = Visibility.Collapsed;
MainWindow mainWindow = new MainWindow();
mainWindow.Show();
}

Haha! I found it!
So, I ended up calling the SetWindowPos function in the Windows API and supplied the handle for AutoCAD window. I did this inside my main application:
[DllImport("User32.dll")]
static extern bool SetWindowPos(IntPtr hwnd, IntPtr hwndInsertAfter, int x, int y, int w, int h, uint flags);
public const int SWP_HIDEWINDOW = 0x0080;
public static void Main()
{
//...Setup AutoCAD...
//Change window size and hide it before calling to open mainWin inside the DLL.
SetWindowPos(new IntPtr(acadApp.HWND), new IntPtr(1), 0, 0, 0, 0, SWP_HIDEWINDOW);
//Display mainWin by entering the DLL.
acadApp.ActiveDocument.SendCommand("AUTOCADCOMMANDNAME");
//Terminate application as before...
}
Basically I'm telling the AutoCAD window to hide by modifying the HWND directly. I also set the dimensions to width=0 and height=0 which causes the window to take up the minimum size possible. Unfortunately, the window will flicker once, but for my purposes, that is negligible. If anyone can find a way to remove the flicker, that would be great! :)
EDIT: When using SetWindowPos, Windows tends to remember the values entered for the next time that application window is shown. This means that if not restored properly, then the next time the user opens AutoCAD manually, it will have the coordinates of 0,0 and the minimum width/height.
To change that behavior, it is necessary to obtain the window information. For my program, I used GetWindowRect obtain the original settings. Before closing my program, I restored those settings using SetWindowPos. See the code below for details:
First, import necessary WINAPI functions and structs:
[DllImport("User32.dll")]
static extern bool GetWindowRect(IntPtr hwnd, out RECT rect);
[StructLayout(LayoutKind.Sequential)]
public struct RECT
{
public int Left;
public int Top;
public int Right;
public int Bottom;
}
Obtain original settings before modifying window:
RECT originalRect;
GetWindowRect(new IntPtr(acadApp.HWND), out originalRect);
Modify the window to hide (and resize):
SetWindowPos(new IntPtr(acadApp.HWND), new IntPtr(1), 0, 0, 0, 0, SWP_HIDEWINDOW);
Restore original settings before quitting:
SetWindowPos(new IntPtr(acadApp.HWND), new IntPtr(1),
originalRect.Left,
originalRect.Top,
originalRect.Right - originalRect.Left,
originalRect.Bottom - originalRect.Top, 0);

Lost focus issue when using WPF and WindowsInteropHelper

I have a problem with hosting a WPF window inside Excel. What we want to achieve is a window similar to Excel 2013 chart icons next to the chart when chart is selected.
The normal logic is already in place, but there was an issue with click on the ribbon or switching to another window and back to Excel. Both of those scenarios resulted in our window getting hidden.
The solution to this is to set the Owner of our WPF window which is not straight forward when combining Excel and WPF windows. The solution for now was this:
// Getting the active window
[DllImport("user32.dll")]
static extern IntPtr GetActiveWindow();
// Using the WindowInteropHelper to bind WPF window to excel
var wpfWindow = new WPFWindow();
var handle = GetActiveWindow();
helper = new WindowInteropHelper(wpfWindow) { Owner = handle };
wpfWindow.Show();
The above code works fine as long as we only stay in Excel. However the following steps produce a problem:
show our wpfWindow from an Excel addin
switch to another program that is currently running (like browser,...)
switchback to Excel
when our form hides the previously selected program becomes activated and is shown on top of Excel
Any solution to this issue? I have read two similar problems here and here, but they don't offer a working solution.

(I realise this is an old question but hopefully will help someone in the future)
This seems to be a known bug with using window.Show() in wpf windows that hasn't been fixed ( here and here )
Forcing focus to the Owner before Closing seems to work for me (Solution posted in the first link):
[DllImport("user32.dll")]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool SetForegroundWindow(IntPtr hWnd);
// Getting the active window
[DllImport("user32.dll")]
static extern IntPtr GetActiveWindow();
// Using the WindowInteropHelper to bind WPF window to excel
var wpfWindow = new WPFWindow();
wpfWindow.Closing += (sender, args) => SetForegroundWindow(new WindowInteropHelper(wpfWindow).Owner);
var handle = GetActiveWindow();
helper = new WindowInteropHelper(wpfWindow) { Owner = handle };
wpfWindow.Show();

How do I display open IE tabs as DWM thumbnails?

I am building a WPF application in C# and I want to display thumbnails of open IE tabs in a listbox. I'm essentially trying to duplicate the DWM functionality in Windows 7.
I have figured out how to enumerate a list of open tabs using Interop.ShDocVW, but in order to use the DWM API calls, I have to pass in an hwnd, and the tabs all share the same handle as Internet Explorer.
So I've been messing with EnumWindows and EnumChildWindows but I can't get anything to work.
Any suggestions on how to best approach this?

This code enumerates window handles that correspond to IE thumbnails and can be used as the hwndSource parameter of the DwmRegisterThumbnail function
public static IEnumerable<IntPtr> EnumerateIEDwmThumbnails()
{
List<IntPtr> ptrs = new List<IntPtr>();
StringBuilder cls = new StringBuilder(100);
EnumWindows((hwnd, lparam) =>
{
GetClassName(hwnd, cls, cls.Capacity);
if (cls.ToString() == "TabThumbnailWindow")
{
ptrs.Add(hwnd);
}
return true;
}, IntPtr.Zero);
return ptrs;
}
[DllImport("user32.dll")]
private static extern bool EnumWindows(EnumWindowsCallback lpEnumFunc, IntPtr lParam);
private delegate bool EnumWindowsCallback(IntPtr hwnd, IntPtr lParam);
[DllImport("user32.dll")]
private static extern int GetClassName(IntPtr hWnd, StringBuilder lpClassName, int nMaxCount);

Update
While specified in the question indeed, I hadn't actually looked into the DWM Thumbnail API and the requirements of the DwmRegisterThumbnail function specifically:
hwndSource
The handle to the window to use as the thumbnail source.
Setting the source window handle to anything other than a top-level
window type will result in a return value of E_INVALIDARG. [emphasis mine]
The emphasized requirement renders my approach with child windows retrieved via FindWindowEx() outlined below invalid, i.e. only FindWindow() might be used to retrieve a handle to a top-level window instead (thanks Simon for pointing this out) - Simon's answer provides an appropriate solution based on the class name of the top-level IE window apparently rendered specifically for this purpose.
[...] in order to use the DWM API calls, I have to pass in an hwnd, and the
tabs all share the same handle as Internet Explorer.
How have you inspected the window hierarchy? If I inspect an IE 9 window with e.g. Spy++, it exposes the following hierarchy of Window Classes (abbreviated):
IEFrame
[...]
Frame Tab
[...]
Frame Tab
[...]
TabWindowClass
Shell DocObject View
Internet Explorer_Server
The child windows have separate handles, so (from the top of my head) you should be able to retrieve the desired ones via appropriate calls to the FindWindowEx function, e.g.:
HWND hwndIeTab = ::FindWindowEx(hwndIeFrame, NULL, "Internet Explorer_Server", NULL);
In order to retrieve all desired tabs, you need to iterate over the results by means of the 2nd parameter hwndChildAfter of FindWindowEx():
A handle to a child window. The search begins with the next child
window in the Z order. The child window must be a direct child window
of hwndParent, not just a descendant window.
So you'd need to iterate via class "Frame Tab" first and retrieve each "Internet Explorer_Server" child window with a second call to FindWindowEx() in turn (though you might want to experiment, whether passing a child higher up via the 3rd parameter lpszClass produces identical or better results).
Good luck!

The solution I went with was using EnumWindows and GetWindowText from the Win32 API. I enumerate through Internet Explorer windows using shdocvw.dll and pass the tab's caption to a method that parses the results of GetWindowText to find the hwnd of the window with that caption.
This works for all IE windows, not just tabs.