Працюючи з WPF, мене сильно цікавило застуосування унаслідуваних (Inherits) пропертей (особливо в світлі того наскільки "дорогі" біндінги (Binding)),

... >>>

Довелось мені писати маленький тестовий сампл для WPF. В неймспейсі самплу додав кастомний клас і захотів відобразити його на формі. За старою звичкою роботи з контролами прописав, щось типу такого
xmlns:local="clr-namespace:WpfApplication1;assembly=WpfApplication1"
Далі мене чекало велике розчарування.
... >>>

Минулої п’ятниці мені вдалося побувати на конференції присвяченій підходу керування - Скрам (SCRUM) яка є одним із під напрямків Аджайлу (Agile). Я викладу кілька моїх думок з цього приводу.

... >>>

... >>>

... >>>

Стикнувся якось при використанні AjaxControlToolkit з вищенаведеним exception-ом. Причому з*являвся невідомо через що і пофіксати можна було єдиним способом: 1) скопіювати зміни кудись наліво 2) відновити з репозиторію і скопіювати зміни назад - і о чудо все працює! :)...

 

Але врешті решт і цей спосіб відмовив, тож довелося цю проблему добряче погуглити. Спочатку на Кодеплексі (www.codeplex.com) сказали що це не проблема їхнього контрола і самого АЯКС-а. Поліз на аяксівський форум - там взагалі якись безпорядок, одні кажуть шо це фіксається через Ctrl+F5, інші шо проблема з 7-м експлорером, ше дехто знайшов взагалі якийсь воркераунд де треба вставляти на сторінку панельку а на неї ше щось. і т.д.  Ясно шо нічого з того так не допомогло.

 

Так от тільки що знайшов в чому проблема: сторінки які з часом відмовляли були в мене переключені в режим Trace. Напевно АЯКС з таким не дуже дружить. Отже ставлю директиву на сторінці Trace=false -> refresh = опля, все гуд!. Міняю назад - теж гуд, чудасія :).

В багатьох класах, що наслідуються від FrameworkElement є така корисна пропертя як *TemplateSelector типу DataTemplateSelector. В неї можна підставити свій клас, що наслідується від DataTemplateSelector і переписати метод SelectTemplate(). Це дозволить на ходу генерувати темпліти для контенту елемента. Дані в цей метод можна отримати елементарними біндігами. А тепер особливість: можна писати всі біндігни (навіть ті що посилаються на ElementName), крім TemplateBinding, тобто щоб RelativSourceMode не був рівний TemplatedParent.

In the many inherited from FrameworkElement contain a useful dependency property *TemplateSelector type of DataTemplateSelector. It can set our inherit from DataTemplateSelector class and override the method SelectTemplate(). This allow dynamic generate template for a content. Content-data we can get a elementary binding. And now feature: we can use all binding (even that what refet to ElementName), except TemplateBinding, therefore RelativSourceMode doesn't equal TemplatedParent.

Нам потрібно виставити свої стилі і шаблони для для елементів, якими наповнюються контроли наслідувані від абстрактного класу Selector (до них належить стандартні ComboBox, ListBox, TabControl).
Це можна зробити двома шляхами.
1) В ресурси самого контрола внести стилі і шаблони айтемів. Це трохи незручно. З цих стилів і шаблонів нічого не можна буде "побачити" за межами ресурсів "батьківського" контрола.
2) Використати віднаслідувану від Selector`a пропертю ItemContainerStyle - внести в неї значення по ключу статичного ресурса.

PS: Зручність другого способу особливо помітна при написанні контролів, коли для кастомізації айтема потрібна інфа з-за меж "батьківського" ресурсу.

We need set own custom style or template for item of control which was inheritance from abstract class 'Selector' (for example: ComboBox, ListBox, TabControl)
We can use two way:
1) We can add in control's resource some style and template. But it isn't good way, because these styles and templates have access only in boundary of control.
2) We can use inheritance from Selector ItemContainerStyle dependency property and set in it new style value.

Іноді нам доводиться використовувати кілька малті дата трігерів, де один із біндінгів у всіх трігерах одинаковий. Як показує практика краще його писати останнім в списку біндінгів, в іншому випадку він не завжди спрацьовує. Для іниших видів малті трігерів вище написане не перевірялось, хоча навряд відрізняєтсья..

Sometimes we will be use a few MultiDataTrigger and them contain one identical binding. As practice shows better way is write identical binding to last in the list of condition, in other case MultiDataTrigger works not always. For the other types of MultiTriggers the it was unchecked, although scarcely it isn't identical..

Іноді виникає потреба покастомайзити один чи кілька кольорів контролу. За умови, що шаблон недоступний (чи тяжко доступний) і якщо там використовуються сисетмні кольори, для кастомізації можна застосувати такий "обхідний маневр". Приклад для ліст-бокса.

Sometime we need custom one or more brush of control. If template is not available and in base template used system brush, we can use this workaround (example for ListBox):

<ListBox>
  <ListBox.Resources>
    <SolidColorBrush x:Key="{x:Static SystemColors.HighlightBrushKey}" Color="Maroon" />
    <SolidColorBrush x:Key="{x:Static SystemColors.ControlBrushKey}" Color="Maroon" />
    <SolidColorBrush x:Key="{x:Static SystemColors.HighlightTextBrushKey}" Color="White" />
    <SolidColorBrush x:Key="{x:Static SystemColors.ControlTextBrushKey}" Color="White" />
  </ListBox.Resources>
  <ListBoxItem>blah-blah</ListBoxItem>
  <ListBoxItem>blah-blah</ListBoxItem>
  <ListBoxItem>blah-blah</ListBoxItem>
</ListBox>