Excel crash when typing open parenthesis Excel crash when typing open parenthesis vba vba

Excel crash when typing open parenthesis


You don't even need the With block. Any attempt to type ( after the class name takes Excel down.

The problem is that you have the VB_PredeclaredId set to true and the default member is trying to return itself. When you attach a debugger to the dying Excel instance, you can see that the underlying issue is a stack overflow:

Unhandled exception at 0x0F06EC84 (VBE7.DLL) in EXCEL.EXE: 0xC00000FD: Stack overflow (parameters: 0x00000001, 0x00212FFC).

When you type With TestCrashClass(, what happens is that VBA starts looking for an indexer on the default property, because Init() doesn't have any properties. For example, consider a Collection. You can use the default property's (Item) indexer like this:

Dim x As CollectionSet x = New Collectionx.Add 42Debug.Print x(1)   '<--indexed access via default member.

This is exactly equivalent to Debug.Print x.Items(1). This is where you start running into problems. Init() doesn't have parameters, so VBA starts drilling down through the default members to find the first one that has an indexer so IntelliSense can display the parameter list. It starts doing this:

x.[default].[default].[default].[default].[default]...

In your case, it's creating an infinite loop because [default] returns x. The same thing happens in the Collection code above (except it finds one):

IntelliSense on open parens

Throw in the fact that you have a default instance, and the end result is something like this:

Private Sub Class_Initialize()    Class_InitializeEnd Sub


As @TimWilliams points out, having a default member that returns an instance of the same class (or a class loop eg. ParentClass.ChildClass.ParentClass.ChildClass... where ParentClass and ChildClass both have default members), and when used in certain syntax cases, such as a With block, will cause VBE to try and resolve the default member.

The first parenthesis makes VBE assume there must be a method, indexed get or array index that will take an argument, so it sets off to resolve the ultimate target member.

So the incomplete line, with a cursor located after the parenthesis:

With TestCrashClass(

Is effectively the same as:

With TestCrashClass.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init.Init '....You're inquisitive scrolling this far over, but you get the point.

At some point, your system or VBE runs out of resources and exits with the grace and poise of a thermonuclear group-hug.

+1 for improvising with a copy/pasta of a parentheses pair.


Sounds like some sort of corruption. I've had Excel behave irrationally like this before, normally in large projects, and the only way to get around it is to drag all of your classes etc into a new project.

I suspect it happens because Excel doesn't truly delete classes, modules, worksheets etc that have been removed. You can tell this because of the file size.

There is no Compact and Repair functionality, as in Access, as far as i'm aware