0

I am working on my first real WinForms application using VB.NET and the project is getting a little bigger than originally expected - so I'm more or less forced to deal with the challenge of structuring my code a little better. I'm not used to doing this in WinForms so I'm not sure if the solution that I found is the right way to do it:

Since I have a lot of Control elements, especially TextBoxes, I really need to move the code for handling different events to another class. As far as I've seen, there are many different ways how to do this, depending on what kind of program you're working on. The one I found the easiest to understand is creating an additional class and declaring all the necessary Control objects using WithEvents. So for example in my main class I would have:

Private Sub txtCustomerName_TextChanged(sender As Object, e As EventArgs) Handles txtCustomerName.TextChanged
' do lots of stuff here
End Sub

and if instead I want to move all that code to my new class, it would look something like this:

Public Class Events
    Public WithEvents txtCustomerName As TextBox

    Public Sub New()

    End Sub

    Private Sub txtCustomerName_TextChanged(sender As Object, e As EventArgs) Handles txtCustomerName.TextChanged
    ' do lots of stuff here...
    End Sub
End Class

meaning that all I would have to do in my main class now would be:

Dim events As New Events()
events.txtCustomerName = txtCustomerName

and do this for all the other Control elements as well. That way, I could keep my main class a lot cleaner but I would end up with a huge class full of event listener code. I feel like this would help me a little bit but it still feels kind of crude. My next idea would be to maybe split this up further so I could have one event class for TextBox events and another one for Button events - but then again I'm not even sure if I'm on the right way here or if I'm missing something entirely.

DanielRichter
  • 11
  • 2
  • *"Since I have a lot of Control elements, especially TextBoxes, I really need to move the code for handling different events to another class"*. No you absolutely do not. That is utterly the wrong approach. The code to handle the events of controls on a form belongs in that form. You can make the code in the form more manageable by using regions, which allow you to collapse sections of code to get it out of the way. You can also break a single class into multiple parts in different files. A form is already broken across two files for the designer and user code. – jmcilhinney Feb 22 '21 at 11:37
  • In VB, only one partial class definition has to include the `Partial` keyword and that is already done in the designer code file. If you want to see that file, select your project in the Solution Explorer and click the Show All Files button, then expand the node for your form. In that file, you'll see the `Partial` keyword and the `Inherits` keyword, so they are not needed in other parts. If you want a partial class for just event handlers, create another code file named Form1.EventHandlers.vb and declare the Form1 class in it. You can then use the navigation bar at the top to create handlers. – jmcilhinney Feb 22 '21 at 12:10
  • It's not necessarily a bad idea to move code out of the form if that code is not directly related to that form. For instance, you might move data access code into a dedicated class that then doesn't have to know anything about forms and could be used in any type of application. Code that is specific to the form, e.g. handlers for events of controls on that form, should definitely be part of that form though. – jmcilhinney Feb 22 '21 at 12:30
  • Some additional alternatives that you might consider: If some of your event handlers are doing formatting or data manipulation on the control itself (rather than controlling interaction with the rest of the program), you might consider writing a derived control that encapsulates the event handlers so you don't need to write them for every instance on the form. Also, if you have multiple controls which need one common event handler, you can also consider having a single routine handle the event (`Handles` allows a list of controls and events, not just a single one). – Craig Feb 22 '21 at 13:59
  • Most of my Controls are used to keep different objects up to date and in some cases perform different actions with the values that were entered by the user. I think I will stick to using regions then as suggested by jmcilhinney. – DanielRichter Feb 22 '21 at 14:14

0 Answers0