Делаю UserControl, в нём TextBlock и TextBox. Помещаю его в форму. Как правильно из разметки формы, где используется мой контрол (<my:UserControl1 .../>), задать значение какому-нибудь внутреннему свойству, например TextBlock.Text?

Здравствуйте, Аноним, Вы писали:

А>Делаю UserControl, в нём TextBlock и TextBox. Помещаю его в форму. Как правильно из разметки формы, где используется мой контрол (<my:UserControl1 .../>), задать значение какому-нибудь внутреннему свойству, например TextBlock.Text?

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

В любом случае, можно сделать зависимое свойство в классе UserControl1, которое и будет устанавливаться пользователем контрола. Внутри шаблона контрола это свойство нужно привязать к свойству TextBlock.Text таким образом:

<TextBlock Text="{Binding MyProperty, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type my:UserControl1}}}" />

V>можно сделать зависимое свойство в классе UserControl1
Можно конечно, но если на каждое новое переопределяемое свойство внутреннего контрола втыкать свойство-отображение во внешний, в какого ёжика он превратится.

V>В общем и целом, UserControl-ы не предназначены для таких задач
А что предназначено? Странно, даже в пропитавшейся нафталином дельфе было доступно всё дерево свойств внутренних контролов. Точно в WPF этого не сделать? Неужели никому никогда не потребовалось для составного контрола шрифт поменять или фон подкрасить?

Здравствуйте, Аноним, Вы писали:

V>>можно сделать зависимое свойство в классе UserControl1
А>Можно конечно, но если на каждое новое переопределяемое свойство внутреннего контрола втыкать свойство-отображение во внешний, в какого ёжика он превратится.

V>>В общем и целом, UserControl-ы не предназначены для таких задач
А>А что предназначено? Странно, даже в пропитавшейся нафталином дельфе было доступно всё дерево свойств внутренних контролов. Точно в WPF этого не сделать? Неужели никому никогда не потребовалось для составного контрола шрифт поменять или фон подкрасить?

Понятно, используйте DataTemplate вместо UserControl. А у стандартных контролов, которые вы уже используете, есть свойства HeaderTemplate, или ContentTemplate, или ItemTemplate, или много других свойств оканчивающихся словом Template — вот туда и подставляйте свои DataTemplate-ы.

Здравствуйте, Аноним, Вы писали:

А>Делаю UserControl, в нём TextBlock и TextBox. Помещаю его в форму. Как правильно из разметки формы, где используется мой контрол (<my:UserControl1 .../>), задать значение какому-нибудь внутреннему свойству, например TextBlock.Text?
Если очень нужно, то просто присвой элементу имя (x:Name). Тогда он будет доступен в коде, как привятное поле твоего UserControl-а. Другое дело, что таких вещей в WPF стараются избегать, чтобы не сильно увязывать код с содержимым XAML.

>даже в пропитавшейся нафталином дельфе
Эх, воспроизвёл бы кто-нибудь для wpf парсер разметки и дизайнер как в утраченной технологии древности vcl.net...

Здравствуйте, Osaka, Вы писали:

>>даже в пропитавшейся нафталином дельфе
O>Эх, воспроизвёл бы кто-нибудь для wpf парсер разметки и дизайнер как в утраченной технологии древности vcl.net...

Kaxaml чем не устраивает? А на полноценный дизайнер лучше не рассчитывать. Ибо полноценную разметку можно получить только после компиляции.

C>Kaxaml чем не устраивает?
Попробовал посмотреть, крашится через несколько движений мышью после запуска.
C>А на полноценный дизайнер лучше не рассчитывать. Ибо полноценную разметку можно получить только после компиляции.
Хочется чтобы было как с дельфийским TFrame: разметка позволяет переопределять свойства UserControl'а на любую глубину вложенности и добавлять вложенные объекты, и без этого убийственного ограничения что xaml может быть только у последнего класса в иерархии (а так чтобы сколько угодно уровней наследования формы, и в каждом в разметке дифференс добавленных/переопределённых свойств и итемов коллекций контролов). Реализовано всё было >15 лет назад, на тогдашних компах не тормозило.

Здравствуйте, Аноним, Вы писали:

А>Делаю UserControl, в нём TextBlock и TextBox. Помещаю его в форму. Как правильно из разметки формы, где используется мой контрол (<my:UserControl1 .../>), задать значение какому-нибудь внутреннему свойству, например TextBlock.Text?

Унаследуйте ваш UserControl от какого-либо другого, схожего по поведению, все дополнительные свойства объявите как DependensyPropery и их setter'ах устанавливайте значения для ваших внутренних контролов.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Делаю UserControl, в нём TextBlock и TextBox. Помещаю его в форму. Как правильно из разметки формы, где используется мой контрол (<my:UserControl1 .../>), задать значение какому-нибудь внутреннему свойству, например TextBlock.Text?

