What I want to create is a list view that will resize itself in order to show all items. Normally I would use AutoSize, but this won't work here. Any other options how can I make ListView expand and shrink to fit all?
You will have to manually calculate your desired height and set it as items are added/removed.
Detecting item addition or removal isn't directly supported - so you'll either need to create your own Add/Remove Item calls for clients to call, or handle LVN_INSERTIEM type messages from WndProc.
Auto-sizing controls are usually trickier to use - as you have to track Min/Max sizes, allow room on the owner, and usually add to an awkward usability point for users. Only do something like this if typical solutions (i.e. scroll bars) truly can't work for your need.
"AutoSize" property is not supported for the "ListView" control. As #JohnArien mentioned, you will have to programmatically re-size your list view control's size according to the number of items available. But be warned that this may not be a good idea in terms of visual appeal of the Form. Your form design might look ugly if you change the size in run time. More over these types of controls are expected to expand their client area within the given size with the help of scroll bars. I would strongly suggest you to reconsider this option.
Related
I am attempting to insert a panel into my WPF application that would have a few very specific behaviours:
1.) Wraps content evenly. Starting from the top left corner and running downward, before moving to the next column.
2.) Allows me to define a maximum number of columns to wrap to. For my purposes, this number would be between 1 and 3.
3.) Allows me to set an initial height, but it will also grow to accommodate additional items. (Only setting an initial height because my content won't wrap without it. If I leave it auto, it all comes out in a single column regardless of whether it fits on screen or not)
At this point, I have concluded that what I'm attempting do will require a custom panel, but I'd like to ensure before I begin that process (and learning how to do so) that I'm not missing a much simpler answer.
A WrapPanel can be set to wrap vertically, but you have no control over the number of columns.
A UniformGrid would offer you control over the number of columns, but wraps horizontally not vertically.
In short: you need a custom panel. The built-in ones do not offer the combination of features that you want.
UniformGrid has a LayoutTransform property, which can be used to transform it in order to change the position/rotation of the elements inside. But it will also transform the content.
Some more tricks involving Setters on the types of the items inside your UniformGrid and the content can be transformed again to retain the desired "original" orientation.
You can learn more in this tutorial.
Alternatively, it seems that the Extended WPF Toolkit contains its own implementation of UniformGrid, with an Orientation property, the only problem being that it won't grow to accomodate the number of items; instead, it will obey to an arbitrary Columns property.
Then again, you may be able to change the value of this property each time you add a new item/resize your UniformGrid, but it will be some more manual work and may potentially lead to code behind, which could be seen as an issue if you're working in MVVM.
I need to move controls around when the scrollbar's size change (System.Windows.Forms.SystemInformation.VerticalScrollBarWidth).
I'm creating a control with custom scrollbars that go over the normal ones. This implies creating a new UserControl (not inheriting a built-in control) and playing around with panels so as to hide the normal scrollbars.
The custom control must have one "outer" panel at the right size, this one containing an "inner" panel larger than the outer panel, so the scrollbars do not appear. How much larger depends on System.Windows.Forms.SystemInformation.VerticalScrollBarWidth and HorizontalScrollBarHeight as was already answered. But then I must know if that changes when my app is running, as improbable as it seems.
This question is related to:
How do I know the current width of system scrollbar?
I'm currently trying to achieve something similar.
I'm running Windows XP SP3, "Classic" style, and upon changing just the scrollbar width of the current design, my override of OnSystemColorsChanged() (in a class derived from Control) gets called four times.
Why it's four times I don't really know, I suspected it might be because there's four properties in there that seem to depend on that setting:
SystemInformation.HorizontalScrollBarArrowWidth
SystemInformation.HorizontalScrollBarHeight
SystemInformation.VerticalScrollBarArrowHeight
SystemInformation.VerticalScrollBarWidth
But all of these already hold the new value at time of the first call. So I'm not 100% sure what's going on here. But it looks like OnSystemColourChanged() should rather be called OnSystemInformationChanged().
Hope this helps ...
One must listen to Microsoft.Win32.SystemEvents.UserPreferenceChanged.
As takrl mentioned, OnSystemColorsChanged gets called, but only once for me (Windows7, Framework 3.5)
As my first WPF project, I am attempting to build an application to play a card game similar to Magic the Gathering. It is not clear to me how to lay out the main play area. You can see some examples that are similar to what I am attempting by looking at example 1 or example 2. The chat/info areas on the right would be separate user controls.
The cards must maintain their aspect ratios, and each play area would start with 10 columns and two rows of cards. As more cards are played, the number of columns and/or rows may change. Each player area may have a different number of columns and/or rows. Cards may overlap, and may be placed sideways (tapped). Cards in all areas should be the same size (although they may be cropped in some areas). Cards do not need to lie exactly on the grid (they do not necessarily snap-to-grid).
When the user hovers the mouse over a card, it should expand to a significantly larger size using an animation. A card in one player area may overflow into the other player's area when expanded (but only as long as the mouse hovers).
Given these requirements, I am tempted to use one large user control derived from Canvas with image objects for each card (along with other shapes to delineate the areas). This implies that I will be doing a lot of work during the OnRenderSizeChanged event to position the child items within the canvas (manual layout).
Using a grid does not seem feasible to me, due to the free-form placement and overlap.
Decomposing the play area into smaller user controls would leverage the WPF layout capabilities, but it seems like decomposition would prevent the cards from expanding into adjacent user controls during the mouse-over, so that doesn't seem feasible either.
Is there a better alternative to one large canvas-based control? It seems wrong to be doing manual layout in WPF, but I cannot see an alternative.
This sounds like a great scenario for Composite Application ala Prism. It provides solid framework for implementing regions, modules, sending message between modules etc... From looking at your screen captures, developing a shell with different regions and dropping modules into them would probably greatly benefit your layout. As for the cards themselves, perhaps they could be modules as well?
Check out:
http://msdn.microsoft.com/en-us/library/ff649780.aspx
Particualy good examples come with the download package including a stock market like application and event aggregator example.
You said:
Decomposing the play area into smaller user controls would leverage the WPF layout capabilities, but it seems like decomposition would prevent the cards from expanding into adjacent user controls during the mouse-over, so that doesn't seem feasible either.
But this is not correct. Decomposition is absolutely the right approach to take, and this would not prevent the cards from expanding into adjacent user controls. The reason being that you can use a RenderTransform rather than a LayoutTransform. See this example, by Charles Petzold, or this article, to visualize the difference. Because a RenderTransform is applied after the layout has already occurred, your cards would be able to expand outside their bounds.
Given that decomposition is the right approach, I would arrange your various card collections into a Grid, with each collection being an ItemsControl. The ItemsControl should bind its ItemsSource property to some collection, and then you can provide a custom ItemTemplate that would display the image and any other information. I would be hesitant to use a Canvas, as this would restrict you to hard-coding the positions for the cards (which is a very WinForms-like solution for a problem that can be far more elegantly solved). Take advantage of WPF's fantastic layout engine and use nested grids and items controls to create a dynamic layout. This will ensure that your game board looks good at any resolution and when stretched to various sizes.
I recommend you take a look at this guys project . In java I know but if I was to go the route of building a card game. That would be what I would go off of.
A lot of canvases inside of a grid could help you here, the canvas will allow the content to render outside of its bounds, as long as you turn ClipToBounds to false, and you will be given much more control over exact placement of the cards than with other schemes. You will also get the powerful functionality of a grid control, allowing you to add and remove columns and rows as needed (though you will also have to dynamically add and remove canvasses, though this isn't too difficult.
If you're worried about the contents of your "Card" moving around when the box is rescaled, surround it in a viewbox. It will manage all your scaling for you, and ensures your card uses as much real estate as it can get. Alternatively you could use a RenderTransform, but a lot of these might slow your program down (Experts: does the viewbox operate using RenderTransforms? If so this point is moot)
To ensure the cards maintain their aspect ratios make sure each Image's Stretch attribute is set to "Uniform", making them all keep the same size could be done by designating a master card, and binding heights and widths of all subsequent cards to this original card, though that is a little messy and doesn't allow the cards to expand. Another solution is to set a single size for each card manually, animating this when you want to expand or shrink.
I need to build a WPF control that looks somehow similar to this:
alt text http://img251.imageshack.us/img251/6857/circle.png
Where each color should be clickable and resizable (or selectable).
This control will be used to set modes on the hours of a day.
I've thought about making 24 buttons that would be arranged in a circle:
alt text http://img684.imageshack.us/img684/2184/buttonsk.png
Another idea was to draw a complete circle and calculate user mouse click's position for the selection and draw several circles to represent the data.
Any other/better ideas on how to build this?
(please excuse my poor drawing).
I think you would get odd edge-effects with multiple overlapping or touching controls. So I would make a single custom control to do this. It would convert the mouse position on button down to a slice, and then do the appropriate action.
With a single control, you could also come up with a rational way of dealing with keyboard input and for showing selection and allowing for multi-select behavior.
It sounds like you want a customized ListBox (multiple items that are selectable/clickable). For the layout you would want to use some type of RadialPanel as the ItemsPanel. You probably also need to change the ItemContainerStyle to make your ListBoxItems look like what you have above, probably with some triggers to change colors based on selection state. Depending on what behavior you need from your items you may need to create custom ListBox/ListBoxItem derived custom controls but in a lot of cases the built-in behavior will get you a long way. To reuse it as a single unit you could wrap up the ListBox with its 24 hour items and customized templates in a UserControl and expose the selection data in whatever form you need as a Dependency Property (like an IEnumerable of the data items representing the selected hours).
Does that help you get started?
I'm trying to use the windows native (Theme-aware) header control to display just some column headers. The main purpose is to avoid manually drawing the column headers and rely on the natively supported functionality.
So the 2 options I was thinking of are:
Use a HeaderControl, and add columns to it (I can't seem to find a header control supported by WinForms).
Use a ListView control, and tell it display no rows (or basically set its height to the height of the column header) - can't find any way to determine which height should I assign to the control.
Any good ideas much appreciated!
There is no HeaderControl for WinForms in the .NET framework so far (the ListView utilises the ColumnHeader class but this is only useful with the ListView). If you are only targetting Microsoft Windows, you could look at wrapping the Win32 control for use in .NET although I expect that will be substantial work.
Your second option is a valid possibility even though it feels somewhat clunky. I can see difficulties arising in getting the list to size properly such that the header and only the header is visible.
A third option would be to roll your own HeaderButton that represents one column (like ColumnHeader) and use the theme drawing calls to draw it, then just combine them in a FlowLayoutPanel or TableLayoutPanel into your header bar. If you want resizing, you could make the HeaderButton have a grab region that you can pick up and alter its width.
I think the third option will be reasonably simple to create, even with the sizing ability, so I would recommend taking that route (I might even give it a go myself when I get home tonight).