It becomes trickier to troubleshoot routines which you set up to fire automatically (i.e., on "events"). That is where breakpoints come in.

Set a breakpoint at the top of your "OnExit" routine. When that routine fires (or fails to fire) as you expect, you will jump to the VBA window, ready to step through the routine (using F8).

Collectively I think of it as "Step through" although, "Step Into" is the official name for what F8 does. There are a number of variations. You might not need to step through every line of your code, because some parts of it work and some parts of it don't, but that's what I'd suggest to start with. You can explore the concepts of "Step out of" and "Step Over" and "Run to this line" later.

When you say there are no errors in your code, but it doesn't appear to do what you need it to do: that is an error.

However, it is an error that only you can fix. Because Microsoft is doing exactly what you told it to do. So you have to tell it something different.

I'm trying to help you help yourself on how to troubleshoot this kind of stuff.

For example, if you put your cursor on the line which says "Private Sub Document_ContentControlOnExit..." line, and hit F9, you will see a deep red line appear.

Now, if you go use your document, changing a content control and expecting this code to trigger...but you never jump to the VBA window, you know your event isn't even "firing."

So you may need to restart Word (I'm not sure when Content Control events become corrupt in Word 2010).

But if it is firing... then you can use F8 to go step-by-step through your code and see what code you wrote that you *expect* to be triggered by the conditions which existed when this whole routine started.

When the logic your wrote doesn't match up with what you expect... you are well on your way to adjusting.

Breaking it in to smaller bits will make the entire troubleshooting experience feel less overwhelming.

And that's what setting breakpoints will help you to see.