Runtime Error 361: “Can't load or unload this object,” explained and fixed
Error 361, “Can't load or unload this object”, fires when a Load or Unload statement names a form or control whose state cannot be changed in that way. The object might already be loaded (for Load), not loaded (for Unload), be a control that was created at design time without a control array, or be one of the objects VBA does not allow code to load at all. It is a state and design bug: the statement is legal Visual Basic aimed at an object in the wrong condition.
For people who just run the program
- This is a message for the program's maintainer. End users meet error 361 when a packaged VB/VBA program mismanages its windows or controls; nothing about the document or data causes it.
- Note which window or action was involved. Opening a second copy of a window, closing one that never opened, or repeating an action quickly are the classic triggers; the action identifies the object.
- Restart the program if windows are left in odd states. A failed load or unload can leave the program's window bookkeeping inconsistent, and a restart is the clean reset.
- Pass on the error number and the action. The number tells the developer the exact family of mistake; the action tells them which object.
For people who write the code
- Track loaded state instead of assuming it. Keep a flag or check the Forms collection before Load, and only Unload forms your code loaded. The default instance of a form adds a wrinkle: referencing it loads it implicitly, which confuses hand-rolled state tracking.
- Control arrays are required for Load on controls.
Load can only create new elements of a control array (a control with an Index property set at design time). Loading a plain control raises error 361; design the prototype element with Index = 0.
' txtField(0) exists at design time with Index = 0
Load txtField(1) ' creates the second element
txtField(1).Visible = True
Unload txtField(1) ' removes it again
' Load txtSingle ' error 361: not a control array element
- Do not Unload from inside every event. Unloading a form from within one of its own control's events, while other events for that form are queued, produces state errors of this family. Set a flag, let the event finish, and unload from a safe point.
Showing a form is not loading it in the sense Load means. Mixing the two models, sometimes Showing the default instance, sometimes Loading instances, is how state bookkeeping drifts until error 361 appears. Pick one model per form and be consistent.
If it still happens
If state checks look right, look for the object being a special case: MDI children, forms shown modally, and objects owned by the host (such as document windows in Office) each have their own restrictions on load and unload. The object's own documentation, not general VBA rules, decides what is allowed.
Common questions
What is the difference between Load and Show for a form? Load creates the form in memory without displaying it; Show loads it if needed and then displays it. Error 361 concerns the Load and Unload statements themselves and the object's eligibility for them.
Why can some controls not be loaded at run time? Because dynamic creation is limited to elements of control arrays defined at design time. A control without an Index cannot be cloned with Load; the design must provide the array prototype.
Related errors