I currently have LibVLC setup with a C# project and it uses a Panel to output the video stream. As WPF is better suited for some GUI options I want to implement, I have now switched my project over to it. However, I noticed that WPF Controls don't have handles like C# controls do.
I have found these...
http://wpfmediakit.codeplex.com/
http://videorendererelement.codeplex.com
However I am new to WPF and have no idea how to actually integrate them. What would be the best approach to output the video streams from LibVlC in WPF?
I managed to resolve this by using a WindowsFormsHost control and just use a Panel as I was doing previously in my Win Forms application. Still seems that using something else native to WPF would be preferable, but for now this is working fine.
I'm afraid that's not possible...
Since WPF controls are not Win32 controls behind the scenes (the MS specific HWND or the more general HANDLE), like most WinForms controls are, providing a HANDLE to libvlc for rendering is not possible or not easy.
See here
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.
You could try to use a Window and attempt to get its Handle like this:
IntPtr windowHandle = new WindowInteropHelper(windowInstance).Handle
Then pass this handle to libvlc. Remember to obtain this handle no sooner than inside the Loaded event of the window, see here
But this will limit you to using a top level Window control, which doesn't seem to be what you want.
Related
Here's what I am trying to accomplish - To create an MDI application in WPF, which can host child web applications. I am using WPF webbrowser control to render web applications. WPF inherently doesn't seem to support MDI applications, so after a bit of searching, I found this project, which uses UI controls to simulate windows and manages them inside a WPF canvas. This approach seems to work reasonably well until I start adding webbrowser control object as an MDI child.
When I add webbrowser control as an MDI child, it always appears on top of other WPF elements including other MDI child controls (as shown below). From what I understand, webbrowser control always appears on top of any other WPF object except for window (and popup). Assuming that's true, I think I need to use actual WPF window to avoid overlapping issue.
The only solution i can think of right now is to wrap WPF window inside an HwndHost object and then add that as an MDI child. However it appears that a child window cannot have title bar. That means that i need to have a window that has a dummy title bar area (just like actual window title bar) and actual content area (which will show webbrowser control) as shown below (Red border is HwndHost object).
This approach seems to solve the overlapping issue. The next thing i need to try is to let users click on the dummy title bar and drag the MDI window inside the canvas element.
Questions -
Is my understanding about WPF webbrowser control overlapping behavior right? If not, what am i missing?
Is the second approach a step in right direction for accomplishing what i want? If yes, how do i implement the drag behavior for HwndHost?
Is there any other alternate solution i can try?
Note:
Although many consider MDI not an elegant solution, I do not have a choice. (We tried alternate solutions like tabbed windows/dockable
windows, but were not well received)
I am quite new to interop programming, and do not understand the
concepts well. Please correct me if i am misunderstanding things.
Thanks!
Is the stuff that is displayed when you create a GUI with WinForms or WPF still based on the native controls like Common Controls or any of the system provided Window Classes or is everything that is displayed "custom" drawn by the framework?
Note: I'm not talking about stuff like a file dialog, but GUI that was actually implemented with WinForms or WPF.
And yes, this is purely out of interest.
User HighCore commented:
WPF Uses an "HWND" for the Window objects, but then all other objects
(Controls) inside the Window are WPF objects not related to Win32 in
any way, wheareas AFAIK, winforms uses a separate HWND for each UI
element.
And indeed, using Spy++, we can observe the following when we create a test app with a simple dialog/window and a button on it:
MFC/native:
The app window is a Window (HWND) with the Window Class of #32770 (Dialog) (I used a "Dialog based" app.)
The Button is a separate Window (Class: Button)
Windows Forms:
The app window has the Window Class WindowsForms10.Window.8.app.0.2bf8098_r20_ad1 (oh my)
The Button is a separate Window (Class: WindowsForms10.BUTTON.app.0.2bf8098_r20_ad1)
WPF
There's only one top level Window, although for good measure I added a ComboBox, a ListBox, and a Menu to this window in the UI designer.
The Class of the only Window is: HwndWrapper[WpfApplication1.exe;;9b1aec0f-1b88-419c-8730-858906314cd9]
The Window Class names are actually quite interesting: With the MFC/native one you get the classes known for years and documented on MSDN. With Windows Forms, it does appear that it always uses the same class names. And with WPF it seems the name of a Class of a Window also incorporates the executable/process name.
So apparently MS thinks that using more than one Window per window isn't necessary anymore. I think I need to open a second question for that.
Windows Forms uses native controls for some UI elements. WPF draws everything on its own.
I've done some searching, but I can't find an exact answer on this. In my C# WPF app, I get the HWND pointer and pass it to a C dll. That C dll then attempts to use GDI calls to render an overlay of sorts on my window. There are no errors, but nothing appears. If I switch to a Windows Form, the dll can render over it fine. If I host a WindowsFormHost control and use the hwnd from there I have the same effect. I've seen information on the HwndHost control but it doesn't really look like what I want. Perhaps someone with more knowledge of that control can tell me differently. I read somewhere that an hwnd used for DirectX rendering (like WPF) can't also use GDI. Does this make my scenario impossible? I could fake it by overlaying a borderless form over the WPF window, but obviously that wouldn't be too pretty. Any thoughts or ideas?
You can't have WPF and GDI rendering to the same hwnd but you can easily have a child hwnd inside of your WPF app and let GDI render into it. Take a look at HwndHost for doing that. The section "Hosting a Microsoft Win32 Window in WPF" in this article has a little more details. It also talks about the various issues you'll run into (like airspace) when doing this type of interop.
Is it possible to have a project containing both Winforms and WPF?
Say a WinForm project that is transformed step by step(form by form) in a WPF one, will be possible to have a Winform opening on a button, and a WPF one opening on a other button?
Yes. You have to pick one technology to display each physical window and control in your app, but there's no reason why you can't mix and match.
For example:
A WinForms window can show a WPF window.
A WPF window can show a WinForms window.
A WinForms window can contain WPF content (see the ElementHost control).
A WPF window can contain WinForms controls (see the WindowsFormsHost control).
This works great.
One can have WPF windows in Windows Forms and Windows Forms windows in WPF
http://msdn.microsoft.com/en-us/library/ms745781.aspx
http://msdn.microsoft.com/en-us/library/system.windows.forms.integration.windowsformshost.aspx
Adding Winforms to WPF projects can be done smoothly (directly from the "Add new item" menu), but there is not straight option to add a WPF window to a Winforms project. Still, I handled to do it following these steps:
Add a WPF User Control (this option is available on the "Add new
item" menu) and then convert it into a WPF Window. Modify the XAML
changing the UserControl parent tag to Window, and remove the
inheritance from UserControl (all of this is explained in this link).
Add a reference to System.Xaml.dll. See this link.
Add a reference to System.Windows.dll (I found it on my computer on this path: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5. Be aware it might be different in yours). See this link.
What you might be looking for is the ElementHost control. What it lets you do is take WPF content and host it in a Windows Forms window. More details are here:
http://msdn.microsoft.com/en-us/library/ms745781.aspx
There is also a control that lets you do the reverse: host Windows Forms content from within WPF:
http://nayyeri.net/host-windows-forms-controls-in-wpf
Between the two, you can move the 'dividing line' between WPF and Windows Forms with some degree of flexibility.
There is at one caveat you'll need to keep in mind. Windows Forms works internally in terms of HWND's... a window managed by the legacy Windows window manager (which handles the z-order). WPF doesn't do this... A WPF tree is typically rendered into a single HWND', and it's WPF that manages things like z-order. What this means to you is that z-order doesn't always work the way you expect it to, and there are things you can't do with hosted Windows Forms controls that you can do with traditional WPF elements. (There is actually a way to solve this, but it involves periodically rendering the HWND into a memory bitmap, rendering that bitmap into a WPF surface, and then redirecting events directed to the WPF surface to the underlying HWND. This is powerful, but tricky and difficult to get right.)
I see no objection to do that.(I have in WinForms Application WPF windows)
Many of the examples used MessageBox.Show which is part of the Windows.Forms.
Of course you must rewrite all windows, not only controls.
I'm creating a HUD window for inspecting biz entities in my WinForms application.
I wanted to have a completely different style of window (minimize the content area and showing only the TitleBar, no system buttons, etc) so I created a WPF application for this.
The problem is that I want this Window to 'live' inside my WinForms application. I can't just add the WPF as an OwnedForm or set the main Form as the Owner of the WPF window.
So, how can achive this?
EDIT: Thanks to pst I found the answer. Here is the snippet:
System.Windows.Forms.Integration.ElementHost.EnableModelessKeyboardInterop(_inspector);
WindowInteropHelper inspectorHelper = new WindowInteropHelper(_inspector);
inspectorHelper.Owner = this.Handle;
_inspector.Show();
A WPF Window has a Win32-window handle/context.
See WindowInteropHelper. You can use this with Win32 (or perhaps there is WinForms support?) to set the owner window of the WPF Window. Be aware the handle does not exist until the "source initialized" (?) event.
However, using just WinForms, you may be able to customize the titlebar as much as you need (you can overwrite the drawing itself via Win32, and I think you lose all the control boxes without going this far).
There are lots of google results on this topic if you use the correct keywords.