how to set the z-index windowsformhost that they are not always at the top of the WPF element ?
According to MSDN (Layout Considerations for the WindowsFormsHost Element)
A hosted Windows Forms control is drawn in a separate HWND, so it is
always drawn on top of WPF elements.
This is a design limitation
Another good article from MSDN that explains possible issues when using different graphical technologies in Windows is Technology Regions Overview
However googling I found that there seem to be some hackings for this (known as airspace restriction)
One hack (never tried it personally so not sure if it works) is at
this link
I've just encountered the same problem.
There is a potential workaround - depending upon the nature of the Windows Host window control and the WPF element you want to appear:
I bound the the WindowsFormsHost control's Visibility to a property on my view model to enable me to hide the host (and the controls on it) when I want to display the WPF that we want to appear over it.
Update, a few years later (2016-09):
My following answer, as noted by the top comment, is no longer valid, and was not available in the final version of .NET 4.5, or subsequent releases. Unfortunately, the link I included still has z-ordering information for HwndHosts present for the "current version" of .NET, which could lead some to believe this functionality does, in fact, exist. It doesn't. There is no work-around.
Original answer:
A year later, things have changed a bit with .NET 4.5. For those who stumbled upon this, much as I did, here is a more updated excerpt from Walkthrough: Arranging Windows Forms Controls in WPF on MSDN:
By default, visible WindowsFormsHost elements are always drawn on top of other WPF elements, and they are unaffected by z-order. To enable z-ordering, set the IsRedirected property of the WindowsFormsHost to true and the CompositionMode property to Full or OutputOnly.
All you need to do, when using .NET 4.5, is add the following attributes to your WindowsFormsHost element IsRedirected="True" and CompositionMode="Full" or CompositionMode="OutputOnly".
In my situation my WindowsFormsHost is in a two row Grid. The bottom row has a StackPanel in it that changes Height depending on what it contains. I handle that StackPanel's LayoutUpdated event to resize my WindowsFormsHost by subtracting it's ActualHeight from the Grid's ActualHeight. Be sure to use ActualHeight not Height.
void ResizeWinhost()
{
mainGrid.UpdateLayout();
detailPanel.UpdateLayout();
winHost.Height = mainGrid.ActualHeight - detailPanel.ActualHeight - 5;
}
Related
I have UserControl which is hoseted in ElementHost.
It contains DataGrid
When user presses enter or double clicks the row new window is shown (modalless), and when that window is closed window with ElementHost is activated back. The problem is that DataGrid loses focus.
Snoop showed me that visual tree has the following structure:
AdornerDecorator -> AvalonAdapter -> My UserControl.
Snoop shows that after activation AdornerDecorator has properties
IsFocusable = false
IsFocused = false
IsKeyboardFocused = true
IsKeyboardFocusWithin = true
What is an absolute nonsense to me.
When user hits Tab or arrow keys the first enabled UserControl's element receives focus.
I've read this post and I'm not happy with it:
Focus works differently for WPF and Windows Forms, and there were some
rough edges around here that we were unable to fix. If you have focus
inside a WindowsFormsHost and either minimize/restore the form or show
a modal dialog, the focus inside the WindowsFormsHost may be lost –
the WindowsFormsHost still has focus, but the control inside it may
not.
Now what? Relax and be happy?
And the very disapointing is inability to reproduce the problem in other applications.
Can anyone explain what are the reasons of such a strange behavior?
May be offer some workaround.
It is a known bug: http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/7d41218e-c2bb-4957-b0b4-aa24efc4d8c2/
So far the official word from Microsoft is the issue I've described
above is an acknowledged bug but will not be fixed for .NET 3.5. Also
this issue won't be fixed in the next version the .NET Framework (.NET
4.0).
(by kainhart)
But unfortunately the reference to connect is dead.
To workaround this bug I had to add IsVmFocused property to my ViewModel and also create my FocusHelper.IsFocused attached property which listens for element's IsFocused property change and bound VM's property.
You can see the xaml in this (task related) SO question: What is a Cached acessor in the context of DataBinding?
I need a control where user can pick only one option. Combobox is fine, radiobuttons are ok, but for some purpose I think about another crazy, but interesting solution.
There should be a slider control on a window and three possible positions of this sliding thing. I know this can be easily accomplished by setting slider's Minimum and Maximum plus TickFrequency and IsSnapToTickEnabled properties.
Now, is there a way how to add labels on left/right edge and center of slider showing user options within the slider? Or is it neccessary place labels/textblock below?
Last, though the most important thing is, how to associate integer slider positions with string options? I thought about switch, but this is wpf - there is "more wpf" solution, isn't it?
Just drag slider's rider to it's position and by binding set class string property to appropriate value.
Every control within WPF can have its visuals completely modified to suit your needs. This was/is the beauty of WPF over WinForms.
Can your slider have a TextBlock within it? Absolutely. Style as you desire and be on your way. A great article can be found via MSDN Magazine which outlines the approach to customizing WPF controls.
With regard to the integer values, use an IVauleConverter to translate the values to whatever you prefer.
this question is only for those who use the MDI from Codeplex.
I successfully implemented the mdi container and can add or remove child elements dinamically through my code.
My problem is that some of my custom controls (like UserControl) contain a few other controls (ex: TextBox, Buttons, ComboBox, etc), and every control works normally, EXCEPT for the RichTextBox!!!
The issue is that every time I input text in runtime mode, after each char input it automatically goes to another line.
Before you say that may be the way my custom control is built, be assured... it's not. I passed the control containing the richtextbox to another window and it worked normally.
Anyone has the same problem?? Or solution?? I know the codeplex version is still not fully finished but I'm hoping I'm the one doing something wrong...
Thanks
Found the issue. My RichTextBox Width Property was set to AUTO and for some reason (that is completely oblivious to me), it was what was causing the problem.
The solution is to give it a physical (a number rather than AUTO) value to it's Width property.
In my case, since my control has a TextBox just above the RichTextBox and they're supossed to be the same width, I've set my RichTextBox.Width = TextBox.ActualWidth. Note that I used ActualWidth and not width since the width property in my TextBox is also Auto, but the value returned by ActualWidth is a number.
Hope it helps someone :-)
I wanna do Docking control at run time, and set a splitter between the docked control and the others exactly like Visual Studio. I don't know what is the best option, I'm thinking about: changing it's grid row the control where (when dock the control to bottom change the control to the bottom row of the main grid), I tried to change the control's row from 0 to 1, the control then disappeared??!!
Any Help???
Thanks
In the silverlight toolkit you have a DockPanel that works kinda like "Forms". But everything is Xaml though :).
http://silverlight.codeplex.com/releases/view/43528
If you are new to Silverlight it may be a little difficult to understand the Grid control at first (I went through that myself), but it is really powerfull and flexible. Take the time to clearly understand all its features. I personnally never use the DockPanel.
When I drag a control from the toolbox on to the Visual Studio 2008 WPF design surface, it sets a margin based on where I dropped it and a default size.
Is there any way to prevent VS setting those? When I drop a control on a stackpanel I want it to flow in to the existing controls in the panel.
Thanks!
I've never found a way to prevent this. I just type the XAML instead.
EDIT:
I wrote the above nearly three years ago. In the meantime, it would appear that the design-time experience has gotten a lot better.
While the designer still adds hard-coded margins if you drag-and-drop, there are ways to remove those margins without having to do it by hand.
Here's a link to an article that illustrates how to use design tools in Visual Studio 2010 to lay out a form without having to type any XAML. (Despite the title, it's about WPF.)
The first part of the article shows hard-coded pixels, but I've linked to the second part that shows how to lay out the controls without that hard coding.
Layout Techniques for Windows Form Developers
When I drop a control into a stackpanel, it doesn't add margins, it "flows" in with the rest.
The controls you drop onto the design surface have a margin by default because that's how it knows where it's placed. What I typically do is create a grid and set it's margin where I want it, then create columns and rows to put controls into. I drop in my other controls which will add margins which are usually not what I want. After I have all my controls into my grid, reasonably placed, I switch to XAML view and either remove the margin completely (which causes a control like a button to fill the entire space), or make the margin something like 5, which puts some nice padding around the control.
Bottom line...and this is especially true with Silverlight development, you must get used to manipulating the XAML directly. It's the only way you'll get the layout exactly where you want it. This is my opinion and most everybody in my shop who does WPF/silverlight development.
Unfortunately there does not appear to be a means to do this.
The default size is set as a result of you manipulating the size of your control is the designer. When you increase the width and/or height of a control the designer is interpreting your actions as a request to make the control that specified width and/or height.
A similar situation is encountered with the margins. As you alter the position of your control within the designer, it modifies properties to achieve the layout you've created. In the case of most containers the simplest solution is to modify margins in order to achieve the desired position, as you've already pointed out the simples solution is not always the most desired.
Personally I prefer to only use the XAML editor and only occasionally take a peak at the WPF Designer when I want to see the current layout. I also tend to favor using the Grid to layout most of my windows/controls as it provides the greatest flexibility not only for sizing and positioning, but for other tasks/features such as animations, transforms, etc.