Executing textbox TextChanged code without changing the text

I want to execute my “textbox changed” code (1) when I change the code in my text box, and (2) in other places in my code.

I would like to do this without creating a separate subroutine, as I have done in the following example:

Code:

---

Sub GetIterMax()
    ‘ My code for getting the maximum number of iterations
End sub

Private Sub TbxIterMax_TextChanged(sender As System.Object, e As EventArgs) Handles tbxIterMax.TextChanged
        GetIterMax()
End Sub

---

Chat AI suggested two things that generated error messages. They were:

Code:

---

tbxIterMax.OnTextChanged(New EventArgs())
Error BC30390” TextBoxBase.Protected Overrides Sub OnTextChanged(e As EventArgs)' is not accessible in this context because it is 'Protected'.

RaiseEvent tbxIterMax.TextChanged(tbxIterMax, New EventArgs())
Error BC30676: tbxIterMax is not an event of form1

---

Let’s see if humans can do better.

I’m using Visual Basic in Visual Studio 2022.
Windows 11

What you already have is the proper way to do it so why try to do it any other way? If you really must then you can just call the event handler directly but why would you? Writing clear, readable code should be your priority and you already have that. Making the code less readable to save writing one method is just bad.

Quote:

---

Chat AI suggested

---

Spotted the problem right there.

Quote:

---

I want to execute my “textbox changed” code (1) when I change the code in my text box, and (2) in other places in my code.

I would like to do this without creating a separate subroutine, as I have done in the following example:

Code:

---

Sub GetIterMax()
    ‘ My code for getting the maximum number of iterations
End sub

Private Sub TbxIterMax_TextChanged(sender As System.Object, e As EventArgs) Handles tbxIterMax.TextChanged
    GetIterMax()
End Sub

---

---

As the Mandalorians say "This is the way" ...

This is what works, this is what's the generally accepted Best Practice (pat pend) way to do it.


-tg

I think what Chat AI wanted to suggest, but didn't quite get it was this:

Code:

---

TbxIterMax_TextChanged(TbxIterMax, EventArgs.Empty)

---

While that would work, I certainly wouldn't consider it to be best practices.

Not to beat a dead horse, but setting up a method and calling that method when appropriate is the best way to approach this.

Well, that's been covered, but I'm REALLY curious as to what's wrong with writing a second method? I can think of one reason that is technically right, but mostly wrong, so I'm hoping there's a different reason.

Quote:

---

Originally Posted by Shaggy Hiker

Well, that's been covered, but I'm REALLY curious as to what's wrong with writing a second method?

---

I'm going to go with the misconception that writing less code is automatically better.

Thanks for your answers. Your suggested code works. This forum has provided better help than the chat.
TbxIterMax_TextChanged(TbxIterMax, EventArgs.Empty)

I wanted to reduce the number of subroutines so I could more easily understand my own code.
I am reworking an old program and had forgotten that my code changed my maximum number of iterations nIterMax when the text in my text box changed.
I hoped that reducing the number of subroutines would make this more apparent.
Thanks for letting me know that using separate subroutines is the best practice.
Knowing this I might stick with my old code and add a few comments for myself - in case I'm looking at it in 2034, climate change and age permitting.

I'd suggest that you should have MORE subroutines, not less. It all comes down to the size of the methods and your naming conventions. I'd say that GetIterMax is not a bad name at all, as I feel that I know exactly what it does based on that name. That's a good start. Beyond that, what I find is most difficult to understand is when there is one large method. Keeping all methods quite small, even if that means splitting a large method up into several smaller methods, will add to the readability of the code in the long run.

Having said that, TbxIterMax_TextChanged isn't a horrible name, either, as it says what event this is used for right in the name. As a general rule, calling event handlers directly like this isn't a good practice, but it's also not inherently bad, either.

Ultimately, making code comprehensible to whoever reads it, even if that's just you a week from today, is a difficult task.

Look into XML comments so that you can leverage intellisence to quickly discern what a method is doing.

First of all, I would suggest that you follow Microsoft guidelines and not use bad abbreviations. There is literally no reason to use "Iter" instead of "Iterations", given that we have autocomplete these days. Also, a method whose name starts with "Get" should be returning the value indicated by the rest of the name. It sounds like you method should actually be named "SetMaxIterations" and the field "maxIterations".

I'm not sure why you think that eliminating that method will make things better. The name of your event handler won't change so there will be no more indication there that you're modifying that field when the Text changes. You'd still have to read the code to know what's happening and then you would have the benefit of a suitably-named method to self-document the code. There is a school of thought that you should never do anything directly in an event handler but rather always do everything in methods with names that indicate the purpose, so when you read an event handler you can see exactly what it does from the method calls and not have to work it out from the code.