Inputbox vba ошибка

Sub InputBox()

That procedure is implicitly Public. Presumably being written in a standard module, that makes it globally scoped.

Link = InputBox("give me some input")

This means to invoke the VBA.Interaction.InputBox function, and would normally succeed. Except by naming your procedure InputBox, you’ve changed how VBA resolves this identifier: it no longer resolves to the global-scope VBA.Interaction.InputBox function; it resolves to your InputBox procedure, because VBAProject1.Module1.InputBox (assuming your VBA project and module name are respectively VBAProject1 and Module1) are always going to have priority over any other function defined in any other referenced type library — including the VBA standard library.

When VBA resolves member calls, it only looks at the identifier. If the parameters mismatch, it’s not going to say «hmm ok then, not that one» and continue searching the global scope for more matches with a different signature — instead it blows up and says «I’ve found the procedure you’re looking for, but I don’t know what to do with these parameters».

If you change your signature to accept a String parameter, you get a recursive call:

Sub InputBox(ByVal msg As String)

That would compile and run… and soon blow up the call stack, because there’s a hard limit on how deep the runtime call stack can go.

So one solution could be to properly qualify the InputBox call, so that the compiler knows exactly where to look for that member:

Link = VBA.Interaction.InputBox("give me some input")

Another solution could be to properly name your procedure so that its name starts with a verb, roughly describes what’s going on, and doesn’t collide with anything else in global scope:

Sub TestInputBox()

Another solution/work-around could be to use a similar function that happens to be available in the Excel object model, as QHarr suggested:

Link = Application.InputBox("give me some input")

This isn’t the function you were calling before though, and that will only work in a VBA host that has an InputBox member on its Application class, whereas the VBA.Interaction.InputBox global function is defined in the VBA standard library and works in any VBA host.

A note about this:

If Link <> "" Then

This condition will be False, regardless of whether the user clicked OK or cancelled the dialog by «X-ing out». The InputBox function returns a null string pointer when it’s cancelled, and an actual empty string when it’s okayed with, well, an empty string input.

So if an empty string needs to be considered a valid input and you need to be able to tell it apart from a cancelled inputbox, you need to compare the string pointers:

If StrPtr(Link) <> 0 Then

This condition will only be False when the user explicitly cancelled, and will still evaluate to True if the user provided a legit empty string.

Instead of using the InputBox function, another approach would be to use the InputBox method of the Application object, which contains built-in error handling.

Sub Inputbox_Clarity()
    Dim feeding As Variant
    feeding = Application.InputBox("Enter a number >= 1000 and <= 3000", "Number", Type:=1)
    If feeding = False Then Exit Sub
    If feeding < 1000 Or feeding > 3000 Then Exit Sub
    ActiveSheet.Range("A100") = feeding
End Sub

Alternatively, you can use a Do/Loop to continue prompting for a valid number or until the Cancel button is pressed.

Sub Inputbox_Clarity()
    Dim feeding As Variant
    Do
        feeding = Application.InputBox("Enter a number >= 1000 and <= 3000", "Number", Type:=1)
        If feeding = False Then Exit Sub
    Loop While feeding < 1000 Or feeding > 3000
    ActiveSheet.Range("A100") = feeding
End Sub

Hope this helps!

A common requirement in VBA programs is to display an input box, and get the
user to type in an integer.  Here is a routine which will allow you to do
just that:

Here is how you could call this routine to get a whole number (integer), then
display its square:

When you run the SquareNumber routine, if you enter text
into the input box it will trigger an error and pass control to the
NotInteger label.  This in turn will set the value of the function
to -1.

You will then see an error message like this:

This is a typical use of error trapping:

• We know we are about to do something which sometimes won’t
  work;
• We set an error trap giving a label to jump to in the event
  of an error;
• We run the code, secure in the knowledge that it will do the
  right thing whether or not the user reacts in the correct way.

That’s pretty much the complete story about error-trapping, but
error-trapping aficionados might like to read the final part of this series, in
which you can raise your own errors and learn how error messages bubble up
through the call stack!