Это одно и то же. Суффикс "Extension" можно опускать, так же как и суффикс "Attribute". Синтаксический сахар от Майкрософт.

ЗЫ. Я уже написал довольно много собственных XAML Markup Extensions, со свистелками и пер, с блекджеком и шл, с фичами, которые были необходимы команде. Рекомендую поизучать материю, там много интересного. Заодно и про XAML подучить можно.

Ну как что вылазит потихоньку изучаю.

Просто пока WPF чисто как фон идёт. Я этот проектик и начал, чтобы без спешки что то новое на "каникулах" изучить.

Как работа начнётся опять будет "Дафай-Дафай".

Хочу предостеречь от одной ошибки, которые многие делают, начиная изучать WPF. Часто этот фреймворк рассматривают только как DirectX альтернативу WinForms с необычным способом формирования GUI через XAML. То есть продолжают использовать WinForms подход, но на новых инструментах.

WPF - это смена парадигмы. Декларативный подход к описанию GUI, а не императивный. WPF показывает всю свою мощь, если грамотно применять концепцию MVVM. Конечно, старые методы будут работать тоже, но стоит ли овчинка выделки? WinForms будет всё-таки побыстрее, особенно на старых машинах.

Я почему это пишу. Увидел, что вы запихиваете UIElement в ItemsControl.Items. Так делать можно, но... Предназначение у ItemsControl'а другое.

Ну MVVM для WPF и MVP для Winforms - это как бы "стандарт" для меня. Хотя и не всегда.

Для WPF еще OnPropertyChanged добавляется

Да и для нормального изучения WPF нужно достаточно долгое время работы только с ним. А пока получается только урывками.

Предназначение у ItemsControl'а другое.

А какое? Как видел, в основном, UIElementы и пользуют. Я вот раньше тут целый проект выложил, тоже чисто интереса сделал. Так тоже для кнопочек использовал.

ItemsControl предназначен для отображения коллекции объектов, а точнее - коллекции объектов model или view-model. Он заточен под это. У него имеются dependency property ItemsSource и возможность применять DataTemplate к каждому объекту коллекции.

Если надо отобразить статический набор каких-то UIElement'ов, то используйте любую Panel: Grid, UniformGrid, DockPanel, StackPanel, WrapPanel.

Как я уже писал, можно, конечно, в ItemsControl вручную запихивать UIElement'ы. Он это проглотит. Но это забивание гвоздей микроскопом.

а точнее - коллекции объектов model или view-model

никогда такое не требовалось и не думаю что потребуется. Да не могу еще где то найти подобное утверждение.

http://www.dotnetcurry.com/wpf/1160/wpf-itemscontrol-funda...

http://www.wpf-tutorial.com/list-controls/itemscontrol/

https://docs.microsoft.com/en-us/dotnet/api/system.windows...

Represents a control that can be used to present a collection of items.

An ItemsControl is a type of Control that can contain multiple items, such as strings, objects, or other elements.

The following illustration shows a ListBox control that contains the following different types of items:

A string.

A DateTime object.

A UIElement object.

Если надо отобразить статический набор каких-то UIElement'ов, то используйте любую Panel

А кто сказал что Тулбох должен отображать исключительно статические элементы? Это чисто сейчас.

Если думаете, что не потребуется, тогда рекомендую почитать про MVVM в WPF подробнее. 99% юзкейсов ItemsControl'а - это отображение коллекции объектов из view-model через байндинг к свойству ItemsSource (и автоматическим созданием CollectionView) и определению DataTemplate для объектов коллекции.

По ссылкам не ходил. В примере от Майкрософт string и DateTime - это именно объекты model. То что туда добавили UIElement - это просто пример, что такое тоже возможно. Такое иногда требуется, например, для создания комбинированных статическо-динамических представлений, но это уже эдвансд топик, как говорится.

Вот первая ссыль из гугла, простейший туториал: http://www.wpf-tutorial.com/list-controls/itemscontrol/

А, вижу, эту статью вы тоже нашли. Ну так вот там ровным счётом это и показывается - как отображать коллекцию объектов через темплейтинг, то есть декларативное описание представлений для объектов model и view-model. Просто тут для упрощения напрямую загоняют объекты в itemsControl. На практике это делается через байндинг к ItemsSource, иначе весь смысл теряется. Коллекция-то может быть динамическая (ObervableCollection), а XАML статический.

это именно объекты model.

я просто не называю это "объекты модели". Просто данные.

