WPF Что происходит, когда ширина дочернего элемента привязана к фактической ширине родительского элемента?

Question

Так что, если у меня есть привязка на ширину дочернего объекта, который связывает его с родительским объектом ActualWidth, что случится?

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

Однако это предполагает, что привязка распространяется не так быстро. Я все еще не могу понять, когда значение привязки распространяется на цель. Все зависит от того, когда изменяется значение фактической ширины родителя. Это происходит после завершения макета? а потом связанные кусочки обновлять? Каждое связывание прерывает текущий запущенный код, чтобы обновить целевое значение? если нет, не вызовет ли это проблемы, если одна привязка распространяет изменение, которое требует перерисовки, тогда другая привязка распространяет другое изменение, которое вызывает перерисовку и т. д.

Некоторые люди спрашивали, какова была моя настоящая проблема:

Поэтому изначально я хотел иметь контрольный участок для заполнения доступного пространства. Достаточно просто, но я хотел, чтобы это было в окне прокрутки. Scrollviewer дает бесконечное пространство своим детям во время измерения. Таким образом, вместо этого вы можете привязать ширину и высоту дочернего элемента управления к фактической ширине и реальной высоте родителя; макет делает второй проход, и все кажется вздутым.

Однако позже у меня возникли проблемы подобного типа растягивания элемента управления в шаблоне элемента управления, но затем я обнаружил, что могу установить минимальную ширину и выравнивание = растяжение, чтобы растянуть его.

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

Так что теперь я использую привязку для одного и метод minwidth плюс выравнивание для другого. В любом случае, это было интересно только для того, чтобы убедиться, что то, как я работаю, не вызовет странных ошибок позже.

Я надеюсь, что макет не запускается сразу при изменении ширины или высоты, а вместо этого система периодически проверяет изменения размера

Answer 1

Согласно перечислению DispatherPriority, DataBinding происходит раньше Rendering,

• послать
• Нормальный - Конструкторы бегут здесь
• DataBind
• оказывать
• нагруженный
• Фон
• ContextIdle
• ApplicationIdle
• SystemIdle
• Неактивный
• Недействительным
• вход

Таким образом, привязка будет пытаться оценить сначала, прежде чем произойдет рендеринг

Однако рендеринг может привести к обновлению привязки, поэтому, если процесс рендеринга родительской панели увеличит ширину панели (например, родительская панель, помещенная внутри другой панели, автоматически растягивает дочерние элементы, чтобы занять 100% пространства. как Grid или последний элемент в DockPanel), то это вызовет обновление привязки и увеличит ширину дочернего элемента во время цикла рендеринга.

Вторая часть этого SO ответа также может помочь вам понять. Обратите внимание на № 6 тоже.

Последовательность событий, когда окно создано и показано

Как и было запрошено, вот последовательность основных событий в WPF при создании и отображении окна:

1. Конструкторы и геттеры / сеттеры вызываются при создании объектов, включая PropertyChangedCallback, ValidationCallback и т. Д. Для обновляемых объектов и любых объектов, которые наследуются от них.

2. Когда каждый элемент добавляется в визуальное или логическое дерево, запускается его инициализированное событие, что приводит к тому, что стили и триггеры применяются в дополнение к любой специфичной для элемента инициализации, которую вы можете определить [примечание: инициализированное событие не запускается для листьев в логическом дереве если в его корне нет PresentationSource (например, Window)

3. Окно и все неразвернутые визуальные элементы в нем измеряются, что вызывает ApplyTemplate в каждом элементе управления, что вызывает дополнительную конструкцию дерева объектов, включая дополнительные конструкторы и геттеры / сеттеры.

4. Окно и все не свернутые визуальные эффекты на нем расположены

5. Окно и его потомки (как логические, так и визуальные) получают событие Loaded.

6. Любые привязки данных, которые потерпели неудачу при первой установке, повторяются

7. Окну и его потомкам предоставляется возможность визуально визуализировать свой контент.

Шаги 1-2 выполняются при создании окна, независимо от того, отображается оно или нет. Другие шаги обычно не выполняются до тех пор, пока не появится окно, но они могут произойти раньше, если они запускаются вручную.