А>Унаследуйте ваш UserControl от какого-либо другого, схожего по поведению, все дополнительные свойства объявите как DependensyPropery и их setter'ах устанавливайте значения для ваших внутренних контролов.

Прошу прощения, написал ерунду. не в setter'ах, а просто в секции set ваших свойств. Это позволит из кода вызывающего ваш контрол использовать Binding для определенных вами свойств.

А>все дополнительные свойства объявите как DependensyPropery и их setter'ах устанавливайте значения для ваших внутренних контролов.
Способ работающий, но что делать пользователю моего контрола, если надо изменить внутреннее свойство, не отображённое во внешний контрол? Писать мне письмо чтобы я выпустил новую версию?

Здравствуйте, Аноним, Вы писали:

А>если на каждое новое переопределяемое свойство внутреннего контрола втыкать свойство-отображение во внешний, в какого ёжика он превратится.
А>в пропитавшейся нафталином дельфе было доступно всё дерево свойств внутренних контролов
Да уж.

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

По идее, если вы группируете несколько элементов управления в один, они объединены общей логикой. Например, у них должен быть один и тот же размер шрифта, цвет фона, bindings должы определенным образом задаваться. Если позволить все эти свойства менять для отдельного элемента, как в Delphi, то пользователь вашего контрола легко нарушит его логику работы.

Вас же не смущает, что в шарпе члены типов и сами типы без явно заданных модификаторов доступа не являются public?

Здравствуйте, Аноним, Вы писали:

А>>все дополнительные свойства объявите как DependensyPropery и их setter'ах устанавливайте значения для ваших внутренних контролов.
А>Способ работающий, но что делать пользователю моего контрола, если надо изменить внутреннее свойство, не отображённое во внешний контрол? Писать мне письмо чтобы я выпустил новую версию?
В общем случае — да, но все это можно заранее предусмотреть и описать эти свойста. Как еще 1 вариант, можно разрешить пользователю изменять Template, как общий для контрола, так и для его отдельных частей, как это реализовано в DataGrid контроле.

HL>Какой-то ...дак в тогда еще Borland решил, что все, что мы накидаем на формочку — published, и оно доступно для всех и отовсюду.
Откуда это маниакальное стремление всё запретить и прекратить? Похоже, вам сюда http://rsdn.ru/forum/flame.politics/4231362.aspx

Автор: Osaka
Дата: 13.04.11

HL>Вас же не смущает, что в шарпе члены типов и сами типы без явно заданных модификаторов доступа не являются public?
Так и сделали бы как "в шарпе", самим контролам я так и быть напишу руками public — и из кода cмогу всё назначить, не поправ священную инкапсуляцию. А если из кода можно, то какой смысл был делать "нельзя" из разметки?

А>В общем случае — да, но все это можно заранее предусмотреть и описать эти свойста.
предусмотреть всё невозможно. Ну или развернуть всё дерево (а свойство у контролов 100500)
А>Как еще 1 вариант, можно разрешить пользователю изменять Template, как общий для контрола, так и для его отдельных частей, как это реализовано в DataGrid контроле.
ага, переопределение темплейтов по сравнению с добавлением одной строчки с новым значением свойства

Здравствуйте, Аноним, Вы писали:

А>Откуда это маниакальное стремление всё запретить и прекратить?
"Оттуда". (С)

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

HL>>Вас же не смущает, что в шарпе члены типов и сами типы без явно заданных модификаторов доступа не являются public?
А>Так и сделали бы как "в шарпе"
Так они и сделали. Хотите задавать из разметки — делайте DP и радуйтесь жизни.

Здравствуйте, <Аноним>, Вы писали:

А>Делаю UserControl, в нём TextBlock и TextBox. Помещаю его в форму. Как правильно из разметки формы, где используется мой контрол (<my:UserControl1 .../>), задать значение какому-нибудь внутреннему свойству, например TextBlock.Text?
x:FieldModifier?

Здравствуйте, Аноним, Вы писали:

А>>В общем случае — да, но все это можно заранее предусмотреть и описать эти свойста.
А>предусмотреть всё невозможно. Ну или развернуть всё дерево (а свойство у контролов 100500)
А>>Как еще 1 вариант, можно разрешить пользователю изменять Template, как общий для контрола, так и для его отдельных частей, как это реализовано в DataGrid контроле.
А>ага, переопределение темплейтов по сравнению с добавлением одной строчки с новым значением свойства

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