The RelativePanel layout control - xaml

I hear RelativePanel and SplitView are new layout controls for Windows 10. What is cool about the RelativePanel put as concisely as possible?

UWP is more focused on making a single app which will run on all the platforms. These panels are also called as Adaptive Panels. It has taken care of Adaptive UI very beautifully in app development.
RelativePanel is better than StackPanel to implement the desired layout for multiple screens using the same base code.
It has attached properties eg. RelativePanel.Below, RelativePanel.Above, RelativePanel.RightOf, RelativePanel.LeftOf which is very useful for making the different UI for different Device family using the same code.
RelativePanel is even more powerful when it is combined with VisualStateManager. You can see the example here.

MSDN has all the answers but here is a summary as concisely as
possible.
RelativePanel defines an area within which you can position and align
child objects in relation to each other or the parent panel. It is
essentially a layout container that is useful for creating UIs that
do not have a clear linear pattern; that is, layouts that are not
fundamentally stacked, wrapped, or tabular, where you might naturally
use a StackPanel or Grid. If your UI consists of multiple nested
panels, RelativePanel is a good option to consider.
Using RelativPanel's attached properties (such as
RelativePanel.Below, RelativePanel.Above, RelativePanel.RightOf,
etc), you can position a UI elment relative to another UI element as
well as relative to the panel (e.g.,
RelativePanel.AlignVerticalCenterWithPanel).
RelativePanel, used in conjunction with AdaptiveTriggers, can be a
powerful tool to create responsive UI that scales well across
different screen sizes. If you want to explore further on this, there
is a sample you can download and experiment with.

Related

Avalonia UI, creating a custom control by drawing things

One could create a control by starting from a container control (like panel) and add other existing controls (like buttons, textbox, etc) on it. But in some cases, there are no such suitable primitive controls and one has to draw things from scratch.
Avalonia UI's Visual Studio extension has a UserControl template, and it seems that it allows adding existing controls using XAML, which is the former case of the previous paragraph. But how to draw from scratch? Where is WinForm's OnPaint() equivalent or WPF's OnRender() equivalent? Is there any example of creating a control from scratch in Avalonia UI?
or WPF's OnRender() equivalent
It's called Render, the name is pretty much the only difference, DrawingContext's API closely resembles WPF one.

How do you properly position elements in XAML without using absolute position?

I have a UWP app that I am working on, and using absolute position creates problems when using the app on screen sizes different than the one it was designed for.
I'm not sure how exactly i should place elements at distances from each other without using margin and absolute position. How should I be doing this?
Edit: I am using XAML to design the UI.
Well, it depends on what UI you want to build up.
There are various panels and, usually, there is NO need to use absolute position in most cases.
Usually, the Grid panel is used to create flexible layouts, by adding rows and columns: for example, if you want to create a page with some content and a bottom app bar with buttons on it, you usually create a Grid with as many rows as you need for your content controls, plus one for the bottom appbar itself.
Years ago, I also started building UIs by using absolute position for every element, but then times passes and you start having a flexible mind in order to build flexible layouts.
Sorry to not answer any further, but your question is just TOO broad to give any precise answer.
Best regards
How do you properly position elements in XAML without using absolute position?
You should use an appropriate layout panel:
Layout panels are containers that allow you to arrange and group UI elements in your app. The built-in XAML layout panels include RelativePanel, StackPanel, Grid, VariableSizedWrapGrid, and Canvas.

Automatically adjusting winform and controls to screen size

