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.
Related
I am working on a Qt-UI with PyQt and found this nice snipped to create a custom collapsible box widget here: How to create collapsible box in PyQt
I have just replaced the internal QScrollArea by a QFrame.
It works perfectly, as long as the content of the layout that is added stays the same.
However, I allow the user to add or remove widgets from that layout dynamically during use. Here I need some help. I am adding a Grid Layout with, say, 3 widgets inside there (initial creation of the box with .setContentLayout) and once the user adds a 4th widget:
the layout is compressed and keeps its original size
all widgets inside are compressed to fit in the newly created one
overall size of the collapsible box is kept constant.
I have played with various options like updateGeometry() on the content_area and all surounding widgets. It seems I don't fully understand what this code does, I am not really familiar with these animations yet. My best guess is, that the animation somehow blocks the update of the height of the collapsible box, causing the layout to be compressed.
I would be really happy for a pointer where to look / what to adjust to get the size of the collapsible box reacting to the size of the containing layout.
Thanks!
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.
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.
I have a requirement to create a button in a Windows 8.1 app which has an icon and a text label. The icon will be a symbol from Segoe UI Symbols and the text label will be Segoe UI Semibold at a smaller text size.
I want to be able to reuse the button in different places within the app, using different icons and text labels.
How show I go about this? I could create a button and then edit the ContentPresenter to have a horizontally oriented stack panel with two TextBlocks, but then how could I reuse this? And how could I change the text in the two different text blocks?
Should I create a separate custom control with separate dependency properties for each of the textblock strings? I'm interested in hearing what you would do.
thanks
Create a simple Style. To make it easy, I would base it off the standardized AppBarButton style. You can format it to whatever size you want (I have done something similar to make a larger button or one with text on the side).
Have the main icon simply be a ContentPresenter which binds to the Content using a TemplateBinding. Make sure to set the FontFamily to Segoe UI Symbol. Have the text label pull from AutomationProperties.Name, similar to how the AppBarButton style does.
Then, whenever you want to use this just do:
<Button Style="{StaticResource MyCustomButtonStyle}"
Content="" // Where "000" is replaced by the number of the icon you wish to use.
AutomationProperties.Name="Text Label"/>
This should be extensible and easily reproducible to whatever location you need. When copying over the AppBarButton style, I suggest removing the artificial size limits (specifically the width of the main content Grid). I do suggest either giving the Text Label a fixed size or having it pull its size from the specified parent Width, so that it will Wrap correctly.
Hope this helps and happy coding!
Are you desiring to create something like for an AppBar? Take a look at AppBarButton and the style/types it supports. In Windows 8.1 we added some things around SymbolIcon specifically. Since you basically want two pieces of 'content' for your style you'll have to re-purpose one property (unless you create a custom control which doesn't sound needed for this scenario). Using AutiomationProperties.Name for the visible label is a good idea because it will also help with accessibility by default for those users.
Investigate the style for AppBarButton to get you started.
I know the title is a little confusing, but the best way to describe what I'm after is by running the Weather metro app on the Consumer Preview; as you scroll horizontally, you'll note that the section headings kind of move around and stay on top of the relevant content, and then fade out as you cross over into a new section. (The main background for the first section also kind of does this)
My question is, how would I go about replicating this behavior in a WinRT app of my own? Are there any existing controls I can leverage or would I have to essentially rewrite it all?
This looks just like a ScrollViewer - you would handle the ViewChanged event and depending on the scroll offset - change the opacity of overlaid static TextBlocks and completely hide the ones that scroll once you cross specific tresholds. I don't think there is anything like that that does it, but I can build it.