0

Below is my code and I am having an issue where when you put a decimal to move to the next octet of the ip you can't put another decimal so instead of putting 10.10.10.10 you can only do 10.10 it doesn't allow you to put another decimal to continue on. It does work where you can't put any letters in I just can't get it to allow multiple decimals.

    Private Sub Ip_TextChanged(sender As Object, e As TextChangedEventArgs) Handles _ip.TextChanged
        If sender.Text <> String.Empty Then
            Dim TypedNumber As String = sender.Text
            Dim NumberRegex As String = "^[0-9]*\.?[0-9]*$"
            If Not System.Text.RegularExpressions.Regex.Match(TypedNumber, NumberRegex).Success Then
                sender.Text = sender.Text.Remove(sender.Text.Length - 1, 1)
                sender.SelectionStart = sender.Text.Length
            End If
        End If
    End Sub

Any help is appreciated! Thanks, Kyvex.

  • 1
    Your whole pattern is optional and would allow at max 0+ digits, a comma and 0+ digits. Perhaps [this page](https://www.regular-expressions.info/ip.html) about matching an ip might be helpful. – The fourth bird Apr 09 '19 at 16:07
  • This question is different because it is a different language it's vb.net not C#. So therefore you saying my question is a duplicate is irrelevant. Thanks. –  Apr 09 '19 at 18:52
  • @Kyvex - what is the code supposed to do? – dbasnett Apr 09 '19 at 19:32

1 Answers1

1

The question mark is qualifying "zero or more" dots, not octects, so I think multiple dots would have to be consecutive for them to be allowed. To fix that part, you would need to group the decimal identifier with the . to get something more like this:

^([0-9]*\.)?[0-9]*$

That being said, for an IP address pattern, that's probably still a bit too flexible, because you're allowing any number of decimal numbers in an octect, so to support an IP address pattern and the various iterations leading up to it, I think you might want a pattern something like this:

^([0-9]{1,3}\.){0,3}[0-9]{0,3}$

NOTE: That still allows for some invalid octect values (e.g. 999), but I think it would at least allow a user to enter the value key-by-key.

To offer a bit of editorializing (without knowing your situation, so take with a grain of salt), I would suggest giving some thought to the user experience of this approach. As a user it can be frustrating if entry controls don't behave as one normally expects, and sometimes it can be less invasive to display a validation error with some guidance rather than restricting the normal behavior of a standard control. It's hard to predict what behavior is "normal" for a user, and if your control prevents them from reaching a valid end point because they went about it in an unconventional manner, it can cause frustration.

ETA: I've edited the second pattern in response to a comment (good catch!), but I also wanted to note that I think that illustrates a broader point. My revised pattern probably still has some unintentional problems, but the broader point is that it's going to be difficult to not only get the pattern to work properly for the desired end-result, but also for the various iterations which may be used to reach the end result.

Steven
  • 1,260
  • 9
  • 22