I’ve run into similar weird debugging slowdowns with VBA classes that have VB_PredeclaredId = True, so let’s break down what might be happening and how to fix it:

Possible Causes #

1. Predeclared Instance State Bloat: Your Create method modifies and returns the predeclared instance of WeekSchedule (via Set Create = Me). Every time you call DaySchedule.Create(), you’re overwriting the same global instance’s properties. Over time, this might cause Excel’s debugger to struggle with tracking the instance’s state, even if CPU usage looks low.
2. Hidden Property Getter Logic: If any of your class’s properties (like me_Monday, me_Name, etc.) have hidden Get procedures that run code when accessed, the Locals window will trigger those getters for every member it displays. Even lightweight code can add up if the debugger is iterating through many members repeatedly.
3. Excel Debugger Cache Corruption: Sometimes the VBA debugger’s internal cache gets glitched after prolonged debugging sessions, leading to unexpected slowdowns even with unchanged code.

Solutions to Try #

1. Return a New Instance Instead of the Predeclared One #

The biggest red flag here is modifying and returning the predeclared instance. Instead, create a fresh WeekSchedule object in your Create method:

Public Function Create( _
ByVal Name As String, _
ByVal Cycle As Long, _
ByVal Prio As Long, _
ByVal startDate As Date, _
ByVal WeekDays As String) As WeekSchedule
    Dim newSchedule As New WeekSchedule
    Dim WeekDays_Arr() As String
    Dim Days As Variant
    
    ' Reset properties on the NEW instance
    With newSchedule
        .Monday = False
        .Tuesday = False
        .Wednesday = False
        .Thursday = False
        .Friday = False
        .Saturday = False
        .Sunday = False
        
        WeekDays_Arr = Split(WeekDays, ";")
        For Each Days In WeekDays_Arr
            Select Case Days
                Case "Mo": .Monday = True
                Case "Tu": .Tuesday = True
                Case "We": .Wednesday = True
                Case "Th": .Thursday = True
                Case "Fr": .Friday = True
                Case "Sa": .Saturday = True
                Case "Su": .Sunday = True
            End Select
        Next Days
        
        .ScheduleType = "weekly"
        .Name = Name
        .Cycle = Cycle
        .Prio = Prio
        .StartDate = startDate
    End With
    
    Set Create = newSchedule
End Function

This way, each Create() call returns a clean, independent instance, and the predeclared instance stays untouched. This almost always fixes debugger slowdowns related to reused predeclared objects.

2. Check for Hidden Property Code #

Double-check your WeekSchedule class module for any Property Get procedures you might have added for those me_* members. For example, if you have something like:

Public Property Get Monday() As Boolean
    ' Hidden logic here, like reading from a worksheet or calling another function
    Monday = me_Monday
End Property

Even trivial extra code in these getters can cause the Locals window to lag as it fetches every property value. If possible, make these members public fields instead of properties, or ensure the getters are completely minimal.

3. Reset the VBA Debugger #

• Close and reopen Excel entirely. This clears the debugger’s internal cache and often resolves random slowdowns that don’t have an obvious code cause.
• If closing Excel isn’t an option, try resetting the VBA project: go to the VBA Editor > Run > Reset. This stops any running code and resets the project state.

4. Test with Simplified Inputs #

Try calling Create() with a minimal WeekDays value (e.g., "Mo") instead of a long list. This helps rule out any issues with the Split/loop logic accidentally creating unexpected state in the instance.

内容的提问来源于stack exchange，提问作者Yannic Nöhring