Is there any performance hit when we use any Expand (FillAndExpand, CenterAndExpand) attribute with any Layout (StackLayout or FlexLayout)? Any recommendation for how to use layout with considering the performance of the app.
From the official documentation:
Don't set the VerticalOptions and HorizontalOptions properties of a
layout unless required. The default values of LayoutOptions.Fill and
LayoutOptions.FillAndExpand allow for the best layout optimization.
Changing these properties has a cost and consumes memory, even when
setting them to the default values.
And,
When using a StackLayout, ensure that only one child is set to
LayoutOptions.Expands. This property ensures that the specified child
will occupy the largest space that the StackLayout can give to it, and
it is wasteful to perform these calculations more than once.
So, having this in mind, try to simplify your layouts as possible, and only set Expand if it is really necessary.
You can read more information in Xamarin Performance Doc.
Related
I have a couple of ListViews on different pages in my UWP application. For some reason, one of them seems to have Padding along the bottom below the last ListViewItem, while the other does not.
Neither of them has bottom Padding specified, so I'm wondering if this could be inherited from a parent control? I searched the entire XAML of the one with Padding, and it is not set anywhere else either. It isn't a huge problem, but I would prefer my controls to be consistent throughout my application, and I think adding the bottom Padding to the ListView without it to make them match seems silly, especially when I am unsure of why the first one has Padding in the first place.
Is there somewhere to determine where properties are set in the hierarchy, similar to the way CSS works?
Here is what they look like:
No padding:
Padding:
I added a Background to the ListView control to verify that there is no Padding there..
So it would seem it would have to come from the ListViewItem itself, but it does not have the Padding property set.
The issue turned out to be that one of the parent controls of the ListView that was displaying correctly (how I wanted it to) had a VerticalAlignment="Top" set, while all the parents of the other ListView were set to VerticalAlignment="Stretch".
I was finally able to get XAML Spy working properly, and it was helpful in previewing the changes while the application was running so that I could determine which element I needed to set the VerticalAlignment on without recompiling over and over again. Thanks to #ChrisW for the recommendation.
I have a ListView binding to grouped data. What I would like is to be able to bind the background of each group based on the content of the item. GroupStyle.ContainerStyle was deprecated in 8.1 without changing the ItemsPanel of the ListView. This unfortunately comes with a performance hit though.
Is there a way for me to define a background for the entirety of a Group without changing the ItemsPanel of the ListView?
Unfortunately, I can't change the template of the items and header together (though I've tried) because some of the items are duplicated and do not know which group they are in.
There are two different approaches to solve this problem:
add the responsible Property to your ItemTemplate and connect it with a converter, which converts it to a type you need (in your case a BackgroundColor). The problem is, as already mentioned, that this is very costly and in my opinion a converter is not made for such a huge operation. Don't forget that in MVVM the ViewModel should provide all the information which is needed by the one who designs the view.
the better way is to add a Property which is called something like “ItemBackground” and which you bind to the ItemTemplate. I prefer this approach, because there is no logic which background to use in the View.
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.
The documentation for HBox and VBox includes the statement:
Deprecated: Use Box instead, which is a very quick and easy change.
But we recommend switching to Grid, since Box will go away eventually.
However, it isn't obvious what the "quick and easy change" should be.
How do you use Box and/or Grid to achieve the functionality of VBox or HBox?
One of the big changes in gtkmm3:
Gtk::Box, Gtk::ButtonBox, Gtk::IconView, Gtk::Paned, Gtk::ProgressBar,
Gtk::ScaleButton, Gtk::ScrollBar and Gtk::Separator now derive from
Gtk::Orientable, allowing their orientation (vertical or horizontal)
to be specified without requiring the use of a derived class such as
Gtk::HBox.
Although Grid isn't mentioned above, both containers now have a method set_orientation; Box can also take it in the constructor. So for Box, set the orientation and use your usual pack_start, pack_end.
With Grid, if you scrutinize the documentation, you'll see this line:
Grid can be used like a Box by just using Gtk::Container::add(), which
will place children next to each other in the direction determined by
the orientation property.
So, it should be as simple as setting the orientation and then add your child widgets.
I want to detect CompositeTransform's TranslateY of ListBox. For this it's necessary to set the ListBox ScrollViewer.ManipulationMode="Control".
However, it causes lag when the listbox is dragged. How to avoid this?
I'll recommend you read following article on ScrollViewer performance.
The MSDN remarks for ScrollViewer.ManipulationMode says
In Windows Phone OS 7.1, the ManipulationMode property enables you to
specify how most of the property updates and events associated with
scrolling a ScrollViewer are handled. You can specify that the system
will handle the manipulations or that you will handle the
manipulations at the control level. In most cases, to ensure smooth
scrolling, you should let the system handle the manipulations, which
is the default behavior.
As you can see, it's unlikely you'll be able to get smooth scrolling and virtualization, when setting the ManipulationMode. What precisely do you need the TranslateY value for?