I tried titling this, "A Very Stupid Question: WPF, dialog boxes and forms" but it wasn't allowed.
I am writing a WPF program in C#. I created this dialog box:
from within Visual Studio 2010 by selecting Add -> New Item -> Windows Form and then built the dialog box.
I CAN'T CATCH THE 'CANCEL'. Other than that, it works just fine.
Here's how I'm calling it:
AdjustAlpha dlg = new AdjustAlpha();
dlg.ShowDialog();
I've seen a lot of posts about the difference between WPF and Forms. I've tried using System.Windows.Forms, I've tried this:
DialogResult result = new AdjustAlpha.ShowDialog();
if (result == DialogResult.OK)
Throws lots of errors.
IS MY MISTAKE SIMPLY USING A WINDOWS FORM IN A WPF APP?
I think mixing WinForms and WPF is becoming thing of the past. Yet, when you're confined by the project/company/TPS then you do, what you gotta do!
If you need to launch a WPF dialog from WinForms - look up how to use ElementHost.
If you need to launch WinForms' dialog from WPF -create a class that implements the WinForms interface IWin32Window -- pass it's returned handle to WinForm's ShowDialog.
Related
i have a some questions about WPF + MVVM + ElementHost. I try to explain it so clear i can.
I'm building an addin(VSTO 2010) that's mean i need an ElementHost to hosted a WPF.
The first Point mean that my WPF can only be an UserControl (WPF)
Regarding Point 1 and 2 ;
It's possible to build an MVVM WPF(UserControl) having Popup(Children) like this One and which can be hosted into a ElementHost?
I hope my Question is enough clear! Thank u for helping.
You sure can, there are a few gotcha's though.
I have had issues with my WPF control not drawing when initially displayed, so I worked around it by tweaking the width when the Child is set. See http://vstocontrib.codeplex.com/SourceControl/changeset/view/50a83624e34d#src%2fVSTOContrib.Core%2fWpf%2fWpfPanelHost.cs
Next is the MVVM style application you want to build, the main issue around this is the VSTO model around windows/documents/custom task panes are all different, one is based on the open workbook (context), one is windows (view) and custom task panes are also window based (view).
MVVM style apps are built more around the current context, or the current opened workbook, I have been working on VSTO contrib for a while now to solve this problem, it even gives you MVVM like bindings when declaring your RibbonXML ribbons if you need ribbon support.
Grab it at http://vstocontrib.codeplex.com and please let me know if it indeed helps you.
And finally the popup, there is nothing stopping you, but you will find in Office 2007 that when you try to open the window for a second time that Office will probably crash. The following code will make your WPF window experience a bit smoother.
if (System.Windows.Application.Current == null)
new Application { ShutdownMode = ShutdownMode.OnExplicitShutdown };
else
System.Windows.Application.Current.ShutdownMode = ShutdownMode.OnExplicitShutdown;
Basically when you display the first window, all is good, but WPF will spin up a Application, which by default exits when the last window is closed. So when your window closes, then you try to open it again, WPF will blow up :P
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.
We had a big project developed in WinForm. Now I'm adding a new window to the project using WPF. The WPF window is now part of the project, i.e. it is not a seperate project or dll. What happened now is any control that is supposed to accept key inputs, such as textbox, does not respond to my keyboard input. The window only responds to mouse.
If I create another WPF project and call this window, all keys work!
Does anyone know the reason for this? Any work around? Thanks!
When creating your WPF window from your Winforms code, be sure to use ElementHost.EnableModelessKeyboardInterop to allow WPF input to work.
Example:
Window window = new Window1();
ElementHost.EnableModelessKeyboardInterop(window);
window.Show();
I've got this situation. (.net 3.5)
A Winform application that with OleAutomation and Office Interop create an excel, a toolbar and handlers for buttons in the toolbar.
Now we've got some functionality that shows the user modal windows (winform 2.0) with the method:
form.ShowDialog(new ExcelHwndWrapper(objExcelApplication.HWND))
And the "owner" of the modal form is set to the "excel" window.
Now I would like to create some WPF Window instead of Winforms due to layout requirements for new functionalities.
Is there any way to Show a WPF ModalDialog "over" excel Window ?
I found something for showing a WPF ModalDialog "over" a winform, but nothing over excel.
Thanks.
When using VSTO and Office 2007, I've had trouble using WPF Windows as modal dialogues. What I found that worked much better was creating a Winforms Form and putting an ElementHost control inside it, then putting my WPF content inside that.
When I used WPF Windows without the Winforms wrapper I ran into trouble with properly capturing keyboard input, among other things.
As long as you make the ElementHost stretch to fill the entire dialogue it'll look like you have a WPF Window.
I'm adding C# WPF dialogs to an existing C++ MFC app, using a C++/CLI interface layer. I've got things working, except I'm having a problem with modality. For example:
MFC app shows a WPF dialog using ShowDialog. Works as expected.
That WPF dialog shows a MFC dialog using DoModal. The WPF dialog is hidden behind the base C++ app, and is not disabled unless I manually change IsEnabled. Not ideal, but it works.
Now, that MFC dialog is closed. Now for some reason the base MFC app is enabled, when it should still be disabled due to the WPF dialog not having been closed. That's bad, as it now allows the user to do crazy things while the WPF dialog is still open.
I have a feeling that it would work better if I could set parent dialogs correctly. But so far I havent been able to set an MFC dialog's parent as a WPF dialog, or vice versa. And, I don't even know if that'd fix it.
Any ideas?
When opening a CDialog, the trick is to use a WindowsInteropHelper to get the parent WPF dialog's HWND. Then, you can use CWnd::Attach to wrap that HWND in a CWnd class to pass to the CDialog's constructor.
The problem I had was that I already had the CDialog constructed., but not yet displayed. The various versions of SetParent can only be used if your target child window already has a valid handle. I had to write a new function in my CDialog class to set m_wndParent, which is what it uses as the parent when it finally creates the dialog. Then everything works great!
Somehow creating WPF dialogs from MFC dialogs "just works". It's magic.
When showing the WPF dialog, are you using the HwndSource class to wrap the WPF window? If so, you may be able to ::SetParent the WPF window as well as use the HwndSource.Handle property to set the sub-child's parent.