Какие-либо накладные расходы на избыточную настройку свойств Control?

Question

Я имею дело с большим количеством кода, который выглядит следующим образом:

 if (btnLeftDock.BackColor != SystemColors.ButtonFace)
 {
    btnLeftDock.BackColor = SystemColors.ButtonFace;
 }
 if (btnRightDock.BackColor != SystemColors.ButtonFace)
 {
    btnRightDock.BackColor = SystemColors.ButtonFace;
 }
 if (btnTopDock.BackColor != SystemColors.ButtonFace)
 {
    btnTopDock.BackColor = SystemColors.ButtonFace;
 }
 if (btnBottomDock.BackColor != SystemColors.ButtonFace)
 {
    btnBottomDock.BackColor = SystemColors.ButtonFace;
 }

Единственная причина, по которой я могу себе это представить, заключается в том, что теоретически есть некоторые накладные расходы, специфичные для winforms, для установки управляющих цветов, например так:

 btnLeftDock.BackColor = SystemColors.ButtonFace;
 btnRightDock.BackColor = SystemColors.ButtonFace;
 btnTopDock.BackColor = SystemColors.ButtonFace;
 btnBottomDock.BackColor = SystemColors.ButtonFace;

Я думаю, что это намного легче читать, и я не вижу никакой разницы в производительности, но первоначальный разработчик должен имел какое-то оправдание. (Правильно?)

Answer 1

В свойстве BackColor есть что-то особенное, это окружающее свойство . Это означает, что если свойство было присвоено никогда , то BackColor элемента управления будет таким же, как и значение BackColor родителя.

Это очень желательно, он обеспечивает автоматическое согласование значений цвета фона. Если родитель изменяет свой BackColor, то все дочерние элементы управления также меняют его на одно и то же значение. Пока они сами не назначали это.

Это могло бы немного парализовать первоначального автора. Но так как он использовал системные цвета, тест не должен быть необходимым. Я думаю.

Answer 2

Это кнопки, верно?

Вы должны обнаружить, что BackColorChanged не запускается, поэтому я не могу представить никаких функциональных побочных эффектов, которых первоначальный разработчик пытается избежать.

Нажмите, чтобы подтолкнуть:)

Answer 3

Глядя на код от рефлектора, кажется, что есть небольшое преимущество в производительности.Ничего существенного, хотя;таким образом, я лично не стал бы беспокоиться о проверке, если бы избыточный набор не был определен как узкое место.В частности, обработчик OnBackColorChanged будет не выполняться на избыточном наборе.

---

public override Color BackColor
{
    set
    {
        if (base.DesignMode)
        {
            if (value != Color.Empty)
            {
                PropertyDescriptor descriptor = TypeDescriptor.GetProperties(this)["UseVisualStyleBackColor"];
                if (descriptor != null)
                {
                    descriptor.SetValue(this, false);
                }
            }
        }
        else
        {
            this.UseVisualStyleBackColor = false;
        }
        base.BackColor = value;
    }
}

, где base.BackColor, определенное для System.Windows.Forms.Control:

public virtual Color BackColor
{
    set
    {
        if ((!value.Equals(Color.Empty) && !this.GetStyle(ControlStyles.SupportsTransparentBackColor)) && (value.A < 0xff))
        {
            throw new ArgumentException(SR.GetString("TransparentBackColorNotAllowed"));
        }
        Color backColor = this.BackColor;
        if (!value.IsEmpty || this.Properties.ContainsObject(PropBackColor))
        {
            this.Properties.SetColor(PropBackColor, value);
        }
        if (!backColor.Equals(this.BackColor))
        {
            this.OnBackColorChanged(EventArgs.Empty);
        }
    }
}

Answer 4

Я подозреваю, что установка визуального свойства, такого как BackColor, приведет к тому, что элемент управления станет недействительным как причина для этого (хотя все еще немного ошибочно). Таким образом, еще лучшим решением будет просто сгруппировать эти изменения между BeginUpdate() и EndUpdate() вызовами, что приведет к одной недействительности независимо от того, что вы делаете.