WPF - Как лучше сделать следующий контрол?
Перетащить в коллекции.
Юсер, батенька юсер для начала....
просто по-разному отображаешь
То бишь вьювы копировать и модифицировать. Повторю еще раз "Copy/Paste" не разрешается.
то от просто добавляет его в коллекцию шкафов
ага ходит по всем рабочим местам и с бумажки вводит данные. Можно конечно и так сделать.
Но планируется описание шкафа залить на сетевой диск и оттуда его просто добавлять.
и заказчик сможет добавлять шкафы и менять их порядок даже не запуская программу
Есть у нас одна старая прога на этом принципе. Кроме разработчика никто больше не знает какой ХМЛ файл и какое поле нужно менять для требуемой задачи. И это не пользователи!
Я там просто добавил новые поля в ModelView и изменил отображение
Для этого не требуется иметь исходного кода и компайлера - заказчик все может сделать сам
Вместо вертикального стека (ItemsControl) сделай ListBox
Это вроде бы обсуждалось в самом начале. Конфигурация должна быть отделена от данных.
И как быть в этом случае?
Кстати, SelectedIndex как лучше сделат? Dependency Property постоянно выбрыкивается. То в одну сторону биндинга проблемы, то в другую.
Какого без ValueChanged очень часто не работает?
http://www.eidias.com/blog/2015/7/16/why-does-the-binding-...
Юсер, батенька юсер для начала....
При чем тут юзер?
То бишь вьювы копировать и модифицировать. Повторю еще раз "Copy/Paste" не разрешается.
Ты вообще о чем? :) Какие "Copy/Paste"? Мы вообще об одном и том же говорим?
ага ходит по всем рабочим местам и с бумажки вводит данные.
Можно конечно и так сделать.Но планируется описание шкафа залить на сетевой диск и оттуда его просто добавлять.
Да хоть от куда бери :) Какая разница? Берешь ModelView (в моем примере это класс LibraryViewModel) и сериализируешь в XML.
От куда потом ты эту XML возьмешь и десериализируешь - глубоко фиолетово :)
Есть у нас одна старая прога на этом принципе. Кроме разработчика никто больше не знает какой ХМЛ файл и какое поле нужно менять для требуемой задачи. И это не пользователи!
Ну так меняй через GUI. Какие проблемы?
Для этого не требуется иметь исходного кода и компайлера - заказчик все может сделать сам
А поля теперь уже тоже надо менять? (впрочем, это тоже не то чтобы сложно) :) Я же не знаю, что у тебя там за поля. Вот и добавил пару штук чтобы было похоже с твоей картинкой.
Это вроде бы обсуждалось в самом начале. Конфигурация должна быть отделена от данных.
Ну этим занимается MVVM.
И как быть в этом случае?
Сделал пример на ListBox'е :) см. аттач.
Сейчас времени совсем нет, так что затянул с примерчиком :)
Мы вообще об одном и том же говорим?
У нас "способы"/"методы" мышления совершенно разные, что с одной стороны замечательно (можно найти гораздо лучшее решение), а с другой стороны сразу понять другого достаточно тяжело.
Мне понадобилось несколько дней чтобы придумать как можно было использовать ваш пример в рамках того что мне нужно. Чисто для отображения было бы гораздо проще чем сейчас у меня.
При чем тут юзер?
при том как ему перемещать шкафы, как сделано в вашем примере 3. Там есть кнопочки, а в пример 1/2 их можно всунуть только к каждому шкафу. (По крайней мере я не вижу другого решения)
Ты вообще о чем? :) Какие "Copy/Paste"?
При том что отображение шкафов/полок в редакторе шкафов и для пользования отличаются. У Вас в примере всегда только одно окно, а их должно быть минимум два. Одно окно исключительно для редактирования конфигурации шкафов, которое будет доступно не всем и второе окно сконфигурированные шкафы с данными - им могут пользоваться все.
в моем примере это класс LibraryViewModel
public class LibraryViewModel : BaseViewModel { private ObservableCollection<Rack> _racks;
и где тут один единственный шкаф? Можно конечно сказать что коллекция из одного элемента и есть один шкаф. И после добавлять только этот один элемент в другую коллекцию. Но лично для меня это "извращение".
при том как ему перемещать шкафы, как сделано в вашем примере 3. Там есть кнопочки, а в пример 1/2 их можно всунуть только к каждому шкафу. (По крайней мере я не вижу другого решения)
Кнопочки я допавил специально, чтобы показать, что за редактированием (удалением полок/стеллажей, перемещением или добавленийм полок/сталлажей (я этого не делал, но далается точно также как и удаление/перемещение) ) не стоит никаких особенных действий - просто изменяется соответствующая коллекция объектов.
У Вас в примере всегда только одно окно, а их должно быть минимум два.
Совершенно не важно сколько окон ;) Данные одни и теже, просто они по-разному отображаются. Чтобы продемонстриторать это, в последнем примере есть нижняя часть, где слева отображается информация о стеллаже, а справа о полке. (надо сначала выделить стеллаж, а потом полку. сразу у меня не получилось сделать так, чтобы при выделении полки автоматически выделялся и стеллаж. решение, я уверен, есть, а для
демонстрации и так сойдет :))
Одно окно исключительно для редактирования конфигурации шкафов, которое будет доступно не всем и второе окно сконфигурированные шкафы с данными - им могут пользоваться все.
Не понимаю, почему тебя так смущает количество окон? В чем тут проблема? Ведь в конфигураторе шкафов будет отображаться тот же самый объект, что и для всех пользователей. Разница будет только в используемых контролах (в одном случае TextBox, в другом TextBlock)
и где тут один единственный шкаф?
Этот класс представляет всю библиотеку. Шкаф - это Rack.
А поля теперь уже тоже надо менять?
не теперь а самого начала. Пока возможны 4 различных комбинации - исходя их двух чекбоксов. Типа так
Ну этим занимается MVVM
Я имел в виду другое. ListBox имеет один ItemSource и он уже заполнен "конфигурацией". Чтобы мне туда закинуть данные их придется "подмешивать" в "конфигурацию".
Грубо говоря, я хочу ItemSource1 для "конфигурации", ItemSource2 для данных
Сейчас времени совсем нет,
Спасибо,что хоть вообще откликаетесь. Похоже мы тут вдвоем только и остались.
Кстати, XML сериализация - кто чем пользуется?
Ладно, пришлось привате данные сделать пабликом. Но сериализовать Dictionary мелкософт не хочет.
Есть костыли, но у меня Dictionary в сериализуемом классе, нужно опять извращаться - задолбало.
https://stackoverflow.com/questions/12554186/how-to-serial...
С DataContractSerializer были какие то другие проблемы, раньше пробовал.
чтобы показать, что за редактированием не стоит никаких особенных действий
ну это вроде и так понятно. Просто для "кнопочки" нужен выбранный элемент. Как только есть возможность выбрать элемент, тут же появляется и "кнопочка".
Ведь в конфигураторе шкафов будет отображаться тот же самый объект, что и для всех пользователей
пример редактор
Хотя тут можно одну часть сделать невидимой - это я уже позже придумал.
Шкаф - это Rack.
То есть сохранять объект, который нельзя отобразить "напрямую"? Можно и так сделать...
Как тогда обеспечить в режиме редактора одновременное изменение нескольких шкафов?
Но лично для меня это "извращение".
------
Если оно дает нужный результат на твоих обьемах данных - какая разница что оно для тебя?
Похоже мы тут вдвоем только и остались.
------
Неа... но, как и говорил, с WPF - не ко мне.
XML сериализация - кто чем пользуется?
------
А той, которая работает - обычная, соаповская и самописная.
Последняя - немного нудная, но выхлоп тот что нужен.
у меня Dictionary в сериализуемом классе
-----
Ну так унаследуйся и пререкрой сериализацию. Там не много.
Как тогда обеспечить в режиме редактора одновременное изменение нескольких шкафов?
-----
Ну а старого Кота ты таки слушать не хочешь?
Там где про три файла?
Количество шкафов в одном, содержимое шкафов - в другом.
Или у тебя снова вопросы по смеси структуры данных с элементами отображения и обработкой событий в WPF?
какая разница что оно для тебя?
"извращения" имеют особенность накапливаться и после определенного предела код уже невозможно понять и модифицировать.
А той, которая работает
на данный момент все три не удовлетворяют всем критериям.
В "своей" требуется большая автоматическая резистентность к изменению данных. Хоть и номер версии идет "автоматом"
Ну так унаследуйся и пререкрой сериализацию
надо время на "разобраться".
Ну а старого Кота ты таки слушать не хочешь?
Подожди, дай рыбку доесть
Если ты свяжешь картинку из 68 со своими тремя файлами, можно подумать....
https://foren.germany.ru/showmessage.pl?Number=33508309&Bo...
в WPF
с ним потихоньку разбираемся.
Хотя какого UserControl-у они дают другой DataContext, до сих пор не дошло, постоянно приходится писать "длинную строку" с рассказом как же взять контехт таким же образом как и для всех остальных контролов.
Пока возможны 4 различных комбинации - исходя их двух чекбоксов. Типа так
Я не вижу тут 4-х различных вариантов.
Я вижу 1 вариант:
1) 2 чекбокса (Junk box и Priority)
2) одна тавлица Preview с гридом на 3 колонки.
- колонка с индексом 0 - проперти Visibility связана с состоянием чекбокса Junk box (через конвертор CheckedToVisibility)
- колонка с индексом 1 - проперти Visibility связана с состоянием чекбокса Priority (через конвертор CheckedToVisibility)
- колонка с индексом 2 - всегда видимая
И никаких гвоздей :)
Я имел в виду другое. ListBox имеет один ItemSource и он уже заполнен "конфигурацией". Чтобы мне туда закинуть данные их придется "подмешивать" в "конфигурацию".Грубо говоря, я хочу ItemSource1 для "конфигурации", ItemSource2 для данных
Есть один объект - ViewModel. Объект этот сложный, состоит из многих других объектов и коллекций. Можно разделить создание ViewModel на два этапа - сначала создать "каркас", а потом заполнить данными. Можно определить, что "каркас" - это конфигурация, а данные берутся сразу из БД или еще как. Тут есть множество вариантов. И все это вопрос определений. Но факт в том, что одного ViewModel достаточно, чтобы отобразить все данные :)
Кстати, XML сериализация - кто чем пользуется?
Я тользуюсь сериализатором от MS. Не парюсь на этот счет :)
Не помню, чтобы мне надо было сериализовать Dictionary...
ну это вроде и так понятно. Просто для "кнопочки" нужен выбранный элемент. Как только есть возможность выбрать элемент, тут же появляется и "кнопочка".
Да нет, это просто user frendly :) Можно сделать на двух эдитблоках и одной кнопке (в одном вводится актуальный индекс, в другом новый и кнопка "переместить"). Можно на одном эдитбоксе - вводишь строку "4->8" как только эдитбокс теряет фокус - парсишь и исполняешь. (строка "4->8" перемещает стеллаж, а "6:2->10" перемещает полку на 6-ом стеллаже).
То есть сохранять объект, который нельзя отобразить "напрямую"? Можно и так сделать...
Как тогда обеспечить в режиме редактора одновременное изменение нескольких шкафов?
Я не совсем понимаю задачу...
В любом случае, определяешь View1 для одного объекта, потом делаешь View2 для коллекции этих View1. Ну и хочешь - отображай один объект, хочешь - все :)
Если ты присмотришься к моему примеру, то увидишь, что Rack и Shelf -
можно использоваться как ViewModel, так что для всех связанных с отображением задач редактируется только XAML (ну может быть еще конвертеры могут понадобиться :))
Не так все плохо, если они изолированы и не мешаюt.
Потому тебе и предлагалось - структура данных - отдельно, презентация - отдельно.
Но ты почему-то хочешь иметь что-то смешанное.
требуется большая автоматическая резистентность к изменению данных.
------
Да, но это будет тормозить.
По-этому Я не заморачиваюсь - пишу и поддерживаю член-методы - 100% резистивность. Задача версионности - отдельно.
Если ты свяжешь картинку из 68 со своими тремя файлами
-----
Вот тебе вообще все по-отдельности - редактируй любой фрагмент независимо от других - все соберется.
Блин, не проходит пост с файлом 15К...
Куда забросить?
Я вижу 1 вариант:
И как его присобачить к Вашим вариантам?
одного ViewModel достаточно, чтобы отобразить все данные
Что то Вы не туда смотрите или скорее у нас разные "ограничения".
"Данные" хранятся и сериализуются в коллекциях. Любая коллекция должная "напрямую" отображаться. конфигурация - одна коллекция и данные другая "коллекция". Загруженные данные могут меняться, соответственно записываются автоматом в файл. При данной реализации эти две коллекции придется каким то образом "смешивать", нужно следить/выбирать реализацию чтобы чего лишнего не записалось.
Я тользуюсь сериализатором от MS. Не парюсь на этот счет
На да - если данные нужно делать публичными исключительно для сериализации, напишем коммент - "руки прочь" и не паримся
А уж не дай бог что то переименовать, комментов не напасёшся.