Комментарии 54
Это все классно, но дорого для собственных проектов.
Скажите, а коммьюнити версии нет? (без 30-дневных триалов и тп.)
Скажите, а коммьюнити версии нет? (без 30-дневных триалов и тп.)
Ответил чуть ниже, как обычно, промахнулся кнопкой =)
В дополнение к триалу, мы предлагаем 60-дневный манибек. Это значит, что вы можете в течение двух месяцев отказаться от покупки и получить обратно полную стоимость приобретенных продуктов. Это достаточный срок для проверки окупаемости расходов. За это время вполне можно написать XAF приложение для учета рогов и копыт и продать знакомому директору ООО “Рога и Копыта” — затраты на DXperience Universal окупятся.
Да, эта извечная тема — дорого ли использовать сторонние компоненты в своих проектах, и когда стоит их покупать, а когда нет. Похожие обсуждения у нас были раньше здесь:
habrahabr.ru/company/devexpress/blog/103836/ и в комментариях к habrahabr.ru/company/devexpress/blog/110194/
Если вкратце — продукты ASP.NET и WinForms можно покупать и по отдельности, если есть желание использовать только 1-2 из них; плюс у нас есть бесплатные версии некоторых наших продуктов и возможность сделать что-то полезное для коммьюнити. Для подробностей, почитайте, пожалуйста, вот этот мой комментарий:
habrahabr.ru/company/devexpress/blog/110194/#comment_3515818
habrahabr.ru/company/devexpress/blog/103836/ и в комментариях к habrahabr.ru/company/devexpress/blog/110194/
Если вкратце — продукты ASP.NET и WinForms можно покупать и по отдельности, если есть желание использовать только 1-2 из них; плюс у нас есть бесплатные версии некоторых наших продуктов и возможность сделать что-то полезное для коммьюнити. Для подробностей, почитайте, пожалуйста, вот этот мой комментарий:
habrahabr.ru/company/devexpress/blog/110194/#comment_3515818
я так ждал Office 2010 тем в этой версии =(
спасибо хоть за WPF TreeList
спасибо хоть за WPF TreeList
Ребята юзаю ваши компоненты с удовольствием!
Сейчас пользуюсь вашими WPF компонентами. Если честно после WinForms они сильно убоги и ОЧЕНЬ снижают отклик программы на действия(еще и много всяких ноухау решений для реализации казалось бы стандартного функционала). Я понимаю, что компоненты наворочены и тяжелы, но даже после загрузки программа подтормаживает при каждом ре-рендере окна… Вообщем сейчас уже отказаться не получится, но на будущее сперва буду проверять, затем доверять..=(
Печально об этом слышать :-( К сожалению, такое можно было ожидать при использовании новой технологии.
Вопреки ожиданиям пользователей и их мнению о том, что приложения на WPF будут работать быстрее чем на винформс, это не так. Приложение, написанное на WPF, в целом будет медленнее — особенно если это что-то показывающеее данные в виде списка (как грид). Кроме того, сложный или неудачный лейаут приложения может являться причиной тормозов. Например, повсеместное использование биндингов может понизить производительность приложения. А это очень часто случается, в частности, при использовании MVVM.
Ещё есть один частный случай: когда в системе установлено и работает приложение, опрашивающее другие окна через UIAutomation (так называемый Automation Client). В этом случае WPF-приложение ооочень сильно тормозит, особенно при показе менюшек. Это официально признаный баг Майкрософт и они обещали его пофиксить.
Однако хочу заметить, что в целом наши компоненты работают достаточно шустро в WPF — в противном случае мы получили бы много негативных отзывов от наших пользователей, а это не так. Поэтому мне хотелось бы поподробнее разузнать про ваше приложение, архитектуру, ваш лейаут. Если вы ещё не пробовали обращаться в наш суппорт по поводу тормозов, то обязательно напишите. Очень может быть, что удастся диагностировать и устранить проблему. Буквально вчера у нас был пользовательский проект, который удалось соптимизировать со 130 секунд до одной! Так что шанс есть :-)
Что же касается наших контролов, то мы работали, работаем и будем работать над ними :) И над тем, чтобы линейка была более полной, и чтобы они были удобнее, и чтобы работали быстрее… Кстати, а какого функционала вы сейчас ждёте от наших ВПФ компонентов больше всего?
Вопреки ожиданиям пользователей и их мнению о том, что приложения на WPF будут работать быстрее чем на винформс, это не так. Приложение, написанное на WPF, в целом будет медленнее — особенно если это что-то показывающеее данные в виде списка (как грид). Кроме того, сложный или неудачный лейаут приложения может являться причиной тормозов. Например, повсеместное использование биндингов может понизить производительность приложения. А это очень часто случается, в частности, при использовании MVVM.
Ещё есть один частный случай: когда в системе установлено и работает приложение, опрашивающее другие окна через UIAutomation (так называемый Automation Client). В этом случае WPF-приложение ооочень сильно тормозит, особенно при показе менюшек. Это официально признаный баг Майкрософт и они обещали его пофиксить.
Однако хочу заметить, что в целом наши компоненты работают достаточно шустро в WPF — в противном случае мы получили бы много негативных отзывов от наших пользователей, а это не так. Поэтому мне хотелось бы поподробнее разузнать про ваше приложение, архитектуру, ваш лейаут. Если вы ещё не пробовали обращаться в наш суппорт по поводу тормозов, то обязательно напишите. Очень может быть, что удастся диагностировать и устранить проблему. Буквально вчера у нас был пользовательский проект, который удалось соптимизировать со 130 секунд до одной! Так что шанс есть :-)
Что же касается наших контролов, то мы работали, работаем и будем работать над ними :) И над тем, чтобы линейка была более полной, и чтобы они были удобнее, и чтобы работали быстрее… Кстати, а какого функционала вы сейчас ждёте от наших ВПФ компонентов больше всего?
Спасибо за ответ. В саппорт обращались и ребята помогли. Например использовали AutomationFix с ваших форумов и подгрузили часть сборок при первой загрузке программы, совместив это с сплеш скрином. Может и здорово было бы дать вам приложение на проверку, но оно уже не маленькое, состоит из нескольких проектов и работает с базой DB2, для работы с которой нужны еще и отдельные драйвера… Недумаю, что стоит отнимать у вас время на разбор всего этого дела. Используем MVVM, layout собираем сами, ваш с сплиттерами не используем… Он здоровский, но когда все подряд тормозит-хочется как можно меньше использовать стороннего, боязно =)… Гриды ваши очень нужны, потому что штатным функционалом очень экономят время(фильтры, саммари), так же ваши бары, три лист. Вообще именно сейчас конкретная проблема лишь одна, но достаточно глобальная: имеется одно окно с таб контролом, в табах подгружаем юзер контролы с вашими контролами внутри. Так вот, после открытия нескольких таких табов-переключения между ними занимают длительные промежутки(до 2-3 секунд), что явно неочень, если мы хотим сделать отзывчивую программу, а она тормозит при рендере(не при всяких операциях с сервисами или базой..) В табах при этом все время одни и те же ваши контролы(из одних сборок). При замене ваших контролов стандартными «аналогами»-табы переключаются быстро. Кстати при релизной сборке-ваши контролы работают намного шустрее(наверно у вас там куча #If DEBUG?..).
Вот… Еще проблема-это ваши «внезапные» баги. Например вы выпускаете новый патч, хочется перекомпилировать проект с исправленными багами и добавленными фичами и закинуть клиенту, а вот и нет, то, что работало в прошлой версии до патча-вдруг перестало работать. Например в одном из 2010 vol было просто ужастно получить бар контрол с проблемной поддержкой горячих клавиш(которые уже работали у нашего клиента и перестали после патча..) И это был не единственный случай. Понятно, что все это-человеческое и все делаем ошибки, но это релиз патч, хочелось бы, чтоб уж он то не портил то, что сам не исправляет. В WinForms у вас всетки кажется все более гладко. В общем вы хорошая компания и саппорт у вас порядочный, и компоненты-нужные, я ЗА ваше развитие, потому тут и говорю про свои проблемы, вы уж не обижайтесь.
Вот… Еще проблема-это ваши «внезапные» баги. Например вы выпускаете новый патч, хочется перекомпилировать проект с исправленными багами и добавленными фичами и закинуть клиенту, а вот и нет, то, что работало в прошлой версии до патча-вдруг перестало работать. Например в одном из 2010 vol было просто ужастно получить бар контрол с проблемной поддержкой горячих клавиш(которые уже работали у нашего клиента и перестали после патча..) И это был не единственный случай. Понятно, что все это-человеческое и все делаем ошибки, но это релиз патч, хочелось бы, чтоб уж он то не портил то, что сам не исправляет. В WinForms у вас всетки кажется все более гладко. В общем вы хорошая компания и саппорт у вас порядочный, и компоненты-нужные, я ЗА ваше развитие, потому тут и говорю про свои проблемы, вы уж не обижайтесь.
Спасибо за конструктивный фидбэк.
По поводу таб контрола, тут ребята подсказывают: попробуйте выставить DXTabControl.DestroyContentOnTabSwitching=«false»
по идее, должно помочь.
По поводу таб контрола, тут ребята подсказывают: попробуйте выставить DXTabControl.DestroyContentOnTabSwitching=«false»
по идее, должно помочь.
Только добрался до хабра… Спасибо за ответ, только у нас там не ваш таб контрол, а стандартный с слегка измененным стилем. Делали по аналогии с этим: blogs.intuidev.com/post/2010/02/15/WPF-TabControl-series-Part-4-Closeable-TabItems.aspx, так что это не в табе дело, а в контенте таба. Почитал про DestroyContentOnTabSwitching, завтра на работе попробую сделать тестовую сборку с вашим контролом, может это решит проблемы с перерисовкой(хотя ваш таб контрол наверно потяжелее будет и общее время открытия нового таба в первый раз-возрастет… посмотрим =)) По-любому- большое спасибо за ответы и за то, что вам не все равно.
Переделал, добавил DestroyContentOnTabSwitching=«false» и все это дело действительно стало переключаться очень быстро =) Но… Теперь время загрузки каждого таба выросло до 3ех секунд, что, конечно, совсем неприятно =( Я новичек в WPF, так что может ещё чего незнаю про оптимизации?.. Сейчас из явных оптимизаций я при деплое прогоняю сборки через ngen при первом запуске новой версии у клиента (http://stackoverflow.com/questions/443955/is-it-possible-to-use-ngen-with-clickonce-deployment/879185#879185) и использую UIAutomationFix (http://social.msdn.microsoft.com/Forums/en/windowsaccessibilityandautomation/thread/6c4465e2-207c-4277-a67f-e0f55eff0110) Может что-то можно сделать, чтоб поведение обычного таб контрола было схожим с DestroyContentOnTabSwitching=«false»?.. То есть ваши отендеренные контролы оставались в окне и не перерисовывались (как я понял моя неприятная проблема с WPF тут в этом)
В смысле тут я описал случай с заменой стилизованного стандартного таб контрола и таб айтема на ваши аналоги.
Со стандартным таб контролом такое не получится: эта логика реализована нативно только в нашем табконтроле. Кстати, у нашего таб контрола тоже можно кастомизить тему — вот пример www.devexpress.com/example=E3168
А по поводу долгой загрузки: 3 секунды — это, конечно, перебор. Причем дело явно не в самом таб контроле, а в контенте табов. Может быть всё-таки пришлёте свой тестовый проект к нам в суппорт, мы его посмотрим — вдруг удастся найти то, на что уходит столько времени?
А по поводу долгой загрузки: 3 секунды — это, конечно, перебор. Причем дело явно не в самом таб контроле, а в контенте табов. Может быть всё-таки пришлёте свой тестовый проект к нам в суппорт, мы его посмотрим — вдруг удастся найти то, на что уходит столько времени?
Странно… Загрузка замедлилась, после того, как я заменил стандартный на ваш и отключил мои стили на таб контрол. Потому и подозрение пало на ваш контрол, другого то ничего не изменялось… Как только начнут жаловаться клиенты-пришлю, выхода у меня не будет =) Пока все не так критично. Ещё раз спасибо за отзывчивость.
Всегда пожалуйста! Если что, задавайте свои вопросы в Суппорт Центр или в habrahabr.ru/company/devexpress/questions/
Задал там вопрос. Однако недостаток в том, что как я понимаю вопросы/ответы не будут видны другим. Может быть создадите топик, в котором в комментариях можно будет обсуждать проблемы? Вот как этот например :)
Странно. Может после того, как мы ответим, он станет виден? Сейчас проверим.
Теперь видно: habrahabr.ru/company/devexpress/questions/98/
О, кстати! Я тут обновился до последней версии ваших компонентов (11.1.6), переделал все под ваши табы, удалил Automation Fix код и… Все заработало быстро. Похоже ваши инжинеры что-то подкрутили, иначе даже незнаю. Сами в саппорте посоветовали фикс, который в свое время что-то подправлял, а теперь удалив его, получил отличное отзывчивое приложение. Надеюсь так и оставят, будущий фикс теперь ставить страшно =)
Спасибо за проделанную работу по оптимизациям.
Спасибо за проделанную работу по оптимизациям.
Вот и мы после просмотра сэмплов решили пока с впф повременить. Уж больно неповоротливо по сравнению с винформами.
Пользуясь случаем, хочу выразить респект за оперативную поддержку. Без нее компоненты не были бы настолько привлекательны полезны. Пользуемся в основном WinForms.
А в новом CodeRush не появилось фичи с генерацией имени переменной по типу? Пример: ClassA -> classA
Или она давно есть, а я не нашел? =)
Или она давно есть, а я не нашел? =)
Такая фича есть, можно сгенерировать имя переменной по типу следующим образом. Набираем тип, например ClassA а затем жмем Ctrl + A и получаем: ClassA classA.
Вот блин… А я в базе знаний порылся в свое время и нашел только, что это планируется реализовать. Спасибо!
В документации вроде бы есть топик Auto Declare — можно здесь подробней почитать, там еще ссылка на то как поменять стиль для полей и локальных переменных.
НЛО прилетело и опубликовало эту надпись здесь
О! Я к вам с вопросами. про XtraReport родимый.
1. Появились ли Merged Cells наконец?
2. Производительность при добавлении чарта (простые линии) где 2 — 3 тысячи значений. Сейчас имеем проблемы т.к. генерация чарта в отчете в PDF не удовлетворяет совершенно… Не работали над этим? Вообще что можете посоветовать если в чарте тысячи значений, может какие то есть хаки.
3. Появилась ли возможность генерить чарт в отчете с повышенным DPI? в 2010 версии что ни меняли — на выходе в PDF размытое все.
4. Появилась ли возможность генерировать merged report (из нескольких разных отчетов один) не только в PDF (через эвент before print как в примере) но и в XLS (на разные листы)?
Пусть конечно есть проблемы, но ваши отчеты все равно рулят. Пробовал Telerik — мама дорогая, таких тормозов поискать надо. Считаю XtraReport лучшими report tools на сегодняшний день для дотнета.
Желаю успехов!
1. Появились ли Merged Cells наконец?
2. Производительность при добавлении чарта (простые линии) где 2 — 3 тысячи значений. Сейчас имеем проблемы т.к. генерация чарта в отчете в PDF не удовлетворяет совершенно… Не работали над этим? Вообще что можете посоветовать если в чарте тысячи значений, может какие то есть хаки.
3. Появилась ли возможность генерить чарт в отчете с повышенным DPI? в 2010 версии что ни меняли — на выходе в PDF размытое все.
4. Появилась ли возможность генерировать merged report (из нескольких разных отчетов один) не только в PDF (через эвент before print как в примере) но и в XLS (на разные листы)?
Пусть конечно есть проблемы, но ваши отчеты все равно рулят. Пробовал Telerik — мама дорогая, таких тормозов поискать надо. Считаю XtraReport лучшими report tools на сегодняшний день для дотнета.
Желаю успехов!
С удовольствием постараюсь ответить.
1. Пока нет :-( Если конкретно, вы имеете в виду www.devexpress.com/issue=S31499 или www.devexpress.com/issue=S31501?
2. А вы пробовали SwiftPlot series view? Он специально оптимизирован для таких целей.
Если по какой-то причине использовать его не получается, вот есть список полезных советов по улучшению перформанса в чартах:
www.devexpress.com/Support/Center/kb/p/K18146.aspx
А вообще, тут многое зависит от ситуации, так что если всё это не поможет, присылайте проект в суппорт, будем разбираться.
3. Насколько я помню, там могут быть две причины. Первая состоит в том, что в Акробате теперь по умолчанию стоит dpi равное 110, а не 96 (как это по умолчанию в Windows). Если вернуть на 96, это поможет сделать картинку чётче (http://www.devexpress.com/issue=S91919) Единственное, проблема всё равно будет актуальна для лейблов, которые используют слишком маленький размер шрифта, но тут поможет только если мы будем экспортить их в пдф не вместе с картинкой чартов, а отдельно, нативными пдф элементами. Пока, к сожалению, это не сделано — www.devexpress.com/issue=S31631.
4. По идее это легко можно сделать для XLSX. Во всяком случае, такой код очень даже работает:
private void button1_Click (object sender, EventArgs e) {
XtraReport1 report1 = new XtraReport1();
report1.CreateDocument();
XtraReport2 report2 = new XtraReport2();
report2.CreateDocument();
report1.Pages.AddRange(report2.Pages);
report1.ExportOptions.Xlsx.ExportMode = XlsxExportMode.SingleFilePageByPage;
report1.ExportToXlsx(@«C:\Temp\1.xlsx»);
}
P.S. Кстати, у нас на Хабре есть раздел habrahabr.ru/company/devexpress/questions/
Туда можно задавать вопросы по нашим продуктам — будем стараться оперативно на них реагировать.
1. Пока нет :-( Если конкретно, вы имеете в виду www.devexpress.com/issue=S31499 или www.devexpress.com/issue=S31501?
2. А вы пробовали SwiftPlot series view? Он специально оптимизирован для таких целей.
Если по какой-то причине использовать его не получается, вот есть список полезных советов по улучшению перформанса в чартах:
www.devexpress.com/Support/Center/kb/p/K18146.aspx
А вообще, тут многое зависит от ситуации, так что если всё это не поможет, присылайте проект в суппорт, будем разбираться.
3. Насколько я помню, там могут быть две причины. Первая состоит в том, что в Акробате теперь по умолчанию стоит dpi равное 110, а не 96 (как это по умолчанию в Windows). Если вернуть на 96, это поможет сделать картинку чётче (http://www.devexpress.com/issue=S91919) Единственное, проблема всё равно будет актуальна для лейблов, которые используют слишком маленький размер шрифта, но тут поможет только если мы будем экспортить их в пдф не вместе с картинкой чартов, а отдельно, нативными пдф элементами. Пока, к сожалению, это не сделано — www.devexpress.com/issue=S31631.
4. По идее это легко можно сделать для XLSX. Во всяком случае, такой код очень даже работает:
private void button1_Click (object sender, EventArgs e) {
XtraReport1 report1 = new XtraReport1();
report1.CreateDocument();
XtraReport2 report2 = new XtraReport2();
report2.CreateDocument();
report1.Pages.AddRange(report2.Pages);
report1.ExportOptions.Xlsx.ExportMode = XlsxExportMode.SingleFilePageByPage;
report1.ExportToXlsx(@«C:\Temp\1.xlsx»);
}
P.S. Кстати, у нас на Хабре есть раздел habrahabr.ru/company/devexpress/questions/
Туда можно задавать вопросы по нашим продуктам — будем стараться оперативно на них реагировать.
1. да — RowSpan и ColSpan.
2. Как раз свифт и используем. Не шибко быстрый. Но по ссылке почитаю, может что и ускорится.
4. по экселю попробую — а нативный XLS можно?
Спасибо за ответы :)
2. Как раз свифт и используем. Не шибко быстрый. Но по ссылке почитаю, может что и ускорится.
4. по экселю попробую — а нативный XLS можно?
Спасибо за ответы :)
1. Ок. Я передам команде про вашу просьбу :-)
2. Странно — он как раз заточен на работу с большими объемами данных. Если ни один из советов по ссылке не поможет, присылайте ваш тестовый проект в суппорт — очень хочется посмотреть на него повнимательнее и сделать пошустрее.
4. XLSX по-моему тоже нативный? ;-) (в том плане, что это ж тоже формат от МС?) К сожалению, нормальный постраничный экспорт у нас есть только в формате XLSX, а вот с XLS всё не просто — уж больно сложно там на данный момент что-то модифицировать. Да и к тому же очень многие наши пользователи уже мигрировали на XLSX — даже те, у кого нет Оффис 2007 или 2010, всегда могут поставить себе этот фикс: support.microsoft.com/kb/924074
2. Странно — он как раз заточен на работу с большими объемами данных. Если ни один из советов по ссылке не поможет, присылайте ваш тестовый проект в суппорт — очень хочется посмотреть на него повнимательнее и сделать пошустрее.
4. XLSX по-моему тоже нативный? ;-) (в том плане, что это ж тоже формат от МС?) К сожалению, нормальный постраничный экспорт у нас есть только в формате XLSX, а вот с XLS всё не просто — уж больно сложно там на данный момент что-то модифицировать. Да и к тому же очень многие наши пользователи уже мигрировали на XLSX — даже те, у кого нет Оффис 2007 или 2010, всегда могут поставить себе этот фикс: support.microsoft.com/kb/924074
мне вот интересно а баг с удаление файла лцензии они полечили или нет)
Я немного не в курсе. Может подскажите id бага? Или хотя бы в чём он выражался, под какой платформой?
я не знаю айди бага но суть в том что в старых версий, точно могу сказать про 7 и 8 и вроде как 9, если удалить в триал версии файл лиценции то компоненты работали как купленые тоесть не показывалась информация о том что продукт триальный
Разве это баг? Это же фича :) А если серьезно, главная ценность легально приобретенных продуктов DevExpress — доступ к оперативной и квалифицированной техподдержке. Даже несмотря на то что ответы на большинство вопросов можно свободно найти в документации и базе знаний.
Я не согласен по поводу оперативности, мы использовали компоненты для асп.нет, мы неделю ждали фидбека на свой вопрос, в конце концов сами разобрались. ну по поводу фичи, надо хотябы попытатся усложнить жизь тем кто хочет все и на шару, а тут гоп кильнул файлик и все отличненько, правда появится снова зара при повторной загрузке дизайнера или же добавления нового контрола
я не знаю айди бага но суть в том что в старых версий, точно могу сказать про 7 и 8 и вроде как 9, если удалить в триал версии файл лиценции то компоненты работали как купленые тоесть не показывалась информация о том что продукт триальный
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DXperience v2011 vol 1 — Новая версия .NET компонентов от DevExpress