Hosting WPF control in Windows Forms Application - winforms

In my WPF control, i have implemented asynchronous pattern to perform non UI tasks by the following way.
internal static void Execute(Action action)
{
if (System.Windows.Application.Current != null)
{
if (System.Windows.Application.Current.Dispatcher.CheckAccess())
action();
else
System.Windows.Application.Current.Dispatcher.BeginInvoke(action, null).Wait();
}
}
This works fine for WPF applications. When i used my WPF control in Windows Forms Application with the help of ElementHost, i am not able to use the above method, since System.Application.Current will be null.
Now I have to know the following things.
1) Is it possible to access UI thread within my WPF control, when the control has been hosted in Windows Forms Application?
2) If possible, kindly guide me how to achieve it.

I've found an answer. Just initalizing an Application instance does this.
if(Application.Current == null)
new Application();

Related

WPF, dialog boxes and forms

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.

How to find unmanaged window and bring it to front without using user32.dll import

I am working on WPF application. I got a scenario where I need to find a unmanaged popup window when it pops up and bring it to front of the application. I used user32.dll and following code snippet (something like) to achieve it:
private void SetPopupScreenForeground()
{
string popupTitle = "Popup Screen"
IntPtr hwnd = FindWindowByCaption(IntPtr.Zero, popupTitle);
if (IntPtr.Zero != hwnd)
{
SetForegroundWindow(hwnd);
}
}
But when I installed my application in another machine, the code is not working. From internet, I found the reason being the code is running as a service and does not have access in the different machine. Is there any workaround for this issue?
Is there any way to find unmanaged window and bring it to front in WPF application without using user32.dll? Please help.
The issue is actually how Windows handles "desktops". Services run under a special desktop that has no ability to interact with the user's desktop. You will need to communicate using a shared object such as a named pipe.
Here is a duplicate question:
How to use FindWindow() from a service application?
If by service you mean Windows service then those normally can't interact with the Windows desktop at all, so it's not a question of using user32.dll or not.

How to Design a MVVM UserControl WPF and hosted it into a Windows Forms ElementHost?

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

How to identify if an EXE is WPF

I am trying to find out if an EXE is a WPF app or a WinForms app. Any suggestions on how I can go about this?
I have heard that I could use the Reflector tool, if so how would this be done?
Thanks.
Although generally an application can be classed as 'either' a WPF or WinForms application, interoperability is possible such that a WinForms app can 'host' WPF controls and vice-versa. Since your application sounds like it references both sets of assemblies, it could be using both. Just something to be aware of.
Anyway, I've just opened one of my WPF projects in Reflector and some obvious indications it's a WPF application are:
1) There is an App class that has a StartupUri which is a Xaml file (like this)
public class App : System.Windows.Application
{
// Methods
[DebuggerNonUserCode]
public void InitializeComponent()
{
base.StartupUri = new Uri("Window1.xaml", UriKind.Relative);
}
2) There is a XamlGeneratedNamespace in the EXE
3) In the Resources 'folder' there are .baml files (probably within <Application1>.g.resources).
4) The window classes (if you can find them easily in the Reflector tree) implement:
public class Window1 : System.Windows.Window
, System.Windows.Markup.IComponentConnector {
If you really want to trawl through Reflector in detail, WinForms windows will inherit from System.Windows.Forms.Form so you can easily spot if you have both WinForms and WPF in there.
You can check the .exe with code, you do not need Reflector.
Simply find a type in the .exe assembly which inherits from the System.Windows.Application class which is from the PresentationFramework dll (you can do it with reflection).
Now, this isn't a 100% sure method, since theoretically someone could be creating a class which inherits from the wpf Application class, and then not start the app. The definite way is to check in Reflector if that class' Run() method is called.
And the programmatic way to check if the current application in which your code is running is a wpf app is like this:
public static bool IsWpfApplication
{
get { return System.Windows.Application.Current != null; }
}
Open it with reflector and see whether it references one of the PresentationFramework DLLs (then it's likely WPF) or System.Windows.Forms.dll. Note that applications might reference both - in that case, you can't really tell.
Maybe it's easier just from looking at the application. WPF applications are rendered smoother, even with standard controls.
Generally one dead give away is that WPF applications tend to have a different looking focus rectangle on focused items such as buttons or listboxes. The standard Windows focus rectangle is 1px wide and on WPF apps it seems to just look... different.
Also, WPF apps render most elements to memory bitmaps whenever they need to perform some kind of animation and this results in a "fuzzy", almost anitaliased look whenever the particular animation takes place and is displayed onscreen. This effect is noticed in things like, menu highlights, scrolling or general button text after you click.

Will WPF process an App.xaml file if the hosting application isn't WPF?

First I just want to say I am new to WPF, so please excuse my ignorance...
I am creating a .Net plug-in for Rhino 4.0. With the plugin I am developing a UI using WPF.
The Rhino 4.0 CAD engine is an MFC/Win32 application. The plugin will execute after the application is run, and it creates the WPF Window and then "sucks" the MFC Window into it.
So my question is, does WPF look for an App.xaml file to get to Application level resources if the hosting application isn't a WPF app?
If not, what is the best way to store application level resources?
Thanks,
Jason
App.xaml is used as a part of a partial class App : Application.
If your application does not have a WPF based Application class,
you can manually load dictionaries and merge with the application and create a main window and show it (access via static methods of Application class).
Code goes kind of like this.
var reader = new XamlReader();
var dictionary = reader.read("path to xaml file") as ResourceDictionary;
if (dictionary != null)
Application.MergedDictionaries.Merge(dictionary);
var mainWindow = new MyMainWindow();
mainWindow.Show();
WPF projects will - by default - generate an entry point for your application. This entry point constructs and initializes your Application-derived class for you. If you need, you can always create your instance manually, and store application-level resources in it:
App app = new App();
app.InitializeComponent();
app.Run();
Have you tried storing your resources at what MSDN refers to as the 'theme level'?
Within a folder called "<root>\Themes" have a file called generic.xaml.
I haven't tried this for a project that wasn't a WPF application, but the approach might work for you.
my guess is it has to do with how does rhino run your plugin does it run it as a seperate process or does it just call some thing you have defined?
If it does call a function you defined then you could just put the code there that will start the window?

Resources