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кб в одном файле. Но без удобного редактора Я это делать не горю желанием, а редактор писать довольно долго.
Очень даже смущают.
-----
Чем? нормальное состояние коллекции после создания - пустая коллекция.
Конфигурация - это конфигурация. А данные - это данных.
-----
Хммм... с точки зрения програмы - это все данные.
Ты предлагаешь:
Открыть файл конфигурации и прочитать про стелажи.
Открыть файл полок и прочитать про полки.
Связать полки со стелажами. ( Как?)
Я предлагаю:
Открыть файл конфигурации.
Читать секцию простелажи.
Читать секцию про полки.
Связывать, если достаточно информации или читать секцию про детали связывания.
Это то как раз самое простое было.
-----
Достаточно удобный и не слишком привязанный к структуре? нее, долго...