I have an application I'm developing which closely mirrors Windows 7's Device Stage. In Device Stage, beneath the main banner there is a ListView containing actions embodied as ListViewItems.
In my WPF application, I used WindowsFormsHost to host a WinForms ListView so that I could use SetWindowTheme() on it and apply Windows Vista/7 styling to it.
This, however, does not work and doesn't achieve the same effect it does when used in Windows Forms.
How can I achieve the Windows 7 look on a ListView in WPF? I'm not looking to create a custom style then apply it because frankly that's too much of a pain in the ass to continue using WPF for this app.
Thanks! :)
Just add the following lines:
[DllImport("uxtheme.dll", CharSet = CharSet.Unicode)]
public static extern int SetWindowTheme(IntPtr hWnd, String pszSubAppName, String pszSubIdList);
.ctor
{
System.Windows.Forms.Integration.WindowsFormsHost.EnableWindowsFormsInterop();
System.Windows.Forms.Application.EnableVisualStyles();
SetWindowTheme(MyControl.Handle, "Explorer", null);
}
Apparently after digging around, the only answer does indeed appear to be creating a custom-designed control in WPF.
Related
This is my first question in StackOverflow. Due to lack of reputations, I couldn't post any links or images.
I've been working on the following issue for more than 2 days. Any help would greatly be appreciated.
Before I get into my question, here is what I have and what I'm expecting:
I have a Windows Form which hosts WPF in an ElementHost control.
And then, I have a Winforms UserControl similar to DateTimePicker. This
is hosted inside a WindowsFormsHost control.
The above scenario is un-avoidable for the following reasons:
The authorization dialog to all our applications is developed in
Winforms, and takes a Winforms instance as its parameter. There is no
WPF version introduced yet. Therefore, I had to use an ElementHost to
host my View inside the Windows Form.
The Winforms control hosted inside my WPF is also un-avoidable. We
have our own DateTime Winforms UserControl that behaves similar to
the DateTimePicker Winforms control, but has lot more complexities
involved. So, replacing this control with a WPF version is out of
question.
Expected Functionality:
I have a
WPF control (say, a textbox)
A DateTime Winforms UserControl that I was mentioning above.
And a Cancel button that basically resets the above controls.
When I hit the Cancel button, I'm publishing an event from the ViewModel, say RunViewModel to the WPF UserControl code behind file, say RunView.xaml.cs.
eventAggregator.GetEvent<ResetDateTimeEvent>().Publish(true);
In the code behind file, I've subscribed to the event as follows
eventAggregator.GetEvent<ResetDateTimeEvent>().Subscribe(ResetDateTimeHandler);
The WPF control resets to its default value, but the DateTime UserControl does not reset.
So, for testing purposes, I removed the ElementHost control, and just had my WPF View with a WindowsFormsHost control that hosts the DateTime Winforms UserControl, and a WPF "Cancel" button.
When I click on the button, the value on the DateTime control resets to its default value.
Then, I thought this might be an issue with my DateTime Winforms UserControl.
So, I replaced my DateTime Winforms UserControl with a Winforms Textbox control in my actual application. So now the nesting is as follows:
WinForms-ElementHost-WPF-WindowsFormsHost-Winforms Textbox
Here is the xaml code.
<WindowsFormsHost x:Name="ReportFromDtTmHost" Margin="8,0" Grid.Column="0"
LostFocus="ReportFromDtTmHost_LostFocus">
<WindowsFormsHost.Child>
<winforms:TextBox x:Name="ReportFromDateTime"/>
</WindowsFormsHost.Child>
</WindowsFormsHost>
On Initial load, I’m loading the Textbox with Initial Load Text text
private void Window_Loaded(object sender, EventArgs e)
{
ReportFromDateTime.Text = "Initial Load Text";
}
As I was mentioning above, when I hit the Cancel button, this is what happens:
Publish the event from ViewModel
eventAggregator.GetEvent().Publish(true);
Subscribe to the event in the code behind file (xaml.cs):
eventAggregator.GetEvent().Subscribe(ResetDateTimeHandler);
EventHandler for the published event.
private void ResetDateTimeHandler(bool cancelClicked)
{
ReportFromDateTime.Text = "Reset to Default";
}
As you can see in the above code, I’m resetting the Text on clicking the Cancel button.
During Debugging, I could see the Text property being changed to "Reset to Default", but the UI does not show these changes.
Here is the wierd part:
The Child property on the WindowsFormsHost control is different from the actual “ReportFromDateTime” Textbox control.
While debugging, I could see that the Child and Name property on the WindowsFormsHost control were different.
The Name property is empty,
ReportFromDtTmHost.Child.Name = ""
which rather should be ReportFromDateTime.
It almost seems like the Host and the Child controls are getting re-created.
As far as I see it, I think the extra level of nesting (WinForms-ElementHost-WPF-WindowsFormsHost-Winforms Textbox) might be causing issues during the interoperations between WPF and Winforms.
I’ve done a lot of research and searched lot of links for suggestions. I found none pointing out this issue. Some of them were close. Here are a couple of links:
The this suggests to reproduce the message loop under the “Surrogate Windows Forma Message Loop” section.
Here is one more link that explains the issue with nesting under the Nesting section.
I apologize for being verbose. Just wanted you guys to get a clear picture of my problem. Please let me know if you have any questions regarding the post. Any suggestions would be greatly appreciated.
EDIT:
We were able to resolve the issue, but still, it is a work-around. Here is what we did:
There were two ways to resolve this issue, but both were related to using static.
Static Winforms control:
We used the following static Winforms control
public static class ControlHolder
{
public static TextBox ReportFromDateTimeInstance;
}
In the OnChanged event of the "actual" control, we dump the actual control, ReportFromDateTime to the static control, ReportFromDateTimeInstance.
private void ReportFromDateTime_TextChanged(object sender, EventArgs e)
{
ControlHolder.ReportFromDateTimeInstance = (TextBox)sender;
}
And from then on, wherever we update the actual control (as in ResetDateTimeHandler method), we update the static control
private void ResetDateTimeHandler(bool cancelClicked)
{
ControlHolder.ReportFromDateTimeInstance = "Text changed";
}
This shows the updated value on the Front-End
Static EventAggregator
This work-around was provided by one of our colleague.
In this case, we are using our actual control, ReportFromDateTime, rather than the static control, ControlHolder.ReportFromDateTimeInstance
We used a static event aggregator for publishing/subscribing the ResetDateTimeEvent instead of using the Event Aggregator instance provided by Unity Container. So, instead of
eventAggregator.GetEvent<ResetDateTimeEvent>.Publish(true);
we used:
ResetDateTimeEvent.Instance.Publish(true);
And in the subscription:
ResetDateTimeEvent.Instance.Subscribe(ResetDateTimeHandler);
I know that we need not use a static event aggregator in this scenario since we are using the instance provided by Unity Container (which makes sure that a single instance is shared by all the ViewModels), but this also has resolved the issue.
So, I'm still confused on why the above two scenarios are solving the problem. Is it the static-ness that is solving the issue ?
As I was already saying, I feel that the controls are getting re-created, and by the time we have the controls in hand, they have been already re-created.
Any suggestions would greatly be appreciated.
I've done the same thing before in an app that had a WPF control inside of a WinForms control. The WPF used Prism/Unity (later switched to MEF) to start everything up. However, this created a whole new EventAggregator by default in the bootstrapper, so I had override the default IEventAggregator in the container with a static one b/c the WinForm side had already been created and was using its own IEventAggregator instance. The symptom was similar in that published events were not received.
In a mixed system such as yours, singletons are great for ensuring that everything's feeding off of the same reference, especially when your startup is in stages (WinForms then WPF).
Simple answer: yes, use singletons for shared references between WinForms code and WPF code. Those singletons can be fed into the container in the WPF bootstrapper so that injection still occurs in the WPF side, too.
Is it possible to have a window from another 3rd party application shown inside our WPF Window? Preferably in a container control?
I'm guessing there might be some Win32 API that allows us to do that.
I did that some time ago for Winforms, but the method was not to bright, so as long as anyone else doesn't have any idea, here's what I did. The code was pretty much this:
Process p = Process.Start(#"application.exe");
p.WaitForInputIdle();
IntPtr appWin = p.MainWindowHandle;
SetParent(appWin, parent);
SetWindowLong(appWin, GWL_STYLE, WS_VISIBLE);
System.Threading.Thread.Sleep(100);
MoveWindow(appWin, 0, 0, ClientRectangle.Width, ClientRectangle.Height, true);
(where SetParent, SetWindowLong and MoveWindow are the win32 API functions called via p/invoke) The sleep was needed as a hack, because without it the call to MoveWindow would have no effect.
For WPF you will need a handle to a window/control that will be the parrent of your 3rd party window and the easiest way to get such a handle is to use a HwndHost container.
I don't think there is a prettier way to achieve this in WPF. Also, note that I've only tested this in winforms, not in WPF, but it should work also in WPF, as long as it has a valid win32 HWND of the parent.
Why is it that I have to set the WindowStyle property to None on a WPF form to get transparency, but in Winforms I can do it on any form, and retain borders, standard buttons, etc? Clearly the API supports this, so I'm not clear on what's special about WPF that would make this an issue.
I'm guessing that WPF is jumping through some DirectX or OpenGL hoops, while Winforms is just setting the alpha for the window via the API, but I could be way off base.
Agreed, this is heavy handed:
private void VerifyConsistencyWithAllowsTransparency(WindowStyle style)
{
if (AllowsTransparency && style != WindowStyle.None)
{
throw new InvalidOperationException(SR.Get(SRID.MustUseWindowStyleNone));
}
}
WPF uses the exact same mechanism to implement this as Windows Forms, layered windows. There is no obvious reason it wouldn't work the same way in WPF. The code snippet, lifted from Window.cs, simply rules it out. There is however one hint from the UsesPerPixelOpacity property:
When you enable per-pixel opacity, the system no longer draws the non-client area. This is because the intended purpose of UsesPerPixelOpacity is to show non-rectangular top-level UI that works in interoperation scenarios, and showing the rectangular non-client area defeats that purpose.
"interoperation scenarios", I guess.
I'm using the System.Windows.Controls.WebBrowser for various things in my app and I've noticed that adorners are cut off when they are supposed to appear over a WebBrowser. I realize that the WebBrowser control is really a wrapper around a COM component and probably renders differently, but I wondered if anyone figured out how to solve this.
This is the problem I'm seeing. Here I have just a sample adorner that is supposed to draw a big red circle in the top corner of something (as a sample).
When I adorn the WebBrowser with this, I get this result:
I expect to see the full circle.
Here's the code for this worthless adorner, in case that is helpful:
public class SillyAdorner : Adorner
{
public SillyAdorner(UIElement element) : base(element)
{
}
protected override void OnRender(DrawingContext drawingContext)
{
drawingContext.DrawEllipse(new SolidColorBrush(Colors.Red), new Pen(), new Point(7, 7), 30, 30);
base.OnRender(drawingContext);
}
}
And here is how I apply it to the browser in the OnRender method of the host control:
protected override void OnRender(DrawingContext drawingContext)
{
base.OnRender(drawingContext);
var layer = AdornerLayer.GetAdornerLayer(browser);
layer.Add(new SillyAdorner(browser));
}
Anyone have any hacks or workarounds for this?
Edit: I'm using .NET 4.0, if that makes a difference.
Edit #2: WebBrowser appears to inherit from HwndHost, which I've seen another question or two regarding adorners and hwndsources, but I'm not seeing anything that looks like I could implement it for the WebControl, but hopefully this is useful information for someone.
I don't think that will work with an Adroner, but you can float content over a WebBroswer control using a transparent Popup control. More details and a code sample can be found here.
Here's my blog post introducing a library I wrote for layering a WPF adorner over any hwnd. A simple web browser demo looks like this:
This is caused by airspace issues. Since a WebBrowser is a native, non-WPF control, there is no way to directly render adorners (or other WPF content) on top of it.
In order to do this, you need to use a separate window of some sort, and put the content into that separate window. This typically means using a transparent WPF window layered over the top of your main window. Unfortunately, this will not be as integrated of a solution as a true native WPF control would provide.
Try use another transparent TOP LEVEL overlay window. Only supported on Windows 2000 or higher of course, Win9x does not have layered windows.
Im developing some wpf app. Basically i have two types of windows: search windows and insert/edit windows. When i developed win forms apps, i used a trick, called MdiParent. In that way i had ability to put my caled search type windows in a "stack". In orher words if i called 5 different search windows from meniu, they apeared in a component like tab control, one after other.By clicking on that tabs, i could see search results of clicked tab window. The trick as i said was MdiParent technique, like:
private ProductDiscount frmProductDiscount = null;
private void ProductDiscountToolStripMenuItem_Click(object sender, EventArgs e)
{
if ((frmProductDiscount == null) || (!frmProductDiscount.Visible))
{
frmProductDiscount = new ProductDiscount();
frmProductDiscount.MdiParent = this;
frmProductDiscount.Show();
}
else
{
frmProductDiscount.Activate();
}
}
So does anyone can me suggest a good way to implement such a window organization technique in WPF and put some links or examples..?That would be a big help for me.
There is no equivalent of Form.MDIParent in WPF and MDI does not support the idea of an MDI layout. You can set a Windows Owner to another window. This will minimise the child when the parent is minimised.
For an example of MDI style functionality have a look at this thread link text
where Marlon Grech has written something similar to what I believe you are trying to do.
We developped similar application, as WPF doesnt have any default MDI framework but since its completely customizable, what you can do is, you can create User Controls of your "Window" instead of Window type and you can use inside a TabControl and you can customize TabControl to have close buttons etc. Windows in Tabs as they appear in Visual Studio, IE etc, they work good for this type of scenario when you dont want to block user input on modal dialog.