I created a winform application. The size of each screen is 1361, 768 in pixels. This worked great for larger screens and/or laptops. But now I have to move my application to 10inch screen tablets, which means my application does not fit.
I have never had to deal with this issue before, how can auto adjust each form size and adjust all of the controls and panels when viewing on smaller screens?
I am using VS 2012.
Making forms fully scalable in WinForms is possible, but it takes a bit of work. The good news is that most of this work is done at design-time, arranging the controls properly so that everything is done for you automatically by the framework. It's drudgery, but it isn't difficult. Rejoice that you don't have to write the scaling code by hand, form-by-form, like you did with VB 6.
There are four fundamental properties that you will need to acquaint yourself with:
Anchor
Dock
Margin
Padding
The last two should be quite familiar web developers who know CSS—they do the same thing here. Padding controls the inner margin around a control, while margin controls the outer margin. You will need to set these correctly to ensure that your controls can "breathe", because the automatic scaling code is just going to jam them up against one another.
The "standard" margins around a control in a Windows desktop application are approximately 12–15 pixels. You should make sure that you leave at least this much room. Then add additional margins/padding as you see fit to separate things. I keep these layout specifications bookmarked for reference. This is another good reference.
The next step is to instruct the layout manager how you want the controls to be arranged and resized. The key to this is to think in terms of container controls and child controls. The form itself is a container control, and you can set its child controls to either Anchor or Dock within its boundaries. One or more of those child controls can itself be a container control, and its child controls can be Anchored or Docked within its borders. The nesting is virtually unlimited, but for your own sanity and reasonable redraw performance, you'll want to keep it to a reasonable minimum.
A good way of doing this is to use the two provided invisible layout helpers, FlowLayoutPanel and TableLayoutPanel. Personally, I don't find the former very useful very often, at least not for standard Windows applications. But the TableLayoutPanel is invaluable.
Generally what I will do is fill my entire form with a TableLayoutPanel (margins = 0, dock = fill). Then I will add individual controls (or sometimes another nested TableLayoutPanel) to its cells. Those child controls will have their margins set appropriately, and will have either their Anchor or Dock properties set, depending on whether I want that control to have a fixed size or resize dynamically.
Before you get the hang of how these properties interact and how it all works, you'll probably need to play around with your layout a bit. Make a backup of your forms and then just dig in. Or, you might find it easier to start designing each form from scratch (you can still copy-and-paste individual controls in order to preserve their other properties). Eventually, it will all start making sense to you, and you'll be up and going in a jiffy.
The great thing is, once this is all set up, all you have to do is ensure that your form is resizable. Then, whether the user manually resizes it or uses the maximize/restore button, it'll automatically fill their screen size. This also works well for all DPI settings, which is another common Achilles' heel of WinForms devs.
Try to get the resolutions variables to adjust your screens, there is an answer to get these variables using the Screen class
Getting Screen Resolution
DevExpress has a great control call the Layout Control. This control helps to maintain consistent whitespace between controls as the form is resized. It does take a little study to use the control effectively but once you understand how to use this control the results are consistent and you are able to speed through form design.

Content control for complex layout

I start to learn winrt so I have question regarding containers in xaml.
I want to have on main screen of my app a set of different custom controls, but i want to have such interface like in Gridview (Horizontal scrolling, names for groups).
Yes, I can use GridView with different templates per item. But it's not a good solution.
For better explanation please review my picture. It's my goal.
How can I do this? Should i write some kind of custom GridView or there is already such or similar controls?
Thank you!
You can achieve this by using the following:-
-Scroll Viewer
- StackPanel (orientation horizontal)
-Grid view
-User Control
-...
If you are targeting 8.1 then you can use the new hubs which are designed exactly for the described scenario.

Why use XAML in visual studio express for windows 8?

i'm trying to do an application for Windows 8 and i'm following a guide on channel9.msdn
I cant understand why they use XAML to create textbox, label or other controls.
There's a reason ? There's a form which is much faster: simply drag & drop controls into the UI.
So why use XAML ?
Thanks all and sorry for my english :/
XAML supports laying out the form so that if you resize the window, the controls contained in the window are always consistently positioned according to the layout.
If you just drag and drop, you will see that the designers uses margins to position the controls. When you resize the window, they kind of keep the same position and are not going to be well positioned anymore.
This layouting is the essence of WPF. Just read a tutorial about layouting in WPF.
Drag and drop creation of UIs when using XAML creates very poorly formatted XAML and since there are a significant number of things which are most easily done in XAML (data templates for instance), it's easier to simply construct your UI in XAML from the start.