I'm creating a simple UWP application for myself and stuck with lack of understanding of how binding and all that stuff works. Don't know how to explain it better So I created a simple example: https://gist.github.com/anonymous/744dc688d0663a3c14b7a2fc424316f8
The program has a list of selectable items on main screen. I can select several items, press a button and program will show new floating panel, with selected items (And I do further management of these items in my original program). I want this panel to be separate control because my MainPage is already overfilled with code.
The problem is. When I click on the button first time - it works as I expect. But then, when I change selected items and click button again, it shows panel with items from first selection.
My question is - how to do make it work? I have a feeling that it has to be something with INotifyPropertyChanged but cannot understand it.
And I also would be glad to hear the overall recommendations. I'm not c# developer. I'm actually sys. admin but I know a little of python and I learned Delphi 7 in university. So I'm kind of learning c# in process of creation of this application.
UPD: If I change line 28 of SelectedItemsView.xaml from
ItemsSource="{x:Bind SelectedItems}"
To
ItemsSource="{Binding SelectedItems, ElementName=SelectedItemsViewRoot}"
(and add x:Name="SelectedItemsViewRoot" to user control attributes). It works as needed. So new question arrives - is this correct way to do this? I though that Binding is kind of legacy and x:Bind is newer approach that should be used in new apps.
It's ok to use {Binding}, but if you want to stick with {x:Bind}, you can do this with OneWay mode (instead of default OneTime). For example: {x:Bind SelectedItems, Mode=OneWay}.
I strongly encourage you to read these two official tutorials:
Data binding overview and Data binding in depth.
In short, {Binding} is not legacy. It's actually a bit more flexible, but it's performed in runtime, while {x:Bind} is perfmormed at compile time, thus a bit more performant.
Related
Writing a fairly simple app with c#/wpf.
When opening a second window there is a brief flicker or flash.
Extensive googling says that this caused by screen repainting, so not much I can do about that.
(I haven't included any code because it seems this problem is well known and something most people 'learn to live with')
So, I thought, why not put all the XAML in one file with each page within its own grid that I can hide/show with visibility.visible or visibility.collapsed etc.
Works nicely (apart from a very slight delay - less than 1/2 second - the first time i show the second window grid), but I'm unhappy at the idea of containing all the code behind in a single page. (for what its worth, i'm told that compiler see's it all as one file anyway but ... )
Is there a way I can create separate 'code behind files for each 'windows' (in reality a XAML Grid) functionality whilst linking them all to the same Xaml File?
(I have a horrible feeling having typed this that the answer is obvious and I should already know it ...)
Thanx
If I understand you correctly, you just need to create a new Control Class-Code Behind pair for each 'window grid'. This is done in VS by clicking Add-Create Element-User Control (of name UserControl1.xaml, rename it to something Like YourControl.xaml) in Solution Explorer (I think you already know all this, but just in case).
Now, if there is no specific requirement for the control to be of type Grid, you can use it as it is:
<MainWindow>
<Grid>
<YourControlNumberOne />
<YourControlNumberTwo />
<YourControlNumberThree />
<Grid/>
</MainWindow>
If you specifically need Grid-based control, just change the base class of YourControl to Grid, and change the topmost XAML element in the associated XAML file to Grid.
I'm just starting with Universal Windows Platform and actually C# as well (I've got a C background) and just trying to get my feet wet with a basic accounting app meant to keep track of a checkbook. The way it works is simple, the user either presses + or - buttons and specifies the name of the transaction and the amount either credited or debited, hits ok and that transaction is inserted as a row.
So it would look something like this
Gas ($20) 1/5/17 _delete_button_
Paycheck $2400 1/3/17 _delete_button_
Total $2380
....
So each row has 2 editable text boxes (name and amount), one textfield for date, and one button to delete that row.
Now my first instinct as a C programmer is just to create a struct with those variables and every time user inserts a row just populate the struct and push it on a stack. However I just want to make sure that this is the best way to do this and I'm not missing some feature of XAML that would let me do this.
"Now my first instinct as a C programmer is just to create a struct
with those variables and every time user inserts a row just populate
the struct and push it on a stack. However I just want to make sure
that this is the best way to do this and I'm not missing some feature
of XAML that would let me do this."
This question is dangerously close to not meeting the requirements for a good question because it is too broad, but I will answer anyway due to remembering the pain I went through with XAML when new. Whether new or experienced (and I am at most in the "intermediate" category), it seems XAML has its bits that will always send you looking for help. But I digress.
The standard is to create your model, then somehow connect (or "bind") the appropriate parts of the model to your view.
You would use C# (actually can use VB or F# or others also) for your model. This is where you would create your "struct" you are referring to. This would define your individual transaction. Then, create a collection of these transactions, again in your model.
In XAML, you bind to this collection. You have a control (a visual element in your view) that displays all transactions. You have a control for specifying the name of a specific transaction, for selecting a transaction, for inserting, for deleting, etc. All of these controls interact with the model through the bindings.
So, to answer your question, yes you are missing a feature of XAML. It is called binding. Not to be sarcastic but unfortunately, binding is a technology worthy of months of study. Sorry, but you will want to go back to C with no UI at first. Keep at it! If you want to do the universal app thing, it is worth it. You may even find yourself liking (parts of) it.
Link to get thou started:
WPF and other XAML-related
I've put together a scheduling application similar in style to that found in outlook, however it can show the schedules of multiple people. I have written a user control, basically a Border with gradient filled background & TextBlock. One of these controls are added to a Canvas at a set location for every appointment. The trouble is, I will have multiple users, with multiple appointments and may need to display 1000 or so appointments at a time. Initially, it takes an absolute age to instantiate all of these objects, however, I can live with this.
Unfortunately, the big problem arises when I try to scroll through the appointments. I have a couple of buttons to scroll left and right and upon clicking these, the UserControls' Left position are moved left or right a certain number of pixels - it can take several seconds between clicking a button and repainting(I also tried with labels just to test, but it was the same).
I guess the real question here is how to implement an interface, showing hundreds of controls with adequate performance and if this isn't achievable, how would I approach such an UI.
One possible option is a TextBlock CustomControl. You can get the exact same style as you have in your usercontrol but with a somewhat faster loading time.
Without a good, minimal, complete code example that reliably reproduces the problem, it will be difficult if not impossible to completely understand the performance problem you are having, never mind provide a solution.
That said, from your description it sounds like you are really looking to present the user with some type of ItemsControl, such as ListBox or ListView (a specialization of ListBox). In an ItemsControl, you can specify an ItemTemplate that defines how each item in the list will appear; this is analogous to the UserControl you apparently are using now.
I believe it's likely it will work fine just with that change alone. I.e. define your per-item visual as a DataTemplate instead of a UserControl, and set the ItemTemplate property of e.g. your ListBox to that template, then just bind your collection of appointment objects to the ListBox.ItemsSource property.
Note that the ListBox class already defaults to using VirtualizingStackPanel in its ItemsPanel template. So you should have no performance problems at all with this approach if you use ListBox.
If you want to use a different ItemsControl or create a custom one, you may or may not find that you need to use a virtualizing panel object explicitly (such as the VirtualizingStackPanel that ListBox uses). With just 1000 items in the list, even a non-virtualized panel may be fine, but if not then even when not using ListBox, you can always specify it explicitly.
is there any way to make winforms listView showing data like treeView. i mean to make it verticaly oriented and to show columnHeaders one under another and not to put them in horizontal line?
thanx for assistance
Consider using this open-source ObjectListView.
It's a mature control that can show all sorts of lists, a tree-list and much much more (not my code - I'm just a happy user).
It take a few minutes to get used to the idea of using it, but once you got it - using it is a breeze.
Examples:
You can also consider using Better ListView. The usage is 99% same as the original .NET ListView, but it has many extras. For example, every item has a ChildItems property in which you can put further children.
I would like to have the standard silverlightcombobox behave like an html combobox.
So let's say I have a combobox for all states in the US, If I press the 'I' key, it should navigate the selected item to start at the I's ... Is there anyway to do this, it doesn't make sense that it's not built in functionality.
Maybe I missed the memo? Any ideas?
It's not something that comes as standard - even in Silverlight 4 (I hit this very problem today).
However, there are quite a few DIY implementations on the net:
http://gistom.blogspot.com/2009/12/silverlight-combobox-with-keyboard.html
http://www.codeproject.com/KB/silverlight/ComboBoxKeyBrdSelection.aspx
http://www.reflectionit.nl/Blog/PermaLinkd137c1f7-a515-4084-8199-f8b3cf892b8f.aspx
The author of the last post
created a small Behavior which fixes this problem. You can attach the KeyboardSelectionBehavior to a ListBox or ComboBox using Microsoft Expression Blend. You drag it from the Assets and drop it on your ComboBox or ListBox. If you have a custom ItemTemplate you will have to set the SelectionMemberPath property.
If you don't have access to Blend then just use the code as a template and edit the XAML by hand to produce the same result.