Resolved Class and form interaction

[ConsKa]

So as part of my learning experience, I have been shifting as much code as I could muster to defined classes to limit the length of my Form.cs. I have done this for each of the things that I can think of doing in terms of file naming, time capturing, data storage.

However, quite a lot of my win form application is actually interacting with the win form UI items. There are textboxes, there are buttons and active labels etc.

From what I can see, it isn't that easy to pass out the items for another class to handle, and the best you can do is pass out the information to an object then refer to the object in your code?

So, if I have text boxes that need to be populated after X has happened, I will still need the code in my main Form.cs file for actually sending that data to the text box or taking it from the textbox?

As you can see, I am not 100% on this....

 

[Skydiver]

Yes, that is where the beauty and power of WPF's XAML, and ASP.NET's Razor pages shines. The compiler takes the XAML or Razor and generates the boiler plate code for binding the model to the view's UI elements.

WinForms also has data binding, but it's kind of clunky to use.

 

[ConsKa]

Yes, that is where the beauty and power of WPF's XAML, and ASP.NET's Razor pages shines. The compiler takes the XAML or Razor and generates the boiler plate code for binding the model to the view's UI elements.

WinForms also has data binding, but it's kind of clunky to use.

I was trying to build it in a WPF, as it is the more modern thing to do....but I fell down on this:

(Controls[$"...{ controlNumber }"].Text

As there doesn't seem to be an equivalent in WPF, and I think I have to spend a lot more time on XAML to really get that same functionality - cycling through controls based on their name / number placed at the end - and honestly, I still have so much to learn in C# I have not turned to it yet.

And thanks for letting me know that I am not misunderstanding the UI elements interaction with the WinForm, I did look, but nice to have it confirmed.

 

[Skydiver]

Yes, doing WPF requires a different mindset and approach. The imperative style of WinForms programming doesn't quite jive with the declarative approach used in WPF. (Yes, you can do imperative style in WPF, but it is really counter productive.)

In WPF, if you have to fallback on using code behind to access the properties and methods of a control directly, then you are either writing a brand new custom control where you could just customize an existing control; or you are doing things wrong. Ideally, you should never have to declare an ID for a WPF UI element/control.

In your code above where you are directly trying to access the Text property, you are doing it wrong in WPF. In WPF, you would bind the Text property of the control to the property in your model or view model declaratively in the XAML. If you have a variable number of controls depending on the number of items (as I recall from your past posts), you would declare an ItemTemplate that describes each of the controls for each item, and the control declares a binding to the properties of an instance of an item.

 

[Skydiver]

And thanks for letting me know that I am not misunderstanding the UI elements interaction with the WinForm, I did look, but nice to have it confirmed.

You can write some helper methods to minimize the glue code in the WinForms. Also, with the introduction of extension methods and lambdas in C#, the glue code can be written in a more fluent (and/or terser) manner as compared to the way we used to have to write similar code back in the .NET Framework 2.0 days.