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.
Related
I have an application that should work a bit like a message board: text gets parsed, hyperlinks are made "live" and displayed. Only it's in Silverlight. Because of that, I can't use TextBlock like they do here WPF - Making hyperlinks clickable, somehow it's different in Silverlight and it's not possible to do a Hyperlink with a Run inside it.
I've tried the RichTextBlock, as it says here Wrapping Text and Hyperlinks in Silverlight, but couldn't for the life of me figure out how to create the paragraphs and hyperlinks from code, since I need to populate it dynamically.
Then I thought I'd settle for a less elegant solution involving TextBlocks and HyperlinkButtons in a WrapPanel. I added a namespace reference, like it says here WrapPanel in Silverlight 4 toolkit, but when I reference it in XAML, there's no WrapPanel in it, only DataField, DataForm and VisualStateManager.
This Text areas and hyperlinks? doesn't work either, the Silverlight RichTextBox is different and LinkLabel is missing.
Maybe there's another solution that I don't know? I'm keeping an open mind. Any help appreciated.
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;
}
I've got Expression Blend 4 installed on my machine. I just need to know what I'm doing.
My application will be running on a laptop equipped with a touch screen, in police cars where the user will probably be driving the car. Needless to say, the interface has to be easy to use. In this case, that means things like the drop down buttons on ComboBox controls and scroll bars need to be wider than normal so they're easy for the driver to use.
Can someone tell me what part I have to change for each of these controls in order to get the effect I want? I tried editing a copy of the template for one of the combobox controls in one of my user controls and playing with the ToggleButton control but that didn't do what I wanted it to do. There's so much mark-up in the template it's hard to tell what's doing what.
Thanks for any help you can give.
Tony
Edit:
I figured it out from the first answer to this previous StackOverflow post. I had to make a copy of the ComboBox's style, then make a copy of the ToggleButton's style.
Thanks anyway.
Tony
The solution was to edit the application in Expression blend. I clicked on one of the ComboBoxes and right clicked. From the context menu, I selected Edit Template | Edit a copy. In the dialog box that appears, I specified that the new template should be applied to all ComboBoxes in the application.
Within the ComboBox's style, there's a ToggleButton. I repeated the above steps with the Togglebutton. Finally, I changed the width to make it what I wanted. There's also a path in there for the arrow that you can play with if you like.
Tony
I'm creating a User Control that's basically a Panel (with random content inside), and I need to be able to scroll up and down this Panel using buttons (up and down) rather than the scrollbar.
The reason I have to do it this way is because the program will be used on a touch screen monitor and we need big buttons rather than an ugly little scrollbar.
I've been messing around with the VerticalScrollbar properties, and none of them seem to do anything. I've noticed that if I set AutoScroll to false, AutoScrollPosition actually shows coordinates, except negative of what it should be. Also, I've noticed that panel.VerticalScrollbar.Visible = true; only seems to work when placed outside of the constructor. Is there a reason for that?
Basically, WinForms' scrollbars are very confusing (buggy?) to me. Does anyone know a good way to scroll up and down a panel programmatically with buttons (I don't care if I need to have an invisible scrollbar).
Thank you! =D
Make your UserControl a regular UserControl (i.e inherit from UserControl instead of Panel) and place a Panel on your UserControl. Put any content/controls on the inner Panel, and then change the Panel's Left and Top properties to move it around without scrollbars. You could also add buttons to your UserControl to handle the movement of the inner Panel.
A simpler way, however, might be to just use really wide/high scrollbars, and set their Thumbwidth (I think this is the property) to the same large value - this will produce scrollbars that are easy to use with the fingers. To my knowledge there's no way to do this with the scrollbars that appear on a Panel with Autoscroll set to True, so you'd still need to use the method I mentioned above (with an inner Panel sitting on your UserControl) and add the scrollbars to move it yourself.
I agree that scrollbars in Windows suck, so while I'm normally in favor of just using the standard controls that everyone is used to, I don't see anything wrong with rolling your own in this case.
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.