bad form to put messagebox in a class

[rickford66]

Hello,
I seem to remember reading somewhere that it's bad form to put message boxes and input boxes in a regular class, and that they should be used in form classes. I realize this may be subjective, but I wanted to get the opinions of some professional coders.
Thanks.

[Shaggy Hiker]

It's bad form to use InputBox, in general, cause it's such a poor method. The fact that you can't distinguish between the user hitting Cancel, or leaving it blank and hitting OK, is reason enough not to use it.

As for MessageBox, I don't feel it's bad form to use it in a class if it is appropriate in the class. The use of it does require that the project reference Windows.Forms, but the only application that can avoid referencing that would be a console app. So, it might be an issue in a very rare situation, but for the most part, what alternative do you really have?

[Sitten Spynne]

It's hard to say there's a "right" answer to this. It depends a lot on the practices you follow.

I try to follow practices that maintain a very strict separation between UI code and logic. That's why I would say "I wouldn't put a MessageBox.Show() call in a random class." It's a UI concern, so it should be in a UI-related type. If I don't mess with MessageBox directly in my non-UI classes, I should be able to test they do the right thing without needing to show the UI. That's a big deal in large-scale application development.

There's also the matter of reuse. Say I'm validating a username and I write this method:

Sub ValidateUsername(ByVal username As String)
    If String.IsNullOrWhitespace(username) Then
        MessageBox.Show("Username cannot be blank.")
    End If
End Sub

That might be fine in my signup form. As I write my backend logic, I'll also want to check the username there, especially if signup happens over an API. But if I try to use that version of ValidateUsername() on my server, the whole thing will grind to a halt when it displays the MessageBox! Not cool.

If you're working on a small project and you understand the whole scope, it's less of a risk to write code that isn't separated. But I find most professional code starts its life really small, then grows over time. Writing lots of, "When this happens do this in the UI" methods tends to make it harder and harder to add new behaviors. It's much better to write helper functions that let you decide "do this in the UI" as late as possible.

[Shaggy Hiker]

I would make a similar point in a different way. If you must inform the user, then you must inform the user, and Messagebox is a good way to show certain types of information. So, what's the alternative? There are a variety. Code that is running on a server, CAN'T inform the user of anything using Messagebox. It won't be seen, and will block the process. Code in a library may or may not be able to inform the user via MessageBox, depending on how the library is intended to be used. In both cases, it may make most sense to log the information. This can be done either by storing to a DB, storing to a List(of String), or a collection of some other type. Another alternative, if it makes sense, would be to populate either a label or listbox on some other form.

The key point is that MessageBox is all about informing the user of something. It is only one way to do that, and which way is best depends on the situation. However, if it's the right way, then use it.

[Sitten Spynne]

Yeah, I started to diverge into a discussion of Separation of Concerns and edited about a page of text away.

"Is the thing invalid?" is a question I want to ask, but I might do any of a hundred different things in response. So I want to have a tool that answers, "Is the thing invalid?" and I'll choose the tool to do the right thing in response as I need it.

So my answer is less about MessageBox specifically and more about not wanting to mix different things together.