Yes/No message box always returns yes - VB.Net

Question

I was experimenting with message boxes, and tried a simple yes/no messagebox So I wrote this simple piece of code. However, the \"chc\" variable always returns as 1, no matt

Answer 1

The MsgBox() method is returning MsgboxResult Enumeration, check the value that the method returns:

Public Sub MsgBoxExample()
    Dim result As MsgBoxResult = Nothing
    Dim chc As Integer

    result = MsgBox("click something...", vbYesNo, "example")
    If result = MsgBoxResult.Yes Then
        chc = 1
    ElseIf result = MsgBoxResult.No Then
        chc = 0
    End If
    MsgBox(chc)
End Sub

Answer 2

Turn on strict compilation.

• You can do this for a file by placing Option Strict On at the top of your file.
• You can do it for a project in project properties > Compile > Compile Options, setting Option strict to On.
• Make it the default for all of your projects in Tools > Options > Project and Solutions > VB Defaults.

Really, do it. It is one if the easiest, quickest ways to catch all sorts of errors before they happen. You might get hours of your life back. I'm not exaggerating.

With strict compilation turned off, the compiler sees this:

If MsgBoxResult.Yes Then

And says, 'If/then checks for whether a condition is true or false. MsgBoxResult.Yes isn't a boolean - it's an integer. But I'll convert it, and say that anything other than zero is true.'

The problem is that all values for MsgBoxResult are non-zero. So even MsgBoxResult.No is "true."

With Option Strict On, you'll get this compiler error:

Option Strict On disallows implicit conversions from 'MsgBoxResult' to 'Boolean'.

And as soon as you see it, you'll realize that you meant

If result = MsgBoxResult.Yes Then

and you'll fix it before you even run the program.

Compiler errors are better than runtime errors because you don't have to debug the code to figure out what's wrong, or worse, have a user report it and then have to figure out what went wrong. We all make little errors, and the compiler catches them right away.

When you turn on strict compiling, you might see tons of other errors. Each and every one of those is something that could possibly cause a runtime error.

Having strict compiling turned off allows us to do all sorts of evil things like

Private Sub WhatDoesThisDo(x As String, y As Integer, z As TriState)
    If x And y And z Then
        'do something
    End If
End Sub

Then if you call

`WhatDoesThisDo("x", 0, TriState.UseDefault)`

You get a runtime error,

System.InvalidCastException: 'Conversion from string "x" to type 'Long' is not valid.'

It's like having a two-direction highway instead of letting cars drive all over the place and hoping they don't hit each other. It's not guaranteed to prevent accidents, but it eliminates a huge potential cause.