Using XMAL or Code Behind for form controls in WPF

[MPIon]

I am learning WPF for a c# home project (Desktop not Web) and have a basic book on WPF, but it is missing some fundamental points that I can't find answers to.

As I understand it, the XMAL is for the front end forms with code in the back end (in my case c# - all developed in Visual Studio 2022).
Now, suppose I want 100 picture boxes on my form, I don't want to name them PictureBox1, PictureBox2 etc., I want them in an array of picture boxes, which I can easily do in the c# code.
Unless I am missing something, this can't be done in the XMAL. So, now I have some form controls created in the XMAL and some in the c# code (which also means the XMAL is intimately tied to the back end - it won't just plug in to any back end code (Java, VB etc) without code behind for each).

So, how do you decide whether to create the controls in XMAL or in the back end? Why not create all the controls in the back end and not use the XMAL at all?

Also, as I understand it, XMAL creates the controls using Vector graphics rather then Raster graphic as in WinForms, but are the controls created in the code behind also created with Vector graphics?

Basic questions I know, but necessary to understand.

 

[JohnH]

XAML - Extensible Application Markup Language. Similar to HTML which is HyperText Markup Language.

 

[JohnH]

Databinding and templates are common in WPF, think about for example a winforms DataGridView, you add a single control and set up some formatting for the columns/rows, bind the data and all 100 rows appears. In WPF such grids is a lot more customizable, a "data row" or object can be presented and repeated using combination of common elements like button, textbox, image etc. Take a look at this: Displaying Images from a folder with details in WPF | WPF

 

[MPIon]

XAML - Extensible Application Markup Language. Similar to HTML which is HyperText Markup Language.

Yes sorry, typo on my part.

 

[MPIon]

Databinding and templates are common in WPF, think about for example a winforms DataGridView, you add a single control and set up some formatting for the columns/rows, bind the data and all 100 rows appears. In WPF such grids is a lot more customizable, a "data row" or object can be presented and repeated using combination of common elements like button, textbox, image etc. Take a look at this: Displaying Images from a folder with details in WPF | WPF

Ok, thanks, You seem to be implying that 100 picture boxes could be created easily directly in the XAML, though I'm not sure how that would be done yet.
Much more reading to do on this. Probably need to find an example where someone has done this - with basic objects such as PictureBox or TextBox or Label.

I read the link you provided, but could not quite see how this was done. Is it that the template for the Picture Box is created in the XAML, but the c# code needs to actually create the multiple copies of the item using an array of the objects?

 

[JohnH]

In that example there is a single Image element (and some textboxes) in the ItemsControl.DataTemplate, it is bound to the Path property of the bound object. In code-behind a list of ImageDetails objects is created and assigned to ItemsSource of the ItemsControl. When run it will display the image and details of each image file in the folder.

 

[MPIon]

In that example there is a single Image element (and some textboxes) in the ItemsControl.DataTemplate, it is bound to the Path property of the bound object. In code-behind a list of ImageDetails objects is created and assigned to ItemsSource of the ItemsControl. When run it will display the image and details of each image file in the folder.

OK, I am beginning to get it. However, I can't quite see the link between the back and front end. In the XAML, there is an item named "ImageList", but in the code it refers to "ImageDetails".
Which is the bit of code in the c# that actually adds the picture boxes to the form?

 

[Skydiver]

Moving out of WinForms to WPF...

 

[MPIon]

Moving out of WinForms to WPF...

Yes and seeing the complexity of WPF just to do a simple thing, I might just stay with WinForms! Do I need the aggro - drag and drop is great.

 

[Skydiver]

Drag & drop is great until you need to do responsive UI, or you need to do internationalization.

Personally, I can't stand the pixel counting involved when doing drag & drop, even with snap-to enabled. Invariably the snap-to numbers are wrong if you want to comply with the Windows UI guidelines with regards to space between border and control, space between controls, minimum height and width of controls, size of scrollbars and thumbs, etc. -- all of which are not nice multiples of each other.

On the other hand, if you don't care about Windows UI guidelines to contribute to the fragmentation of Windows UI and give credence to Windows critics who say "I don't like Windows because the UI is so inconsistent between apps", then have at drag and drop and place controls anywhere you please.