0

I have a Visual Studio 2015 Windows Forms program with a menu form and several others. The code for the menu button in question looks like this:

Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    Me.Visible = False
    Form1.Show()
End Sub

When this button is pressed, Form 1 is loaded. Within the Form 1 load event is the following For loop:

For i As Integer = 1 To 10
        If x_DataTable.Rows(0)(i.ToString()) <> "" Then
            Me.Controls(("txt" & (i)).ToString()).Text = x_DataTable.Rows(0)(i.ToString())
            Dim s As String = Me.Controls(("txt" & (i)).ToString()).Text.Trim()
            If Convert.ToInt32(s.Substring(s.Length - 2)) < (m_DataTable.Rows(0)("Limit")) Then
                Me.Controls(("txt" & (i)).ToString()).BackColor = Color.IndianRed
            End If
        End If
    Next

Every time that the debugger hits the line that starts with "If Convert.ToInt32", it exits the for loop and the load event sub, and skips backwards to the Form1.Show() statement in the menu code above. Any idea what might be causing this or how to make it execute the code normally?

  • Maybe an exception because `s.Substring(s.Length - 2)` could not be parsed to an integer – Tim Schmelter Jul 26 '17 at 12:02
  • Turn `Option Strict On` – Trevor Jul 26 '17 at 12:23
  • @Codexer I tried turning option strict on, and it gave an error message until I cast the latter half of the line in question to an Integer, but after that it still skipped lines... Thanks for the suggestion though. –  Jul 26 '17 at 12:37

4 Answers4

0

Please Check Convert.ToInt32(s.Substring(s.Length - 2)) , (m_DataTable.Rows(0) ("Limit")) are valid Integers

Test12345
  • 1,625
  • 1
  • 12
  • 21
0

Ok, I think I figured it out. The "Limit" column at row 0 was null, so it was not able to execute that line. Still not sure why it didn't show any error messages and just skipped backwards though.

0

Sounds like the assemblies and the source code are out of sync. Have you changed the config (Release|Debug) or maybe not built, or build to the wrong location?

BanksySan
  • 27,362
  • 33
  • 117
  • 216
0

The Form.Load event has some odd exception handling behavior on x64 systems compared to x86 when a debugger is attached. When an exception is unhandled in a x86 process running on an x64 version of Windows the function is basically aborted, and the exception is eaten by the wow64 sub-system. Execution resumes at the last .net code on the stack before Load was called.

See this answer for a very thorough explanation.

Bradley Uffner
  • 16,641
  • 3
  • 39
  • 76
  • I am running in 64 bit, so that would probably explain it. What you are describing is exactly what is going on. I figured out that the data table cell I was reading was null, and that was the unhandled exception part that threw it back. –  Jul 26 '17 at 16:45
  • Yeah, it's *very* confusing the first time you encounter the behavior. Whenever I work in `.Load` event handlers, I always try to remember to turn on Visual Studio's "Break on all exceptions" setting. If I forget about it, I usually end up debugging problems that don't actually exist until I remember what is going on. – Bradley Uffner Jul 26 '17 at 16:56
  • I'll probably start doing that as well. Thanks! –  Jul 26 '17 at 17:58