WPF - Как лучше сделать следующий контрол?
Чтобы было понятно опишу в привычных терминах.
Есть стеллажи с полками. На стеллаже может быть от 4 до 30 полок. На каждой полке может лежать одна и только одна книга, дополнительно на полке может быть еще несколько табличек, типа автор и год издания. полка может иметь различные состояния отображаемые различными цветами (типа книгу разрешено выносить из библиотеки, книга в читальном зале и т.п.). При работе проги может быть от 1 до 10 различных комбинаций стеллажей.
Программа должна иметь редактор стеллажей. Стелажи нужно выбирать в редакторе, но не нужно при работе. Полки нужно выбирать при работе, но не нужно в редакторе. Дополнительные данные при работе могут вводится вручную для каждой полки.
Очень хочется иметь раздельное описание конфигурации стеллажей и данных на полках, что в принципе отметает листбоксы и гриды.
Есть стеллажи с полками.
------
Стеллаж - контейнер, дин.массив, коллекция полок.
Есть критичность в последовательности доступа к полкам?
На стеллаже может быть от 4 до 30 полок.
-----
Ограничения на размер, встроенные, параметры конструктора, свойства.
На каждой полке может лежать одна и только одна книга,
дополнительно на полке может быть еще несколько табличек,
типа автор и год издания.
-----
ограничения - ноль или одна книга,
коллекция табличек, ноль и более элементов.
Думаю, что в большинстве случаев ты будешь манипулировать всей полкой.
полка может иметь различные состояния отображаемые различными цветами
(типа книгу разрешено выносить из библиотеки, книга в читальном зале и т.п.).
-----
Свойство "состояние полки", коллекция/словарь атрибутов/свойств?
При работе проги может быть от 1 до 10 различных комбинаций стеллажей.
-----
Коллекция стеллажей.
Снова спрошу - порядок доступа критичен?
Программа должна иметь редактор стеллажей.
Стеллажи нужно выбирать в редакторе, но не нужно при работе.
-----
Ну и какая проблема - грид с редактируемыми полями и сбросом результата в файл (хмл?).
Полки нужно выбирать при работе, но не нужно в редакторе.
Дополнительные данные при работе могут вводится вручную для каждой полки.
-----
Не ясно.
Ты говоришь, что у тебя есть редактор стеллажей - получается - конфигурацию, т.е. количество полок, ты определяешь ДО.
И тут же требуешь возможность редактировать после.
Данные - не проблема - добавь Табличке строковую проперть и научись ее заполнять из формы.
Форма для редактирования - удобней динамическая, строящаяся по коллекции Табличек.
Ну если совсем накручивать - форму органайзер со списком всех свободных Табличек и набивку конкретной полки с редактированием полей.
Очень хочется иметь раздельное описание конфигурации стеллажей и данных на полках, что в принципе отметает листбоксы и гриды.
------
Да никаких проблем - один охватывающий ХМЛ и две вложенных ентити - редактируй как тебе нравится.
Имплементация будет не намного дольше чем гриды с боксами...
Очень хочется иметь раздельное описание конфигурации стеллажей и данных на полках, что в принципе отметает листбоксы и гриды.
Вот за что я люблю с++... С одной стороны, прежде чем что-то мутить (писАть), надобно алфавит разработать (из чего потом системку собирать)... С другой стороны, при попытке воспользоваться готовыми решениями, неизбежно натыкаешься на бл..ские ограничения/тормоза при попытке чуть нагрузить систему от автора сего продукта... C# ненавижу, хотя и пользую иногда :))
Библиотека - горизонтальый стэк.
Стеллаж - вертикальный стэк.
Имеете ввиду что то типа этого?
http://www.wpf-tutorial.com/panels/stackpanel/
Тут "отсутствует" коллекция элементов и динамическое их создание. То бишь в коде нужно будет накидывать все элементы, делать самому выбор одного из них, а потом еще передавать туда "двухмерный" массив с данными
Полка - просто текст.
Это просто не канает. Пользователю будет показан текст, но ему еще нужно/можно вводить некие дополнительные данные.
Ты меня немного не так понял. Меня больше интересует выбор наиболее подходящего базового WPF элемента для требуемых целей.
Например: Listbox вертикальный и Listbox горизонтальный - визуально подходит. Элементы отдельного итема можно определить и динамически.
Но, большая проблема "пустых полок" - нужно задавать 10 "пустых" элементов для 10 полок, а после их заполнять данными. То бишь получается смесь данных для описания конфигурации и самих данных.
Есть критичность в последовательности доступа к полкам?
Произвольный доступ к полкам. В старой WinForms версии было все фиксированное и чисто для работы. Потому, было просто накидано 10 отдельных гридов по одной колонке для текста и 10х21х2 обычных чекбоксов для дополнительных данных (21 полка в стеллаже)
.Позже допишу еще....
Думаю, что в большинстве случаев ты будешь манипулировать всей полкой.
на полки вначале раскидываются книги с состоянием "недоступно". Затем оператор может добавить разрешенные дополнительные данные или изменить состояния по умолчанию.
Затем все полки на стеллаже переводят в состояние доступно.
Но это уже работа с готовым элементом , она меня сейчас почти не интересует.
Коллекция стеллажей.Снова спрошу - порядок доступа критичен?
Для работы вообще не имеет особого смысла. Книга располагается на стеллаже 2, полка 3 - произвольный доступ.
Для редактора, нужно иметь возможность выбрать отдельный стеллаж, например для удаления.
Ну и какая проблема - грид с редактируемыми полями
Прежде всего, количество строк определяется количеством элементов в общей коллекции данных.
Сделать в одной колонке 3 строки, в другой 30 будет непросто, как и вертикальное скроллирование исключительно одной колонки. (Хотя колонок должно быть несколько для одного стеллажа)
Ты говоришь, что у тебя есть редактор стеллажей - получается - конфигурацию, т.е. количество полок, ты определяешь ДО.И тут же требуешь возможность редактировать после.
перед 1-м запуском программы нет ничего.
Запускаем прогу создаем стеллажи. Перезапускам прогу - можно работать со сделанной ранее коллекцией. Можно также и редактировать старую коллекцию, но она станет активной только при перезапуске программы.
Да никаких проблем - один охватывающий ХМЛ и две вложенных ентити
Описание коллекции стеллажей можно делать как хочется. Оно будет делаться вообще то один раз перед стартом проги на конкретном компе. На одном рабочем месте будет всегда фиксированное количество стеллажей. Основное требование - одна и таже прога должна работать на любом рабочем месте.
А вот данные приходят из базы. Объединять эти два набора как то совсем не хочется.
ItemsControl с байндингом к коллекции view-model
пока так и сделано. Для начала сойдет.
НО - нет в принципе выбора отдельных элементов
С одиночным ItemsControl проблем вроде не возникает у меня. А вот со вложенными никак не получается. Что то я еще недопонимаю и у вложенного не появляются его элементы, хотя вроде все передается.
WPF -это все же не ко мне.
получается смесь данных для описания конфигурации и самих данных.
------
??? - Делаешь три файла один общий, один с конфигурацией и один с данными.
Первый - не меняется, второй - меняется с конфигурацией, третий - с изменением данных.
Каких-либо проблем с этим не встречал.
Произвольный доступ к полкам.
------
Ну значит индексер надо имплементить.
Проще это делать не в контролах, а вполне себе самостоятельно.
За пятницу Я аккурат что-то подобное накидал для графиков - там не много.
и 10х21х2 обычных чекбоксов
------
Угу... у меня практически тоже самое.
Все было написано для одного станка, теперь надо для произвольной группы. Где-то надо делать селектор и группировку данных в серии. Набросал представление того что надо и теперь подгоняю детали.
Еще раз - подумай над динамической формой - там не сложно, но позднее - удобно.
стеллаже 2, полка 3
-----
Я спрашивал немножко не об этом. Часто бывает достаточно одного итератора, без индексера.
Например, у меня станок способен выполнять десяток операций, но для конкретного куска стекла надо сделать только пять.
Вариантов имплементации у меня два
- сделать общий список из 10 операций и обращатся к ним через индексер
или
- сделать подвыборку в 5 операций и выполнить все из списка.
Второй вариант в большинстве случаев проще в имплементации - нужен итератор, не нужен индексер.
количество строк определяется количеством элементов в общей коллекции данных
------
Ну так и добавляй их в динамике (т.е. в рантайме). Количество и типы элементов возмешь из данных.
Сделать в одной колонке 3 строки, в другой 30 будет непросто
------
Глупости пишешь.
Представь полку отдельным гирдом в гриде стелажа и перестань думать об сложностях.
Запускаем прогу создаем стеллажи.
-----
После запуска проверяешь наличие одного файла.
Если он есть - считаешь что уже все сконфигурировано и можно работать.
Если его нет - создаешь три файла и начинаешь редактировать.
Редактировать xml можно и руками - совсем не обязателен визуальный редактор.
А вот данные приходят из базы.
------
Какая разница откуда брать данные? ну будут вместо файлов записи в таблицах. И чо?
У меня просто фабрика отдает другую имплементацию загрузчика.
Часто бывает достаточно одного итератора, без индексера.
на данный момент это совсем не интересует. Это все детали имплементации
Количество и типы элементов возмешь из данных.
А вначале данных нет - все полки пустые.
Представь полку отдельным гридом в гриде стелажа
грид в гриде ничего не меняет кроме лишнего усложнения. Грид изначально коллекция м:н
Редактировать xml можно и руками
Можно и в нотепаде все делать нифига вообще тогда проги писать.
Какая разница откуда брать данные?
никако
вполне достаточно одного,
-----
Ты, однако, просишь независимого редактирования двух разных наборов.
Поэтому - один обьединяющий и два отдельных.
Если бы еще знать
------
Именно то, что написано - динамическую набивку формы контролами.
У меня так слеплено для ввода данных принимаемых по умолчанию -
прожка создает пустую форму и отдает ссылку на то, что определяет
что именно надо запрашивать у юзера. А что именно надо запрашивать
зависит от версии используемой системы. У меня их три... пока - три.
Шеф когда ознакамливался - выпал в осадок - Что, вот так и все? - Угу... -
Мне нравится!!!
Это все детали имплементации
------
Угу... Но разница между ICollection & IList все же есть.
А вначале данных нет - все полки пустые.
-----
Ну и? Тебя смущают пустые коллекции? Вроде не должны.
Добавишь сериализацию/десериализацию и добавление/удаление и будет тебе редактор.
нифига вообще тогда проги писать.
-----
Так ты хочешь полный визуальный редактор делать?
Если в рамках Студии, то это прямая дорога к DSL.
Но как Я понимаю тебя все же интересует отдельная прожка.
По WPF Я тебе ничего не скажу, а структуру позади формы -
можем обсуждать.
Но лепить полный редактор Я бы не стал -долго это.
Ну и? Тебя смущают пустые коллекции? Вроде не должны.
Очень даже смущают. Конфигурация - это конфигурация. А данные - это данных. Нефиг объединять всё вместе.
Если в рамках Студии
нафига юсеру студия?
Но лепить полный редактор Я бы не стал -долго это.
Это то как раз самое простое было.
Зачем 3 файла?
-----
1, Программа должна иметь редактор стеллажей.
2, Стелажи нужно выбирать в редакторе, но не нужно при работе.
3, Полки нужно выбирать при работе, но не нужно в редакторе.
???
Можешь сделать, разумеется, один и работать с ним, но...
У меня в генераторе детальки конфигурации тоже хранятся в файликах.
Их можно прописать в один файл и все будет работать.
Но сделано - по файлику на табличку и один файл в котором ссылки на энтити.
Если мне нужно быстро посмотреть детали по какой-то таблице - смотрю один небольшой - 5-10 кб - файлик.
Если нужно быстро что-то исключить/заменить - это в обьединяющем файле.
Ну можно, конечно, редактировать и 700 х 10кб в одном файле. Но без удобного редактора Я это делать не горю желанием, а редактор писать довольно долго.
Очень даже смущают.
-----
Чем? нормальное состояние коллекции после создания - пустая коллекция.
Конфигурация - это конфигурация. А данные - это данных.
-----
Хммм... с точки зрения програмы - это все данные.
Ты предлагаешь:
Открыть файл конфигурации и прочитать про стелажи.
Открыть файл полок и прочитать про полки.
Связать полки со стелажами. ( Как?)
Я предлагаю:
Открыть файл конфигурации.
Читать секцию простелажи.
Читать секцию про полки.
Связывать, если достаточно информации или читать секцию про детали связывания.
Это то как раз самое простое было.
-----
Достаточно удобный и не слишком привязанный к структуре? нее, долго...
Ну можно, конечно, редактировать и 700 х 10кб в одном файле. Но без удобного редактора
У нас разный подход к проблеме.
И не знаю где ты видишь сложности, хотя как в асп.нет это всё нормально сделать я не знаю.
Есть страница редактора стеллажа - пара полей для ввода, превью и кнопки сохранить в файл и читать из файла
Есть страница редактора коллекции стеллажей - там список готовых файлов с конфигурациями стеллажей, "зал" со стеллажами и кнопки перемещения туды-сюды. Можно было и драг/дроп сделать, но жирно сильно будет.
Кода там почти ничего.
Чем? нормальное состояние коллекции после создания - пустая коллекция.
А нормальное состояние стеллажа после создание - Х пустых полок. Видишь разницу?
Ты предлагаешь:
Это не я предлагаю - это ты так думаешь.
Я же просто читаю готовую конфигурацию из одного файла.
нее, долго...
Два вечера на базовую идею - это долго?
Я пользуюсь
И заказчик пользуется.. разницу видишь?
Хотя и "для себя" я бы тоже не делал. Редактор нужен один единственный раз. "Извращения" типа драг/дропа нафиг не нужны.
Всё что не заказано - не делается. Заказано - что бы стеллажи были конфигурируемые.
Видишь разницу?
-----
Вижу то, что Х - внешний, по отношении к коллекции. А при исходном Х = 0 - имеем аккурат пустую коллекцию. Какой она и должна быть в исходном состоянии. Дальше можно ее заполнять Х != 0 полок.
А вот какое-то хранилище для стелажей - нужно. И таки оно будет изначально пустым.
Дальше - читай файлик и заполняй нужными полками.
Два вечера
-----
Два вечера? А что будет готово через два вечера?
Мне вот до зарезу надо редактировать свойства в конфигураторе шаблонов форм... и либо иметь удобный тоол, либо встроить это в Студию. За два вечера Я не успею даже описать корректную иерархию данных, не то, что сделать редакторы по месту. А ведь завтра будет новый шаблон и новые зависимости между элементами... а написать их нужно сейчас.
И заказчик пользуется..
-----
Когда Я почти месяц сидел с доками и нудно описывал все документированные элементы - мой шеф был сильно недоволен "задержкой".
Но когда оно заработало - стал сильно довольный.
Самое приятное - обучение работе с прогой, а текучка на вводе имеется, практически не отличается от обучения работе с остальным комплексом софта - обьяснили какие элементы бывают в изделии - вот с этим "заказчик" и будет работать... только форма для ввода не размазана полями по экрану, а вертикально-линейная, с исключением незаполняемых полей.
Плюс - версионность.
Так что не всегда закзчик прав. Хотя правее его - нету.
Мне вот до зарезу надо редактировать свойства
на бери 
https://www.codeproject.com/Articles/520253/ASP-NET-Proper...
Два вечера? А что будет готово через два вечера?
Две формы. Могу скрины кинуть, но WPF тебе бестолку как и сам принцип.
Про Х что не дошло, что ты имеешь в виду.
Заказано - что бы стеллажи были конфигурируемые.
-----
Ну так воткни редактируемый грид, заполни построчно количество полок и скинь в файл.
Потом подцепишь его как энтити и больше тебе ничего делать не надо.
Правда Я бы всеже положил прокладку между гридом и файлом там все одно когда-то придется влезать и переделывать между файлом и базой.
на бери
-----
Оно не умеет ничего из того что мне надо.
Ситуация следующая: есть шаблон, есть некоторый источник данных и есть желаемая конфигурация.
Возможная желаемая конфигуация определяется тем, какие версии шаблона доступны (и какие там использованы ключи/свойства) и тем, какие именно данные в источнике. Ни первое, ни второе на сейчас неизвестны.
И чтобы было вкусно - даже в рантайме с фактическим набором шаблонов и живыми данными нет гарантии получения всех возможных параметов конфигурации.
Это - примерно.
ну и как я энто в грид воткну?
-----
А что это такое? если это стелажи с полками, то тебе предлагается это не делать, а сделать один редактируемый грид в котором строка = стелаж, а содержимое - количество полок. Тупо построчно текстом количество полок.
А то, что ты привел - отрисуешь уже по результатам.
А то что надо похоже абсолютно другое
-----
Обычные свойства в конфигурации.
Я, правда, опустил многие моменты - часть из них иерархичны, часть - взаимозависимы, ну общее количество со связями на экран не вмещается.
Ничего сложного, за исключением того, что через полгода-год автор шаблона уже не помнит какие варианты он обработал, а какие так и не осилил.
все машины должны
-----
Стоп-стоп-стоп...
Мы какую задачу рассматриваем?
как задать количество стелажей с определенным количеством полок на каждом?
Или как выполнить нотификацию об изменении конфигурации, включая выключенные компы?
Вот и решай одну задачу за раз.
Читай правильно - то все машины должны вручную обновится.
То бишь после нажатия кнопы "обновить" перечитать файл описания стеллажа. А не менять данные ручками на каждой машине.
Ну и 10 раз набирать одно и тоже.... ведь там не только количество полок.
ведь там не только количество полок.
------
Опять - СТОП.
Ты пишешь - стелажи (и количество полок?) надо редактировать отдельно.
Простой вариант тебе предложен.
Куда и как дальше - отдельная тема.
Пока же тебе предлагается в гриде вбить количество полок и скинуть в отдельный xml-файл... ну или в базу.
Имеете ввиду что то типа этого?
см. аттач
То бишь в коде нужно будет накидывать все элементы, делать самому выбор одного из них, а потом еще передавать туда "двухмерный" массив с данными
не нужно :)
Это просто не канает. Пользователю будет показан текст, но ему еще нужно/можно вводить некие дополнительные данные.
Ну это уже можешь сделать так, как тебе надо ;)
Прикреплённые файлы
см. аттач
Код не ожидал. Мне были интересны какие то другие идеи. Но спасибо 
, может стащу что нибудь, пока только принцип глянул.
С ItemsControl я тоже сделал, но похоже нужно искать что то другое. Еще нет всех биндингов, а уже медленовато.
TextBox наверняка Window handle имеет. А их нужно на странице под пол.тысячи. 10 шкафов по 21 полке, на полке по два поля ввода - это одна из конфигураций для робота.
В примере проблема та же самая что и у Мурки - сложно обеспечить одинаковость стеллажей. Сейчас только три параметра - надо все перебивать либо извращаться если стеллаж с первого места перемещают на третье.
Ну и "код стеллажа" должен быть одинаковым, что в редакторе, что в использовании.
Я начинал с плюсов, но обратно уже ни за что.
Но это тема совершенно новой и бесполезной дискуссии
Еще нет всех биндингов, а уже медленовато.
А их нужно на странице под пол.тысячи.
Ну так и я о том же. Вдоволь намучавшись с C# (гриды из тысяч строк с туевой хучей активных элементов), написал свой API под плюсами для данной херни (все летает), кнопки, чекбоксы, и т.д. Но данное обсуждение наблюдаю с интересом, может все реально было и под C#, просто руки у меня из ж..ы. :))
гриды из тысяч строк с туевой хучей активных элементов
на чистом шарпе есть гриды и на "миллионы строк" без задержки.
Тоже самое было и для "плюсов". Делали срец. редактор, вначале, на "окошках". После определенного предела окошек, все замедлялось, как все окошки выбросили, сразу все залетало.
Если Вас так зудит открывайте тему, "что лучше С# или C++" и наслаждайтесь бесконечными дискуссиями 
С ItemsControl я тоже сделал, но похоже нужно искать что то другое. Еще нет всех биндингов, а уже медленовато. TextBox наверняка Window handle имеет. А их нужно на странице под пол.тысячи. 10 шкафов по 21 полке, на полке по два поля ввода - это одна из конфигураций для робота.
это есть такое у WPF. если нужно много контролов на экране - тормоз полнейший.. Qt в помощь.
гриды из тысяч строк с туевой хучей активных элементов
-----
Угу... знакомое дело... и решение - тоже стандартное - строчный редактор, один в один момент времени - бо, больше одной строки за раз все одно не редактируешь.
Дело не в Плюсах или в Шарпе, а в подходе - 20 строк на странице - крути как хочешь, много - пора думать как делать.
Т.е. полки у тебя всегда есть и их всегда мах. 20 штук?
Тогда непонятны твои терзания - делаешь в конструкторе заполнение стелажа полками по максимуму - просто резервируешь массив под 20 обьектов и не мучаешься.
Надо покласть книгу по идексеру - клади. Надо получить ее по индексеру - получай.
Единственная проблема - пустая полка. Ну так научи ее говорить - "я есть пустая полка".
Проблема будет с итератором - там, скорее всего, пустые будет нужно игнорировать...
Сейчас только три параметра
Какие 3 параметра? В моем примере есть 2 вложенных коллекции и все.
надо все перебивать либо извращаться если стеллаж с первого места перемещают на третье.
Извращаться? Надо просто в коллекции перетащить айтем с 1-ого на 3-е место. В чем там извращение?
Ну и "код стеллажа" должен быть одинаковым, что в редакторе, что в использовании.
О каком коде ты говоришь? В моем примере нет никакого кода стеллажа :) Есть только данные, которыми этот стеллаж описывается и описание айтема как эти данные отображать.
Комбинации разные бывают, вот самая "тяжелая".
Для переделки моего примера под эту форму нужно минут 20 :) Справа от "Sample name" - просто два эдит бокса?
Ну и у меня ничего не тормозит :)
Какие 3 параметра?
Надо просто в коллекции перетащить айтем с 1-ого на 3-е место.
перетащить - не заметил как
О каком коде ты говоришь?
ну да кода никакого нет, но всё рисуется
На одной странице должна быть вся картинка, на других только то что в рамке и на третьей полка отдельно. "Copy/paste" не разрешено
Программа переписываться не должна.
Для переделки моего примера под эту форму нужно минут 20
А переделывать прогу низзя
Все должен делать заказчик самостоятельно.
Раз Вы так любите что то писать - я пока не могу придумать удобный способ выбора элементов (полок) с помощью мышки / клавы и при наличии скроллера. Впрочем идеи будет тоже достаточно.
У меня на домашнем десктопе тоже ничего не тормозит. Но там 16 гигов памяти и одна студия. На работе памяти меньше, студий загруженных больше, и лапоть не последней модели, но с PCMCIA.
Т.е. 3 параметра - это имя, описание и количество слотов?
Ну так это просто проперти в ModelView. Я в упор не вижу никаких проблем.
перетащить - не заметил как
Перетащить в коллекции. Т.е. при срабатывании эвента вызываешь фанкцию модели, и в этой функции делаешь следующее:
Racks.Move(oldIndex, newIndex);
И все, GUI отрисуется без тебя :)
На одной странице должна быть вся картинка, на других только то что в рамке и на третьей полка отдельно. "Copy/paste" не разрешено
Ну и в чем проблема?
ModelView у тебя одна и та же, просто по-разному отображаешь. От куда ты вообще взял Copy/Paste?
У тебя просто одна ModelView, которая отображается на несколько View.
Сделал заказчик еще один шкаф с полками и хочет добавить его на два рабочих места....Программа переписываться не должна.
Ну если заказчик сделал еще один шкаф, то от просто добавляет его в коллекцию шкафов.
Программа при этом не будет переписываться.
Более того, ModelView можно сериализовать в XML (или сохранить в БД) и заказчик сможет добавлять шкафы и менять их порядок даже не запуская программу.
А переделывать прогу низзя
Ты посмотри на "переделки" :) Я там просто добавил новые поля в ModelView и изменил отображение ;)
Раз Вы так любите что то писать - я пока не могу придумать удобный способ выбора элементов (полок) с помощью мышки / клавы и при наличии скроллера. Впрочем идеи будет тоже достаточно.
Вместо вертикального стека (ItemsControl) сделай ListBox. Если в течении дня будет время, то накидаю примерчик...
Перетащить в коллекции.
Юсер, батенька юсер для начала....
просто по-разному отображаешь
То бишь вьювы копировать и модифицировать. Повторю еще раз "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 (ну может быть еще конвертеры могут понадобиться :))
Я вижу 1 вариант:
И как его присобачить к Вашим вариантам?
одного ViewModel достаточно, чтобы отобразить все данные
Что то Вы не туда смотрите или скорее у нас разные "ограничения".
"Данные" хранятся и сериализуются в коллекциях. Любая коллекция должная "напрямую" отображаться. конфигурация - одна коллекция и данные другая "коллекция". Загруженные данные могут меняться, соответственно записываются автоматом в файл. При данной реализации эти две коллекции придется каким то образом "смешивать", нужно следить/выбирать реализацию чтобы чего лишнего не записалось.
Я тользуюсь сериализатором от MS. Не парюсь на этот счет
На да - если данные нужно делать публичными исключительно для сериализации, напишем коммент - "руки прочь" и не паримся
А уж не дай бог что то переименовать, комментов не напасёшся.
Да нет, это просто user frendly
А других вариантов у меня просто нет. Можно еще конечно и скрипт какой то писать в этом едитбоксе, тогда все без проблем будет 
Я не совсем понимаю задачу...
Ну вот одной кнопой я могу накидать сколько мне надо одинаковых стеллажей, при изменении описания стеллажа они все могут обновится другой кнопой.
Я тользуюсь сериализатором от MS.
----
Что-то у меня было из простых вопросов...
Вроде так - наследовалсь какая-то коллекция или словарик из шаблонных и добавлялась пара пропертей.
Все это надо было сериализовать.
Коллекция - сериализовалась, проперти - никак.
Что то ты не так делаешь.
-----
Не, не Я.
У нас босс дал команду зарезать известные внешние сайты.
Где-то под 80% инета просто недоступно.
Возможно что не срабатывает.
На мелкомягкие форумы тоже не залогинится.
Могу мейл скинуть.
-----
В личку, плс, скинь - в понедельник утром отправлю.
Secure Connection Failed
An error occurred during a connection to files.fm. SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Все бровсеры мои перепробовал ИЕ, ФФ, Хроме - везде одинаково, даже игнорировать не даёт.
--
Вроде нашел
website blocking technology has blocked outgoing or incoming
communication between your computer and a malicious Internet Protocol
(IP) address
И как его присобачить к Вашим вариантам?
Описал же :)
У каждой колонки есть проперти Visibility. Просто связываешь эту проперти со значением чекбокса (через конвертер).
"Данные" хранятся и сериализуются в коллекциях. Любая коллекция должная "напрямую" отображаться. конфигурация - одна коллекция и данные другая "коллекция". Загруженные данные могут меняться, соответственно записываются автоматом в файл. При данной реализации эти две коллекции придется каким то образом "смешивать", нужно следить/выбирать реализацию чтобы чего лишнего не записалось.
Собвершенно не важно где и как хранятся данные. Важно, чтобы UI умел отображать ViewModel, каким образом будет наполняться ViewModel - это уже задача Model.
На да - если данные нужно делать публичными исключительно для сериализации, напишем коммент - "руки прочь" и не паримся
Всегда пожно разбить себе голову о пол во время молитвы :) Если тебе надо сериализовать приватные данные - вооружись DataContact'ом. Ну и везде можно менять имя сериализируемого параметра.
Описал же :)
Меня не техническая сторона интересует, тут проблем как бы нет.
То бишь впиндюриваем каждой колонке еще по паре чекбоксов и дарагой юсер кликай.
Собвершенно не важно где и как хранятся данные.
Это смотря с какой стороны посмотреть. но как то не хочется чтобы в часть конфигурации попали рабочие данные и наоборот.
вооружись DataContact'ом
Жалко не записал где там проблемы возникли. По крайней мере, нужно везде атрибуты раставлять.
Ну и везде можно менять имя сериализируемого параметра.
Это из теории или из практики? И без дополнительных атрибутов? А как насчет namespace? Тоже меняем как хошь?
Меня не техническая сторона интересует, тут проблем как бы нет.
То бишь впиндюриваем каждой колонке еще по паре чекбоксов и дарагой юсер кликай.
А в чем тогда проблема? :)
Это смотря с какой стороны посмотреть. но как то не хочется чтобы в часть конфигурации попали рабочие данные и наоборот.
Давай тогда разберем, что ты называешь конфигурацией, а что рабочими данными?
Количество стеллажей - это конфигурация? А имя стеллажа - это конфигурация? А количество полок на стеллаже? Название книги? Любая другая информация на полке (количество слотов, итд)?
Жалко не записал где там проблемы возникли. По крайней мере, нужно везде атрибуты раставлять.
Врядли в каком-либо другом сериализаторе можно обойтись без надстроек :)
[DataMember(IsRequired = true, Name = "third_party_device_id")]
public string ThirdPartyDeviceId { get; set; }
[DataMember(IsRequired = true, Name = "processing_time")]
private string processingTime;
[IgnoreDataMember]
public DateTime ProcessingTime
{
get { return DateTime.Parse(processingTime); }
set { processingTime = value.ToString("yyyy-MM-dd HH:mm:ss"); }
}
Это из теории или из практики?
Из практики.
И без дополнительных атрибутов?
Код привел. Там вроде все понятно :) И переименовывается так как надо и, класс работает с DateTime, а сериализуется в строку (мне это надо было для JSON сериализации. Собственно говоря из-за JSON сериализации я и взял DataContract).
А как насчет namespace? Тоже меняем как хошь?
А в чем с ними проблема? Там тоже вроде все задается. Но тут я много опыта не имею, не люблю namespace :)
А в чем тогда проблема? :)
В любви к юзверю
Давай тогда разберем, что ты называешь конфигурацией, а что рабочими данными?
сделали рабочие шкафы "физически", скажем даже место для двух табличек сделали - вот это и есть конфигурация. А вот конкретные таблички и всё что на полке лежит - это уже данные.
Вота - "пустота" - конфигурация: текст, цифры, цвет - данные. Выбор тоже относительно просто делается, а то пугали Selector-ом
В Xaml-е так получается. Приходится правда дофига писать, но иначе UserControl-ы не хотят у меня работать.
Configuration ="{Binding DataContext.MagazinesConfiguration, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type local:EditSamplesPage}}}"
ItemSource ="{Binding DataContext.MagazinesData, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type local:EditSamplesPage}}}"
Врядли в каком-либо другом сериализаторе можно обойтись без надстроек :)
XmlSerializer не требует ничего. А писать в атрибутах имена полей - сорри 
. В самопальном сериализаторе, тоже никакх аттрибутов не требуется по умолчанию. Да, изменить,что по умолчанию - тут конечно надо, ну типа поле проигнорировать.
не люблю namespace
ну без него как бы никак. Хотя можно и не писать, да Style guide не позволяет. Да и немецкие названия я сразу заменяю на английские. На этом и накололся.
namespace ABC.MagazineManager
{
internal class MagazineCore
{