I have several composite UserControls, consisting of mostly labels and TextBoxes, and use the Control.DrawToBitmap to print the current UI. This works fine except for one composite UserControl. Its bitmap only contains a couple of controls within the UserControl. The Visible property of all controls is set to True. The documentation for DrawToBitmap states, "Controls inside containers are rendered in reverse order." I'm not entirely sure what this means but some controls are within panels, so I'm thinking this might have something to do with it. In any case, I've tried different orderings for the panels and the control within the panels, but nothing seems to help. Any ideas?
Figured it out. If e.g. two panels overlap but are not nested, then the controls in the panel that's behind the other panel will not be copied onto the bitmap. Changing the order (by bring to front) doesn't seem to have any effect.
Related
I have a WPF/XAML form that has controls on the page and also controls inside a tab control.
I was hoping that by setting the tabindex values appropriately, the user could just tab from the controls outside of the tab control to the controls inside the first tab item, but it seems that the items inside tab control are skipped when tabbing around the form.
Is there a way to have the tabbing go into the tabitem/tab control?
WPF provides a number of ways to affect the tab order in an application. Probably the most important is also strangely the least known. I'm talking about the KeyboardNavigation class and in particular, the KeyboardNavigation.TabNavigation Attached Property. From the linked page on MSDN, this property Gets or sets the logical tab navigation behavior for the children of the element that this property is set on.
There are several possible values in the KeyboardNavigationMode Enumeration used that affect the tabbing order in different ways. Take a look at the last linked page to see which one suits your situation best, but as an example, the Local value has the effect that Tab Indexes are considered on local subtree only inside this container and ... [Navigation leaves the containing element when an edge is reached].
<Grid KeyboardNavigation.TabNavigation="Local">
...
</Grid>
This is a problem I've often faced and it's a tricky one. From my understanding, the reason that it doesn't work as you'd expect is because tab order (even specified via TabIndex) is contextual. TabIndex of higher level items will be prioritized over inner elements. So if you have two TabItems inside of a TabControl, and each one has UIElements inside of them, even if the TabIndex is specified, tabbing will first traverse the TabItems before it moves down to the contents of those controls. I "think", IIRC" this has to do with how the page is composed, but don't quote me on that. MS has weird reasons for some of these subtle nuances.
Onto the solution. What I've done in the past (so long as you're NOT working on WinRT, which makes this problem even worse) you can use UIElement.Focus. I store a list of UIElements in the order I wish them to be when tabbed in the code. Then, by binding the KeyDown event to a common handler for all of these controls, I do something like this:
int currentIndex = TabbableControls.IndexOf(sender);
UIElement next = TabbableControls[(currentIndex + 1) % TabbableControls.Length];
next.Focus();
Hope this helps!
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...
I've written a WPF control which accepts a number of UIElement objects as input and displays them docked either vertically or horizontally. The control exposes functions for enumerating, removing and inserting children, but internally I'm using a Grid to build the layout, creating a row/column for each item and inserting a GridSplitter between them. To do this I've inherited from ContentControl, and upon initialization I just set the Content property with the Grid. Everything is working as intended, but now I wonder if this might be confusing for the user of my control, as it would be counter-intuitive to have a ContentControl that has many items.
Should I be inheriting from ItemsControl instead?
Should I inherit directly from Control which is "content-agnostic"?
Is there a better way to do this?
Thanks in advance.
What you describe sounds like a Panel - basically a control which is responsible for the layout of many elements. I would consider inheriting from that.
Your mention of "docked either vertically or horizontally" leads me to believe perhaps a StackPanel would be a better fit, since it does docking as well.
I have a ListBox that contains a number of User items that are DataTemplated to appear as UserControls in the ListBox. Each UserControl can be expanded in size. To start with, the ListBox is big enough to display them all in their unexpanded state. The problem that I have is that when a number of these UserControls are expanded together, they extend out of the ListBox's visible area. The ListBox does not recognise this fact and no ScrollBars appear, even when they are set to Visible.
I am using DoubleAnimations to alter the UserControl heights when the user clicks on a button in each one. Is there something that I have to do, or some setting on the ListBox that must be set to get it to register the size changes of the UserControls that represent its items and display ScrollBars when needed?
Edit>>>
I have tracked down the problem to a custom WrapPanel that I am using in the ListBox.ItemsPanel. When I remove it, or replace it with a standard WrapPanel, ScrollBars appear when required. I got the code for the Panel from a good article about creating custom WPF panels. Can anyone see what's missing from the code given in the article and why it might stop the ScrollBars from displaying?
I wonder whether ListBoxes normally do what you are expecting? You might try calling InvalidateMeasure/Layout on the ListBox if you know when the item sizes change, just to see?
I decided to write the custom WrapPanel code again completely and this time it worked correctly! When comparing the new version with the previous version, I could see that a + was missing from a += in a measuring calculation and so the Panel thought that the items were much smaller than they really were... hence no ScrollBars.
So, if you have this problem, check your measuring code carefully.
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).