I am working on a WPF panel derivative with custom layout logic and sometimes it might be that component should be visible in two places, when following that layouting logic. Both instances of the same component will be partially cropped. Is it possible to do this - lay out a child component in two different places during the arrange pass?
I think that the panels behaviors are for arrange items in a view, and not for copy the items. I think this is not possible. If you copy a visual element then it will not be the same. If you want get this effect you may use a VisualBrush and paint some region with that, and set to the brush the control that you may want to copy. Using VisualBursh you will see a control copy, but you will not be able to modify it. The other way is using a custom control for making this effect. Other way could be using two different custom panels, both with the same items source (in the case that be the ItemsPanel for some collection).
Hope this answer helps to you...
Related
I'm working on a C# application's UI that has the following structure:
Main Form (MDI Parent)
Tree View
Multiple MDI Childdren, each containing:
Custom User Control
I'd like to separate the form's canvas space allocated for the Tree View from that where the MDI Children are allowed to move in. To that extent, I tried a SplitContainer and setting the MDI Child's TopLevel field to 'false', but, besides the fact that newly created MDI Children were created behind the old ones, I also had issues with them not being cleared properly from the screen and other weird issues.
As I don't have lots of experience with UIs in C#, is the path I am taking correct? Would it be easier to change the above structure so that it doesn't use MDI anymore, or is there a simpler way of dividing the canvas between the tree view and the MDIs, other than the SplitContainer?
Cheers,
Alex
UPDATE: Actually, the solution seems to work quite nicely, thanks! I'll probably be able to stop the widgets from moving in the wrong place by placing a simple check.
Besides that, is there any way in which I could make the TreeView resizable without involving a SplitContainer (because of the reasons mentioned in the post)?
Add a Panel to your Main Form and Dock it to the Left. Now add your TreeView to the Panel. Resize the Panel as necessary. Now your MdiChildren will take up the empty space to the right of the Panel...
*You can actually simply Dock the TreeView itself to the Left side of the Form, but the Panel approach would allow you to place other controls in that left side area as well. Just depends on your UI layout.
So much reading, and so much about inheritance, I can't find any direct answers, so here goes.
If you have a base-class derived to do certain things, look or act a certain way, you can subclass it and get all the functionality of the parent class with only slightly modified differential. The same does not appear to be the same for working with WPF Themes... more specifically, the combobox control (similar issues with textbox, but that's obviously less complex).
By looking at the Control Template Examples, they discuss the entire structure of it, the borders, backgrounds, glyphs, actions, properties, etc.
If the ONLY thing I want to do with a combobox is to change the border of it to Red if there is an error in it, it appears, I have to basically redefine the entire thing and somehow put in my custom trigger setting / color to be implemented.
Somewhat similar is that of the textbox control and how its created. It has the named control when trying to nuts around with the background color... you can't just say... background = some static brush value.
What shortcuts are out there to only allow overriding these small elements without having to re-create the entire template control. I can just imagine what would go on with grids, tabbed controls, and others that could get extremely messed up if you miss one simple thing.
I also see that some controls are made up of OTHER Control.Templates, so how might I be able to attach to changing the property setting on just the single element of the control template... Such as the combobox has the control template for the Toggle Button. From that, it has a border via x:Name="Border" and I want to change THAT element within a derived style.
Thanks
I might not understand your question here. But from what i get is:
Yes you can't partially implement Templates, in fact i wouldn't know how this could be possible. But, if you want to change certain things, you can of course do that. You can create Styles, Templates, Brushes etc. as DependencyProperties and use TemplateBinding to bind to them, on the given child control.
Remember that WPF allows always to change the template on the fly. if we could partially change the template this would might hurt performance or could get messy and complicated. Still, you can do that using ContentControls and TemplateBinding or simply Triggers.
For my custom controls, which might contain multiple part sub controls, i usually add a style for them. For example, a custom ComboBox would contain a ToggleButtonStyle.
One thing that would be nice though, would be to add control template triggers without the need to reimplement the template.
I want to make a custom Panel to (amongst other things) insert spacing between all children. To inherit from Panel seemed very complicated and perhaps unnecessary. What I want is close to StackPanel so I figured I could inherit from StackPanel and modify the ArrangeOverride and MeasureOverride to get what I want.
I got the implementation of these from Reflector but immediately noticed that one property was not accessible at all from a inherited class, namely IsScrolling (and the field _scrollData). My question is if I can skip this or if there is any other way of implementing identical behaviour? Im not sure I will need scrolling for this custom panel but I may do some day and I dont want to paint myself into a corner...
if all you want is just that all elements inside a container would automatically contain margin definitions, you're much better off just creating a custom behavior that implements that functionality.
to create a custom behavior, just implement Behavior<Panel>. It's rather self-explanatory, but if you don't know how then ask.
So I'm just starting out with WPF, and I'm really annoyed by the fact that if I lay two Grids on top of one another, the top Grid isn't opaque. It makes designing extremely annoying. Can this be turned off somehow?
I'm just building your standard Winforms STYLE application, but in WPF. I'm just trying to start bridging the gap here. In Winforms(and VB) you'd always have group boxes or something on your form, and then depending on some user context, one of those group boxes would be on top. Its how I've designed forms since time immemorial. One of two things must be true here:
A) This is not the recommended way to design Windows going forward with WPF, but I don't understand what you're supposed to do
B) There is some property to make the Grids opaque so I can build the Window in the style that I'm used to.
I'm fine with answers that solve either A or B. If I'm not doing things the right way because they've changed, then please enlighten me.
Update: So it turns out, I can make the grid opque by setting the background color, but now it seems like I'm locked into a White background as opposed to sticking with the system colors.
You could use SystemColors to make the control background colour match (rather than being white).
I don't understand why you want to put one grid on top of another though. In WPF you generally use a single grid to stack multiple visual elements within one region. Can you explain why you want to hide things in the background with foreground elements?
It sounds a little like you're implementing a tab control -- switching between pages of controls depending on focus. Have you experimented with the new TabControl?
I'm moving from WinForms to WPF development wherever possible and have found that in doing so it's taken some readjustment. WPF has a completely different way of laying things out and now that I'm more comfortable with it, I think it's superior. I'm guessing you just need to ride the learning curve a little longer.
Hope that helps.
EDIT: In response to your comment, I imagine you can have a tab control without tabs, though I haven't tried it myself (might be worthy of another question on SO). Tab controls are headered controls, meaning that they have a header item and a content item. In this case, the header is the tab button, the content is the page item. You can specify a ControlTemplate that details how these items should be displayed relative to one another.
Interestingly, many other types of common GUI element are also headered controls:
Menu items - The menu item text/icon is the header, and the optional submenu is the content
Tree view - Each node is the header, and optional children are within the content
Group box - The header is, well, the header and the content is, well, the content :)
Note that in the case of menu items and tree views, the type may recursively nest within itself. This is quite elegant and can give some wildly different presentation options over the same logical model with only changes to the control template.
For more information read about HeaderedContentControl and HeaderedItemsControl
You could use the following:
<Grid Background="{DynamicResource {x:Static SystemColors.WindowBrush}}">
<!-- content -->
</Grid>
This will respond to changes in the system colors on the fly (the DynamicResource does this).
I have two different ways of displaying items in a WPF application. The first uses a WrapPanel and the second a vertical StackPanel. I can switch between the two ways of displaying my items by switching the host panel between the two types. This does work but you get an instance change in layout.
Instead I want the child items to animate between the two layouts to give a nice smooth effect to the user. Any ideas how I could go about achieving that? Do I need to a Canvas instead and work out the positioning of children manually? That would be a real pain!
Have a look at the SwitchPanel from IdentityMine's Blendables Layout and also read Dr WPF's article on CodeProject about Conceptual Children
I have posted another solution on codeproject that is free and ready to use WPF Layout to Layout transitions