C# – Is SuspendLayout/ResumeLayout worthless or am I going about it wrong

Following on from verminity's answer you do have one option:

Use the following class

public class SuspendAwareTreeView : TreeView    
{
    public readonly T RealControl;
    private int suspendCount;

    public bool IsSuspended 
    { 
        get { return suspendCount > 0; }
    }

    public Suspendable(T real) { this.RealControl = real; }

    public void SuspendLayout() 
    { 
        this.suspendCount++;
        this.RealControl.SuspendLayout();
    }

    public void ResumeLayout() 
    { 
        this.RealControl.ResumeLayout();
        this.suspendCount--;
    }
}

Then use this class for everything internally where you need to suspend it.

Obviously this won't work if you ever pass the class around to something that only expects a control or if something else outside your control sets it.

If this is the case you would be forced to go with a variety of less than pleasant solutions:

• Write a new User control which wraps the TreeView and defers all calls to it but maintains the suspended state.
  • the resulting instance is no longer "is-a TreeView" which will cause problems.
  • maintenance effort possibly high.
  • if for some reason the treeview ever decided to suspend itself this will break.
  • new version of the runtime unlikely to break anything, you simply won't gain new functionality without effort.
• Implement an entirely new TreeViewEx which exposes this state
  • the resulting instance is no longer "is-a TreeView" which will cause problems.
  • maintenance effort possibly high
  • can never break since you have total control, can diverge from original though
  • new version of the runtime unlikely to break anything, you simply won't gain new functionality without significant effort (possibly in violation of the law/EULA).
• Violate Encapsulation
  • No alteration fo the type system, everything else continues to work.
  • Maintenance effort potentially high on runtime change
  • apps will break if the runtime changes underneath them

For your needs if and only if you control the runtime versions this operates on entirely (i.e. a controlled corporate environment) the following evil but effective hack is appropriate. So long as you test any time you upgrade it may well keep working with little effort.

public class ControlInvader
{
  private static readonly System.Reflection.FieldInfo layoutSuspendCount = 
      typeof(Control).GetField("layoutSuspendCount",
          System.Reflection.BindingFlags.Instance | 
          System.Reflection.BindingFlags.NonPublic);

  private readonly Control control;        

  public bool IsSuspended 
  {
    get 
    {
      return 0 != (byte)layoutSuspendCount.GetValue(this.control);
    }
  }

  public Suspendable(Control control) { this.control = control; }     
}

Attach this to your TreeView and then you can inspect the value whenever you like.

To reiterate this is fragile and entirely inappropriate for an environment where the version of the underlying runtime is not strictly controlled and where you can handle possible significant efforts to fix this on a breaking change. You would do well to include a static initializer which checks if the field actually existed and was the right type and aborted if not.

We've seen this problem too.

One way we've seen to "fix" it is to completely suspend drawing of the control until we're ready to go. To accomplish this, we send the WM_SETREDRAW message to the control:

// Note that WM_SetRedraw = 0XB

// Suspend drawing.
UnsafeSharedNativeMethods.SendMessage(handle, WindowMessages.WM_SETREDRAW, IntPtr.Zero, IntPtr.Zero);

...

// Resume drawing.
UnsafeSharedNativeMethods.SendMessage(handle, WindowMessages.WM_SETREDRAW, new IntPtr(1), IntPtr.Zero);