Runtime Error 450: “Wrong number of arguments or invalid property assignment,” explained and fixed

Error 450, “Wrong number of arguments or invalid property assignment”, covers two distinct faults sharing one number. The first is a call whose argument count matches no valid form of the procedure: too many, or too few in a way error 449 does not claim. The second is a property assignment made with the wrong mechanism: assigning a value to a property that needs Set, an object to one that needs Let, or assigning to a property through the wrong member entirely. Read the failing statement and ask which of the two it is; the fixes have nothing in common.

For people who just run the program

  1. This is a code defect at one specific statement. Either a call or a property assignment is malformed for the object it targets; no document state is involved.
  2. Note the feature and recent changes. Error 450 often follows an edit to a shared routine's signature, or a library upgrade that changed a property's type from value to object (or back).
  3. Nothing to retry. The statement is wrong the same way on every run.
  4. Report the number and the feature. The maintainer needs to see one line; the number tells them the two shapes to look for.

For people who write the code

  1. Classify the statement first. If it is a call, count arguments against the real signature (including whether the procedure is a Sub being called with parentheses around a single argument, which passes it ByRef-evaluated and can mimic a count error). If it is an assignment, check Let versus Set:
  2. Dim c As Collection
    ' c = New Collection        ' invalid assignment: object needs Set
    Set c = New Collection        ' correct
    ' name = obj.Name           ' value property: Let (implicit) is correct
  3. Parentheses change meaning in calls. Foo (x) with a space evaluates x as an expression argument; Foo(x) as a Sub call is a syntax problem, and as a Function misused can surface as 450. Write calls deliberately: Call keyword, or no parentheses for Subs.
  4. For library properties, verify which assignment the version wants. A property that held a string in one version and an object in the next flips the required assignment form; code that kept the old form raises 450 against the new library.
Because 450 merges two causes, fixing “the arguments” on an assignment problem wastes hours. The statement's shape decides the cause: an equals sign points at the assignment half; a procedure name with a parameter list points at the count half. Start there.

If it still happens

If the count and the assignment form both look right, the callee being resolved may not be the one on screen: same-named procedures in different modules, or a property on a base interface shadowing the intended one. Qualify the name fully and use the Object Browser to confirm which definition the project binds.

Common questions

Why does one error number cover two faults? Because both are call-shape errors detected by the same part of the runtime: the machinery that matches a call or assignment against a member's signature. The message honestly lists both possibilities; the statement tells you which occurred.

Can too many arguments really be worse than too few? Both are rejected. VBA has no mechanism to ignore extra arguments; a call must match a declared signature, with Optional parameters and ParamArray providing the only flexibility.

Related errors

Runtime Error 449 · Runtime Error 448 · Runtime Error 35