Runtime Error 446: “Object doesn't support named arguments,” explained and fixed

Error 446, “Object doesn't support named arguments”, fires when a call uses VBA's named-argument syntax, Method Name:=value, against an object whose methods do not accept names. Named arguments are a VBA convenience resolved through the called object's type information; many Automation objects, especially those from libraries designed without VBA in mind, expose methods callable only positionally. The arguments themselves may be perfect; the naming is what the object cannot process.

For people who just run the program

  1. This is a code defect, not a data or settings issue. It appears where macros call into another program's objects with the tidy named-argument style those objects do not support.
  2. Note the feature in use. The feature maps to the specific external method being called with named arguments.
  3. Nothing about the document matters. The same call fails on every document and succeeds on none until rewritten positionally.
  4. Report the number. 446 gives the maintainer an exact, mechanical fix: rewrite the call with positional arguments.

For people who write the code

  1. Rewrite the call positionally, in documented order. Supply every argument up to the last one needed, using commas to skip optional positions:
    2. ' obj.Save FileName:="out.dat", Mode:=2     ' error 446 on strict objects
obj.Save "out.dat", 2                        ' positional: works
obj.Save "out.dat", , True                   ' skipped middle argument
  2. Know which libraries are positional-only. Objects reached through late binding to certain COM libraries, and many objects from non-Microsoft vendors, cannot resolve argument names. When a vendor's examples all show positional calls, that is the tell.
  3. Keep named arguments for VBA's own and Office's objects. They are fully supported there and genuinely improve readability. The discipline is per-library: match the call style to what the object's documentation demonstrates.
Error 446 can hide inside copied example code. Examples written for one host or version (where the object accepted names) get pasted into projects driving a stricter build of the same object. When a “known-good” example fails with 446, the call style, not the example's logic, is the difference.

If it still happens

If positional rewriting still fails with argument errors, verify the parameter order against the installed version's documentation: reordered parameters across versions present as wrong-value bugs, not 446, and quietly corrupt results instead of failing. Match the signature of the version actually referenced.

Common questions

What are named arguments? A VBA call style that labels each argument with its parameter name, like Show(Name:="x"). They improve clarity and allow out-of-order arguments, but require the called object to support name resolution.

Does late binding cause error 446? It can contribute: with an Object-typed variable, VBA resolves the call at run time through the object's interface, and objects that only support positional invocation reject the names there. Early binding to the same library often restores named arguments when the type library supplies them.

Related errors

Runtime Error 448 · Runtime Error 445 · Runtime Error 449