это отображение коллекции объектов из view-model через байндинг к свойству ItemsSource

Ну так это совсем другое дело. Прочиталось "коллекции model или view-model объектов".

Правильно прочиталось. View-model не может содержать UIElement-ов, поэтому любая коллекция из view-model может содержать только model или другие view-model. В качестве model могут выступать и обычные объекты простейших типов. Ведь model по определению - это всё, что относится к предметному домену и бизнес-логике. То есть и "просто данные" тоже.

в общем, кому-то - ехать, а кому-то - шашечки...

зы. это - не ответ на конкретный пост, просто не знаю, как, не отвечая ни на что, просто пост написать. ближе всего этот вот попался.

поэтому любая коллекция из view-model

хм что то опять непонятки.

К одному View цепляется одна ViewModel ну и одна Model.

Какого мне городить еще коллекции из view-model да и еще отображать их ?

весь смысл мввм в том, что когда мы креируем модел, мы думаем о problem domain исключительно! не беря в голову совсем, будет нас кто-то просматривать вообще, или никогда.

когда мы креируем вью, мы не думаем, как у нас устроена модел, и существует ли она вообще. и только вьюмодел знает оба конца (кстати, в ней - бизнес-логика, а не в модел, как кто-то здесь ошибочно написал. по-крайней мере так задумано в классической мввм).

но я бы не рекомендовал зацикливаться на шашечках.

К одному View цепляется одна ViewModel ну и одна Model.

------

Насколько Я помню, а делал это где-то в 2005/7, ВьевМодел может быть много, но по одной в каждый момент времени.

Ребята, не охота тут устраивать лекции. Ну, почитайте книжки и стэковерфлоу.

View-model - это не какой-то супер-пупер класс, который может быть один на одно представление. Model - это не какой-то супер-пупер класс, который в предметном домене только один и к нему обращается view-model. Это всё - концепции, названия. Model - это совокупность всех классов, объектов, данных, конфигураций и всего прочего, что составляет предметную область приложения. То есть, это то, ЗАЧЕМ вообще приложение есть. View - это некое представление чего-то. Окошко диалоговое - это view. Но и единичный комбобокс в этом окошке - это тоже view.

А view-model - это просто прослойка между view и model. Её задача - адаптировать model так, чтобы её можно было показать. И всё! Никакой бизнес-логики там, вы что! Бизнес-логика - на доменном уровне. View-model содержит логику, но не бизнес. Во view-model логика приложения (когда какие окошки показывать, когда размер окна сохранять, где апдейты качать и т.п.) и есс-но логика, необходимая для отображения (сортировка всякая, фильтрация там и пр.)

По поводу того, почему может быть коллекция view-model. Как я уже написал, view может быть единичным элементом большой конструкции. Допустим, у нас 10 элементов управления, достаточно сложных (например, 5 кнопок, 2 комбо и 3 текстбокса), но одинаковых. Так вот имеет смысл создать класс view-model для этого элемента управления, засунуть 10 объектов этого класса в коллекцию, забайндить эту коллекцию к ItemsSource ItemsControl'а и опрделить DataTemplate для этого всего. В итоге получаем стройное решение, где у каждого класса свои обязанности.

В общем, предлагаю всё же поднабраться опыта. И почитайте, например, да хоть тот же гайд к Prism. Многое прояснится.

И всё!

-----

И где противоречие с тем что Я написал?

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

-----

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

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

предлагаю всё же поднабраться опыта.

-----

Хорошо бы... Вот только... куда Я его применю? Время на изучение - месяца 3-4-6(?)... ну или год без отрыва от производства... потом еще 2-2.5 года без применения этого опыта и... закрыли тему в связи с окончанием работы...

ВьевМодел может быть много, но по одной в каждый момент времени.

Что то сложно представить нафига окошку менять DataContext, а как при этом еще и менять DesignInstance

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

Был такая мысль что мы используем разные определения для себя.

предлагаю всё же поднабраться опыта

Ну так как рвз подобные дискуссии в этом и способствуют. Либо нужно постоянно энтим заниматься.

Я вот эту задачку закончу, а как попадется WPF в следующий раз неизвестно.

Вот еще интересен концепт реализации. Не буду детали как то классифицировать в понятия MVVM.

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

Как его лучше передать всем элементам?

Например, в данном случае есть класс вычисления опорных точек. Он используется при показе "фоновой сетки", для выравнивания элеметов и т.п.

Сейчас сделал DependencyProperty и биндинг в ХАМЛе всем элементам для одного окошка