Здравствуйте, LF, Вы писали:
RT>>1. Куча столбцов/колонок RT>>2. Границы ячеек могут быть различной толцишы и различного цвета RT>>3. Сетка не регулярная. Т.е. строки/столбцы/ячеки могут быть объеденены RT>>4. Куча теста в ячейках написанных различными шрифтами RT>>Необходимо реализовать скроллинг как в Excel, т.е. при изменении позиции ползунка содержимое контрола полностью перерисовывается. LF>И каким образом вы решали это на wpf? Надеюсь не рисовали на Canvas?
Не до Canvas дело не дошло. Но пытались сделать 1001 способом начиная от импользования grid и заканчивая отрисовкой все вручную с использованием geometry.
В итоге ни одно решение не смогло даже достойно конкурировать с тупой отрисовкой на graphics.
Здравствуйте, RadmirT, Вы писали:
RT>По поводу скорости работы я с тобой не согласен. RT>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
Это зависит от размера элемента. Постоянно перерисовывать кнопочку 100 x 100 — не проблема. Реальный слив вот где происходит. Допустим, что нам нужно рисовать на элементе какую-нибудь карту или, скажем, координатную сетку графика. Размеры такого элемента могут быть очень велики, например, 200000 x 1000. Понятно, что такой элемент не виден весь. Организация рендеринга в WPF такова, что у меня появляется выбор: либо нарисовывать весь элемент в OnRender, либо добавить полосы прокрутки и перерисовывать видимую часть элемента при изменении их положения. Так вот в первом случае, появляется слишком много графических примитивов. Еще бы! Там же 200 штук пикселов по горизонтали! И это тормозит. Второй вариант — перерисовка при прокрутке — тоже тормозит, если область видимости будет достаточно велика, например, 1680 x 1050. По опыту работы с Windows Forms, там такое организовать проще, потому что она более ориентирована именно на рисование, а не на компоновку пользовательского интерфейса. Справедливости ради стоит отметить, что такие задачи редки и просто потребуют чуть больше геморроя в коде. И потом, это все-таки не приоритетное направление WPF.
RT>Не до Canvas дело не дошло. Но пытались сделать 1001 способом начиная от импользования grid и заканчивая отрисовкой все вручную с использованием geometry. RT>В итоге ни одно решение не смогло даже достойно конкурировать с тупой отрисовкой на graphics.
А вот у этих ребят получилось http://xceed.com/Grid_WPF_Demo.html http://devexpress.com/Products/NET/Controls/WPF/Grid/
хотелось бы посмотреть на аналогичные решения на базе WinFoprms.
Здравствуйте, LF, Вы писали:
RT>>Не до Canvas дело не дошло. Но пытались сделать 1001 способом начиная от импользования grid и заканчивая отрисовкой все вручную с использованием geometry. RT>>В итоге ни одно решение не смогло даже достойно конкурировать с тупой отрисовкой на graphics. LF>А вот у этих ребят получилось LF>http://xceed.com/Grid_WPF_Demo.html LF>http://devexpress.com/Products/NET/Controls/WPF/Grid/ LF>хотелось бы посмотреть на аналогичные решения на базе WinFoprms.
1. У них ОТЛОЖЕННЫЙ скролинг.
2. Это обычный DataGrid т.е. нельзя задать нерегулярную сетку.
RT>1. У них ОТЛОЖЕННЫЙ скролинг.
Нет, вожу ползунком — содержимое перерисовывается.
RT>2. Это обычный DataGrid т.е. нельзя задать нерегулярную сетку.
Может быть в данных конкретных нельзя, что не факт, может этого нет просто в примерах.
Главное тут, что технология позволяет делать сложный UI, а то что не реализовали нерегулярную сетку — дело времени и запросов пользователей.
LF>Может быть в данных конкретных нельзя, что не факт, может этого нет просто в примерах.
Нет нельзя совсем. Перед тем как начать делать свою собсвенную реализацию мы перепробывали кучу компонентов.
В итоге не один WPF или не обеспечивал достаточной скрости или не позволял реализовавать spreadsheet
LF>Главное тут, что технология позволяет делать сложный UI, а то что не реализовали нерегулярную сетку — дело времени и запросов пользователей.
Для бизнес приложений главное не "няшки" а адекватная скрость работы.
RT>Нет нельзя совсем. Перед тем как начать делать свою собсвенную реализацию мы перепробывали кучу компонентов. RT>В итоге не один WPF или не обеспечивал достаточной скрости или не позволял реализовавать spreadsheet
Можно реализовать свой. Я правильно понимаю, что в представленных примерах не устраивает лишь отсутствие нерегулярной сетки?
RT>Для бизнес приложений главное не "няшки" а адекватная скрость работы.
Не увидел тормозов в представленных примерах и выглядит красиво, начальство должно быть довольно.
Здравствуйте, LF, Вы писали:
LF>Можно реализовать свой. Я правильно понимаю, что в представленных примерах не устраивает лишь отсутствие нерегулярной сетки?
Эта "мелочь" является камнем преткновения.
Размещение приметива в WPF довольно затратная операция.
например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже саимое сделать в WinFroms.
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, Codechanger, Вы писали:
RT>>>По поводу скорости работы я с тобой не согласен. RT>>>В случае если необходимо постоянно перерисовавать содержимое элемента управления, WPF сливает WinForms
C>>UseCase в студию.
RT>Рисуем Grid а ля Excel
Тогда используйте Excel с .NET расширением. Если пользователям нужен Excel, то ничего лучше excel придумать не получится.
Для контролов в экселе вполне можно кидать на лист как winforms компоненты, так и WPF (через ElementHost)
G>Тогда используйте Excel с .NET расширением. Если пользователям нужен Excel, то ничего лучше excel придумать не получится.
G>Для контролов в экселе вполне можно кидать на лист как winforms компоненты, так и WPF (через ElementHost)
Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
RT>Размещение приметива в WPF довольно затратная операция.
Я в курсе, поэтому создание элементов надо минимизировать и применять трансформацию уже к существующим.
RT>например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже саимое сделать в WinFroms.
Какое это имеет отношение к нерегулярной сетке?
RT>>например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже саимое сделать в WinFroms. LF>Какое это имеет отношение к нерегулярной сетке?
Прямое. Если сетка у нас регулярная. То мы вполе можем обойтись трансформацииями.
Для нерегулярной сетки алгоритм будет "чуть сложнее". Нуюно будет еще удалять/добавлять примитивы.
RT>Прямое. Если сетка у нас регулярная. То мы вполе можем обойтись трансформацииями. RT>Для нерегулярной сетки алгоритм будет "чуть сложнее". Нуюно будет еще удалять/добавлять примитивы.
Замечательно, а теперь простой Grid c RowSpan и ColumnSpan позволяет строить нерегулярную сетку.
В чем сложности, зачем обязательно надо отрисовывать через примитивы?
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, gandjustas, Вы писали:
G>>Тогда используйте Excel с .NET расширением. Если пользователям нужен Excel, то ничего лучше excel придумать не получится.
G>>Для контролов в экселе вполне можно кидать на лист как winforms компоненты, так и WPF (через ElementHost)
RT>Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
Думаю дешевле чем 10k ваших программ и поддержка попроще будет.
При таком кол-ве можно громадные скидки выбить, от 50%.
Здравствуйте, LF, Вы писали: LF>Замечательно, а теперь простой Grid c RowSpan и ColumnSpan позволяет строить нерегулярную сетку. LF>В чем сложности, зачем обязательно надо отрисовывать через примитивы?
В этом случае мы молучаем еще более сильные тормоза.
Т.к. при каждом изменении положения ползунка. WPF будет "образмеривать" ВСЕ дерево визуальных объектов. Это в разы затратнее чем добавление нового примитива.
Здравствуйте, RadmirT, Вы писали:
RT>Размещение приметива в WPF довольно затратная операция. RT>например, попробуй в WPF разместить на эелменте управления 10000 случайных отрезков, и попробуй тоже самое сделать в WinFroms.
Я пробовал в WPF, всё нормально pan'ится, scroll'ится, zoom'ится. А что там в WinForms?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, RadmirT, Вы писали:
RT>>Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
G>Думаю дешевле чем 10k ваших программ и поддержка попроще будет.
G>При таком кол-ве можно громадные скидки выбить, от 50%.
Из за единственной функции "возможность отображать данные на нерегулярной сетке" покупать Excel. Это как забивать микроскопом гвозди.
Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой.
Q>Я пробовал в WPF, всё нормально pan'ится, scroll'ится, zoom'ится. А что там в WinForms?
После того как эти примитивы разместятся, то все летает. А вот сам процесс размещения ужасно тормозной.
А для нерегулярной сетки приходится постоянно добавлять/удалять примитивы.
Здравствуйте, RadmirT, Вы писали:
RT>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, RadmirT, Вы писали:
RT>>>Идея великолепна, мой капитан. Только сколько нужно отвлить денег чтобы купить 10k лицензий для Excel.
G>>Думаю дешевле чем 10k ваших программ и поддержка попроще будет.
G>>При таком кол-ве можно громадные скидки выбить, от 50%.
RT>Из за единственной функции "возможность отображать данные на нерегулярной сетке" покупать Excel. Это как забивать микроскопом гвозди.
Сходу могу сказать что еще захотят пользователи:
1)Печать как в excel
2)быстро строить графики\отчеты
3)экспорт в сам excel и загрузку из него
4)Выделять и копировать ячейки как в excel
RT>Да и на несколько порядков дешевле заплатить 100-200К рублей за разработку, чем покупать 10k лиценнзий даже с 50% скидкой.
100-200 тыр за разработку хватит чтобы покрыть 0.001% функциональности excel. Пользователям обычно нужно побольше.
Есличе — сам сталкивался с таким проектом. Чем дальше писали, тем больше становилось понятно что пользователям нужен именно excel.
В итоге для нескольких отделов таки написали расширения excel, так они нарадоваться не могли.
Естественно сумма разработки многократно превысила сумму покупки лицензий на офис на всю организацию. И кстати офис у многих уже стоял.
