WPF - требуется ИИ, можно с детьми
Что то народ теорией стал развлекаться. Есть более приземленная задачка.
Есть XAML в котором имется следующая часть, пока только с одним элементом
<local:Toolbox ItemSize="80, 60">
<ItemsControl.Items>
<Grid >
некоторое количество элементов
</Grid >
<ItemsControl.Items>
</local:Toolbox>
Требуется/хочется переместить элемент в ResourceDictionary.
С копированием проблем нет, но как использовать этот элемент из ресурсов?
<local:Toolbox ItemSize="80, 60">
<ItemsControl.Items>
<??? ="{StaticResource Имя}" >
<ItemsControl.Items>
</local:Toolbox>
Хотелось бы сохранять именно только один элемент списка по отдельности, не весь список.
Один элемент списка достаточно сложный объект и хочется его иметь в отдельном файле ресурсов.
недопонятно. что именно вы хотели бы поместить в ResourceDictionary? попробуйте сформулировать ваш вопрос иначе. мне кажется, вы не вполне понимаете, что такое ResourceDictionary и как его можно/нельзя применить. но может, я ошибаюсь. по-крайней мере в том виде, как вопрос задан, я бессилен что-нибудь ответить.
мне кажется, вы не вполне понимаете, что такое ResourceDictionary и как его можно/нельзя применить.
Я почти уверен что Вы не ошибаетесь. 
Пока есть ассоциация только с Винформс и видел, что в WPF очень любят закидывать туда разные стили, кисточки и прочую мелочевку. Объекты тоже попадаются.
Есть допустим, у меня некая механическая деталь, нарисовал я её как то в XAML-е - вот получился некий объект. Этот объект я могу переместить с формы в ресурсы, а потом использовать из кода. В объект где есть Content тоже можно вставить
<Content="{StaticResource Имя}"/>
Получается именно то, что нужно один и тот же объект который можно использовать и в коде и в XAML-е.
что именно вы хотели бы поместить в ResourceDictionary?
Сейчас у меня в ресурсах именно то что было внутри ItemsControl.Items - это отдельный специально подключаемый файл
<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
<Grid x:Key="Name">
дофига разных объектов должно быть. Рисуют определенную фигуру
</Grid>
</ResourceDictionary>
Для теста пока сделано максимально упрощенно. Слева и на "поле" один и тот же объект с несколько разными параметрами. То что слева и есть Toolbox
возможно, этот линк может послужить вам отправной точкой:
https://stackoverflow.com/questions/22960220/create-a-cont...
Спасибо - Ответ невозможно
When you define a arbitrary Control in Resources, you can use it in the future in Control which have property Content and derived from Control class. These are the followings: ContentControl, Label, ContentPresenter, etc.
Можно извратиться, но это будет не один и тот же элемент для кода и XMLа
<local:Toolbox ItemSize="80, 60">
<ItemsControl.Items>
<ContentControl
Content="{StaticResource Имя}">
</ContentControl>я все равно не понял вашей конкретной задачи, так что вряд ли смогу вам быть чем-то полезен. вот интересная дискуссия о ContentPresenter'e, если интересно.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/675...
и ищо:
я все равно не понял вашей конкретной задачи
Зато нашли решение 
. И с наступающим!!!
Задача относительно простая, но есть над чем подумать.
Есть некое 2Д измерительное устройство и есть лист материала определенного размера. Устройство может измерять параметры материала на определенной площади листа под измерительной головкой. Где именно измерять - решает заказчик. Можно измерять как всю поверхность листа (больше 20 точек), так и например в 5 точках (4 - по краям и 1 - в середине) - назовем это планом измерений.
Требуется редактор для создания плана измерения. Что то типа сильно упрощенного визио. Есть достаточно исходников редакторов диаграмм, но все найденные оказались либо слишком сложными либо "дурными". Пришлось искать компромисс.
На картинке в посте ранее слева был так называемый тоолбох, оттуда на "лист" можно перетащить измерительную головку. Определенная точка на головке должна располагаться на пересечении опорных линий (синего цвета, я называю ее сеткой). Когда "план измерений" сделан, его можно записать в файл для последующего использования другими программами. Файл можно также открыть для редактирования.
На сегодняшний момент все основные фунции реализованы. Исправляются ошибки, дополняются возможности. Сейчас вожусь с сеткой - не хочет подлая перерисовываться.
в общих чертах понятно. пару приложений где-то есть, которые мог бы для такого взять за прототип, если бы делал вашу задачу. но одна - в WinForms, одна - в Qt (еще одна - в MFC, но это уже не для сегодня).
в винформз очень удобная канва, а в кьюте очень легко двигать объекты, плюс мультиплатформенность сразу (если надо, конечно).
это клиент затребовал тулбокс, или "свое решение"? я бы попроще попытался придумать. вариантов, конечно, большое множество, но можно:
0. создать какой-нибудь интерфейс, где можно было бы наклацать параметры (типа размер заготовки, шаг сетки, способ размещения головок по сетке, ...), и потом по кнопке окэй натыкал бы на канву головки. человек может посмотреть, если не нравится - изменить. или двигать руками (snap to grid etc.)
1. если уже вручную размещать головки, то не таскал бы их из тулбокса (это только таскать легко, а программировать таскание - головнячок), а пусть клацает правой мышкой в точку, где хочет разместить головку, появится меню с одним из п-в "new head" (может еще что-нибудь?), и когда клацнет - головка создается и помещается туда, где клацнул (или в ближайший узел сетки)
2. выбирается где-то (пускай в тулбоксе) кнопка "головка", и пока ее не "отвыберут", клац левой мышей по полю создает головку. можно очень быстро наклацать множество.
3. ...
но вам виднее, я просто накидал того, что вы наверняка уже тоже рассматривали.
да, конечно же с наступающим! : )
(огненная собака, кажется, наступает?)
но одна - в WinForms
Так текущее приложение и есть WinForms, WPF-ый контрол будет туда закинут. Хотя у начальства в планах потихоньку двигать на WPF.
Мне подумалось что WPF больше подходит для ентого дела, да и что то интересное нужно было на каникулы.
это клиент затребовал тулбокс, или "свое решение"?
Клиент вообще ничего пока не знает. Написано просто "возможность различного размещения мест измерений" или что то в этом роде.
создать какой-нибудь интерфейс, где можно было бы наклацать параметры
Это в проперти гриде задается и пишется в файл.
Стандартные размещения будут идти в заранее заготовленных файлах.
snap to grid есть, как и авторазмещение на свободном месте поля если объекты перекрываются.
Еще добавлю оптимизация пути перемещения.
Как сделать попроще не сильно думал. Идея была сделать как интересно, а там уж посмотрим.
а программировать таскание - головнячок
никаких проблем не заметил (Thumb)
Как сделать попроще не сильно думал. Идея была сделать как интересно, а там уж посмотрим.
расскажу я вам, наверное, под новый год притчу. вообще это в реальности было. наняла моя фирма "помощника" на стороне. парень очень хороший (как человек), умел очень хорошо обходиться с людьми, поэтому руководителю проекта нравился, и тот позволял ему делать все так, как тому того хотелось. когда я однажды высказал предположение, что его решение задачи сложнее самой задачи, он изрек нечто вроде "ты думаешь, я не в состоянии это с помощью if...then... else... сделать? но мне так - неинтересно!". присутствующий при этом рук. проекта кинул ему восхищенный взгляд и изрек нечто "Х не такой разработчик, как вы все, он - особенный!". я заглох и занялся своим делом: как бы для сложных задач простые решения придумать.
крутил-крутил
наш гений, создал нечто, во что всем, кто был рядом, пришлось кроме знаний/опыта в С/С++ еще и в его созданный метаязык и прочую муру врабатываться. но я с этим мало пересекался, и старался по возможности вообще места, где он поваял, обходить стороной. через полгода где-то он откланялся. естественно, никто не лез разбираться в его творчество пока нужды не было. но настал тот час, когда там что-то пошло не так (такое, бывает, случается). пару человек попялились в этот "код", потом сказали, что это - "изнасилование С++","загадки для взрослых", и плюнули. шеф вызвонил гения, тот пришел, попялился полдня в собственный код и со словами "извините, ребята, я, наверное, вас подставил, но я ей-богу ничего здесь понять не могу. сорри!" свалил. уже
не помню, как и кто это дерьмо потом разгребал или переделывал, но мораль мне извлекать не нужно было: я и так знал, чем такие вещи обычно заканчиваются.
Идея понятна и знакома. Но в данном случае мне было относительно по барабану.
На "каникулах" дома работать смысла нет, а поделать, что интересное и с какой то пользой смысл есть.
Был еще вариант с Юниксом покапаться - Гит на сервере по SSH не хочет опять запускаться, но уже надоело, надо было сделать перерыв.
Так бы было просто без редактора, писали бы файл ручками. Да и сделать сложно вариант был - просто взять готовый редактор.
Работает! Спасибо.
По описанию бы не додумался до ентого
https://docs.microsoft.com/en-us/dotnet/api/system.windows...
Это одно и то же. Суффикс "Extension" можно опускать, так же как и суффикс "Attribute". Синтаксический сахар от Майкрософт.
ЗЫ. Я уже написал довольно много собственных XAML Markup Extensions, со свистелками и пер, с блекджеком и шл, с фичами, которые были необходимы команде. Рекомендую поизучать материю, там много интересного. Заодно и про XAML подучить можно.
Хочу предостеречь от одной ошибки, которые многие делают, начиная изучать 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 по определению - это всё, что относится к предметному домену и бизнес-логике. То есть и "просто данные" тоже.
весь смысл мввм в том, что когда мы креируем модел, мы думаем о problem domain исключительно! не беря в голову совсем, будет нас кто-то просматривать вообще, или никогда.
когда мы креируем вью, мы не думаем, как у нас устроена модел, и существует ли она вообще. и только вьюмодел знает оба конца (кстати, в ней - бизнес-логика, а не в модел, как кто-то здесь ошибочно написал. по-крайней мере так задумано в классической мввм).
но я бы не рекомендовал зацикливаться на шашечках.
Ребята, не охота тут устраивать лекции. Ну, почитайте книжки и стэковерфлоу.
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 года без применения этого опыта и... закрыли тему в связи с окончанием работы...
Model - это совокупность всех классов, объектов, данных, конфигураций и всего прочего, что составляет предметную область приложения.
Был такая мысль что мы используем разные определения для себя.
предлагаю всё же поднабраться опыта
Ну так как рвз подобные дискуссии в этом и способствуют. Либо нужно постоянно энтим заниматься.
Я вот эту задачку закончу, а как попадется WPF в следующий раз неизвестно.
Вот еще интересен концепт реализации. Не буду детали как то классифицировать в понятия MVVM.
Есть некий общий класс, который нужен различным элементам приложения и данные для которого могут видоизменятся п процессе работы.
Как его лучше передать всем элементам?
Например, в данном случае есть класс вычисления опорных точек. Он используется при показе "фоновой сетки", для выравнивания элеметов и т.п.
Сейчас сделал DependencyProperty и биндинг в ХАМЛе всем элементам для одного окошка