In WinForms, when creating an element, we could just click on it - and the studio created an event handler for this element, for example

private void Button1_Click(object sender, RoutedEventArgs e) { }

It was enough to just enter

 Button1.Text = "ПомСняли тСкст ΠΊΠ½ΠΎΠΏΠΊΠΈ"

And everything would work. But in the UWP application, when you click on the same button, the studio creates the same handler, but calls it

 private void Button_Click(object sender, RoutedEventArgs e) { }

And now turn to the interface element can not be. Is that in the very Xaml-e write the name (by default it is not) and already refer to it

 <Button Content="Button" **Name="btn1"** HorizontalAlignment="Left" Margin="177,85,0,0" VerticalAlignment="Top" Height="123" Width="264" Click="Button_Click"/>

And the button itself has no text attribute. There are even

 btn1.FontSize

And there is no text. In general, please explain for those transferring from WinForms - why did these things be removed, and what was put to them for replacement?

  • one
    Instead of Text there Content. Because inside the button there can be not only text, but anything, even though the table with the web browser and the embedded video. - VladD

1 answer 1

The paradigm is completely different - this is the development of the ideas of WPF . You need to learn the MVVM pattern - without it, everything is sad. Everything related to the display is written in xaml, the same button is essentially a container where you can cram more elements - yes, even the button inside the button can be crammed until it is blue, for the same text you need to put a TextBlock inside:

 <Button> <TextBlock>НаТми мСня</TextBlock> </Button>

from the code, you can push into the Content property - but you don’t need to do that, since the View fully specified through the declarative xaml markup. In principle, the old one is also possible, but as you have noticed, you need to force the elements to give names, and you still cannot get away from learning the xaml markup, and this way will be thorny and generally meaningless. Such is the price of WPF 's WindowsForm visual flexibility regarding WindowsForm . In the MVVM paradigm, element names are extremely rarely needed - the code with the display is relatively weakly connected through bindings and commands. In particular, this makes it easy for different people to work on UI and business logic is not particularly intersecting. Well, the ease of testing is also a huge plus.