I am making a game where I move images around. I have two big images which should have smaller images on top of them. I often move the smaller images from one of the bigger images onto the other. However I recently added a feature where the big image gets changed up mid-game. This caused it to have priority over the smaller images, and when I move the small images, they end up being moved behind the big images.
In short, I always want the big images to be in the background and the small ones to be in the foreground. Is there a property I can set on those to make this happen?
If you have more than one user interface element in a particular grid cell, the elements are layered on top of each other. Elements added earlier in XAML appear below (lower layer) than elements added later.
You can change the layering of the elements by changing the order in which they are added to the Grid. You can also control the layering by giving each element a value for Panel.ZIndex. Elements with higher values for ZIndex will appear to be on top of elements with lower values, regardless of the order in which they were added to the Grid.
Source:
http://wpf.2000things.com/tag/zindex/
MSDN page on the ZIndex property:
http://msdn.microsoft.com/en-us/library/system.windows.controls.panel.zindex%28v=vs.110%29.aspx
Related
I hope make text that always visible in screen, see my gif
I hope text in FloatingTextCanvs visible but it's covered by button, I find the later create ui object will cover previous objects, can i change text object's index to make text always visible?
To display one canvas in front of the other, you want to change the Sort Order property on the Canvas component to be higher than the other canvas.
If you are dealing with two separate canvases then you can set their sort order to determine which one appears on top.
If you are dealing with two UI elements that are children of the same canvas, then their physical arrangement within the hierarchy determines which one appears on top. The child at the top of the hierarchy will appear underneath the other elements. For example, in the following MainMenuCanvas, the Background image will appear behind the Text.
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.
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 them to be ordered neatly and be able to use animations on each image.
The animation will be a simple "grow" effect to symbolize that the image has been selected. So when a user clicks the image, that Image will grow a bit.
So, a grid? A stack? I'm a bit confused.
A WrapPanel might be one possible choice. This will avoid you having to pre-determine the number of columns of images, making that flexible depending on available width.
When an image is selected, you could simply modify its RenderTransform temporarily to increase the scale factor, which will make it grow a bit without affecting the other images around it.
I've searched around for an alternative way of drawing selection indicators for visual objects (like selected edges, lines etc.) without the use of ControlPaint.DrawReversibleFrame and related XOR methods. The reasons are unwanted XOR-ing "artifacts", reversibility not applying to bitmaps, no control of the actual visual look and slowness.
On the other hand I want to avoid having to repaint the whole scene (map actually) if a user decides he wants to deselect an object or two, because the repaint could be quite expensive.
So the only alternative I can see is implementing some basic drawing logic directly on a Bitmap, but with storing the previous contents of the pixels before they change. Then (in theory) I would be able to reapply old contents of, say, an selected edge rectangle if the user chooses to deselect that edge.
My question is whether you think this is a good idea or do you see some other alternatives to my problem (within the GDI+)?
Thanks in advance
If the selection indicator is just drawn on the top of the unselected object, you can use two bitmaps, draw all the unselected objects on the background one and the selection indicators on the other, and paint them both on screen.
Else, you can do the same, except that you render the selected objects instead of just indicators.
Only store the rectangles "of interest" in an off screen buffer. And repaint when the focus is lost. . . Or if you can redraw just the portion as it appears normally based on in memory data you should be fine. Otherwise it seems that you have the gist of it.