Здравствуйте, AngeL B., Вы писали:

AB>Здравствуйте, globus, Вы писали:

AB>Мы пользуемся этим (DevExpress).
AB>Просто в восторге...

отстой. лучше чем component one & infragictics, но все же отстой:

1. запутанная и часто неудобная объектная модель
2. чтобы спрятать одну кнопку зачастую приходится порождать по 5 классов.
3. исходники отвратительны в плане оформления
4. забывают делать очевидные вещи для extensibility

Кароче, имхо они умеют только хорошо рисовать

Из плюсов — адекватный и быстрый саппорт

Здравствуйте, _FRED_, Вы писали:

_FR>Скины пользуете? Как перформанс? Сравнивали с инфрагистиком?
Мне больше понравился DevExpress. Скорость нас устраивает, скинами пользуемся всегда во всех проектах.
Насчет возможностей (IMHO) DevExpress намного навороченей.
Ты можешь сам попробовать, у них есть Evaluation версия, которая полностья функциональна в том числе в среде VS. Ограничение только в том, что нет исходников, при запуске программы выдается Evaluation окно и в отчетах внизу надпись соответсвующая.

Здравствуйте, Mad Hollander, Вы писали:

MH>А как это делается для каждой ячейки, я чтото не понял.
У них в демке XtraGrid есть пример Inplace Editors, где для каждой строки второго столбца присваивается свой собственный редактор. Вот код ключевого обработчика событий

private void gridView1_CustomRowCellEdit(object sender, DevExpress.XtraGrid.Views.Grid.CustomRowCellEditEventArgs e) 
{
    if(e.Column == this.gridEditorValue) 
    {
        GridEditorItem item = gridView1.GetRow(e.RowHandle) as GridEditorItem;
        if(item != null) e.RepositoryItem = item.RepositoryItem;
    }
}

Событие описано не в гриде, а во вьюхе типа GridView.
В коде видно, что можно определить текущий объект, и текущую колонку, после чего на основании каких угодно условий (у них без условий) вернуть в e.RepositoryItem нужный редактор.

Здравствуйте, _FRED_, Вы писали:

_FR>О! А это уже будет интересно: почему ДевЕкспресс, а не Инфрагистик? Мне все эти "лидеры" кажутся на одно лицо У ДевЕкспресса, правда, если какая-то модель для объектов представления? Что для тебя стало решающим?
Они (ДевЕкс) предлагают за те же деньги больший функционал. На счёт этого можно спорить очень долго, так как для каждого человека это может означать своё.
У них бОльший набор различных компонент для винды и для ASP.NET и понятная иерархия классов (по мне, опять же тут можно спорить до бесконечности).
Приложен XPO, который, являясь "порождающим базу" ORM (не знаю как это назвать, так что термин мой), фактически полностью берет на себя управление SQL-серверами, что для маленьких и средних проектов переводит работу с базой исключительно в область написания бизнес-классов. Для крупных проектов начинают сказываться недостатки всех ORM, так что там применение несколько ограничено и надо хорошо думать (на эту тему на форумах много писали).
В добавок с годовой подпиской поставляются лицензии на CodeRush и Refactor!. Первым я пользуюсь очень ограничено, а вот вторым на полную катушку.

P.S. Ну и конечно, как тут правильно заметили, дизайнеры у них рулят.

Здравствуйте, globus, Вы писали:

G>Посоветуйте пожалуйста лучшую коммерческую .нет библиотеку с поддержкой скинов и кучи полезных контролов да так чтоб без глюков и тормозов прорисовок
G>На данный момент не находжу ничего лучшего чем Nevron. Возможно все же есть альтернативы?

WPF

Здравствуйте, globus, Вы писали:

Мы пользуемся этим (DevExpress).
Просто в восторге...

Здравствуйте, Dog, Вы писали:

Dog>В чём может быть смысл удаления комментариев ?
Dog>А исходники таки да, из того что я вплотную столкнулся (XtraReports), это просто обнять и плакать.

Не удаления комментов, а обработка, которая включает в себя удаление комментов.

Это может быть сделано для того, что бы затруднить копирование кода из библиотеки.

Здравствуйте, AngeL B., Вы писали:

AB>Здравствуйте, http://chabster.blogspot.com/, Вы писали:

AB>Да, совсем забыл.
AB>Раз всё так плохо в DevExp, приведите примеры библиотеки с соизмеримыми возможностями и хорошими на Ваш взгляд исходниками/программным дизайном. Ведь ветка обсуждения для этого и создавалась.
AB>Может и я перейду на лучшее

А смысл? Я уверен, что для большинства проектов не руководствуются требованими к интерфейсу, а берут "самую крутую" библиотеку и за рамки ее функционала не вылазят. Кому нужен этот скиннинг тормозящий? Кому нужны монстрообразные контролы, напичканные функционалом, который нужно выбрасывать постоянно?

Если нужен конкретный элемент управления, я выбираю самый легкий контрол согласно требованиям. И если такого не нахожу — менеджмент, как правило, принимает правильное решение писать либо с нуля, либо на основе стандартного элемента управления (WinForms).

Месяца три назад решили использовать TreeList. Правда, от оригинального трилиста мало что осталось. И, поверь, копаться в их недокументированных исходниках — та еще радость. Если от контрола требуется то, чего нет в их примерах — туши свет. К примеру, нам нужен был TreeList, данные которого обновляются в режиме реального времени. Я поменял половину его исходников, чтобы убрать дикие тормоза, связанные с пересчетом всей геометрии при изменении значения одной ячейки. Причем в саппорте сказали, мол "контрол слишком сложный, поэтому пересчет и связанные с ним тормоза убрать нельзя". Остается лишь поблагодарить ДевЕкспресс за всю ненужную ерунду и связанный с ней еффорт. Для интереса — полистай саппорт. Там везде или "нельзя" или "этот дефект by design" или просто морозятся от ответа на поставленный вопрос.

Если DevExpress используется в оригинальном виде — это лучший выбор. Если дизайн определяется не разработчиком, а, например, заказчиком, — готовьтесь к худшему.

Форматирование кода — вовсе не проблема. Проблема в качестве кода и полнейшем отсутствии документирования (я даже не о комментариях). Представь, что контролы WinForms документированы строго на уровне свойств дизайнера. Как можно использовать такую библиотеку?

Здравствуйте, _FRED_, Вы писали:

_FR>Мои любимые — http://www.divelements.com/net

Сорри за оффтоп, но уж больно меня повеселили картинки с этой страницы: http://www.divelements.com/net/controls/
Там нарисовано, какого цвета траву надо курить, чтобы понять, как работать с каждым компонентом

Здравствуйте, Константин Л., Вы писали:

КЛ>открываю солюшн Scheduler'а:
КЛ>find all "//" — пусто
КЛ>find all "/\*.+" — пусто

КЛ>Визуально тоже проверил

Вот именно. Очень похоже на то, что просто исходники обрабатываются перед публикацией каким то тулом. Он же наверняка и форматирование портит в тех местах, где комментарии были. Опять же, референс по библиотекам очень похоже что по доккоментам генерится, а доккоментов то и нету.

Здравствуйте, Константин Л., Вы писали:

КЛ>имхо, оформлять код таким образом не совсем профессионально:

Да не работаюи они с таким кодом. Это то, что отдаётся наружу. То, в чём они _програмируют_, думаю, всё несколько по-другому выглядит, поэтому обсуждать качество _их кода_ по распространяемым исходникам — бесполезно, это две разные версии исходников.

Здравствуйте, AndrewVK, Вы писали:

_FR>>Ведь действительно — идеал, когда у всех одинаково _и всех это устраивает_ (хотя б процентов на 95%).

AVK>Нет, идеял, это когда тебя любой приличный стиль не создает проблем.

Ну как тебе сказать… Я у десятка разных людей (в совершенно разных компаниях) видел такое:

qqqqq();
tttt();

if(condution)
{
  aaaa();
  bbbb();
}
else
  ccc();
  ddd();

qqqqq();
tttt();

и даже раз сам себя на подобном ловил. мне этого одинажды хватило для того, что бы считать отсутствие кавык в простых случаях чем-то дурнопахнущим.

_FR>> Для того, что б к идеалу придти, обсуждать\осуждать\спорить очень полезно.
AVK>Ага, примерно так же полезно, как спорить о вкусах.

Чайникам лучше действительно не спорить о вкусах, однако спецЫ (и в поварском деле, и в модельерном) очень даже мерюются, пытаясь достичь идеала. Почему бы и нам не?

Здравствуйте, Константин Л., Вы писали:

КЛ>>>имхо, оформлять код таким образом не совсем профессионально:
_FR>>Да не работаюи они с таким кодом. Это то, что отдаётся наружу. То, в чём они _програмируют_, думаю, всё несколько по-другому выглядит, поэтому обсуждать качество _их кода_ по распространяемым исходникам — бесполезно, это две разные версии исходников.
КЛ>тогда зачем давать фуфло, простите? Вот ты бы стла такой код отдавать? еще раз говорит о качестве компании.

Для отладки или для самого крайнего случая, когда рефлектить лень :о)) К тому же в рекламных целях заявлять о предоставлении исходных кодов заманчиво

Здраствуйте!

Посоветуйте пожалуйста лучшую коммерческую .нет библиотеку с поддержкой скинов и кучи полезных контролов да так чтоб без глюков и тормозов прорисовок
На данный момент не находжу ничего лучшего чем Nevron. Возможно все же есть альтернативы?

Заранее благодарен!!!

Здравствуйте, AngeL B., Вы писали:

AB>Мы пользуемся этим (DevExpress).
AB>Просто в восторге...

Скины пользуете? Как перформанс? Сравнивали с инфрагистиком?

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, AngeL B., Вы писали:

AB>>Мы пользуемся этим (DevExpress).
AB>>Просто в восторге...

_FR>Скины пользуете? Как перформанс? Сравнивали с инфрагистиком?

Если нужна функционатьность докируемых окон — это полный кошмар, а в целом нормально, но тормозит порядочно. Сравнить могу только с Sincfusion Essential или как оно там, дэвэкспресс намного лучше.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, AngeL B., Вы писали:

AB>>Мы пользуемся этим (DevExpress).
AB>>Просто в восторге...

_FR>Скины пользуете? Как перформанс? Сравнивали с инфрагистиком?

Да, кстати, дерево, попробуйте вставить новый нод в произвольное место... (у нас версия 7.1.2)

Здравствуйте, Константин Л., Вы писали:

КЛ>0. отстой. лучше чем component one & infragictics, но все же отстой:
Меня поражают посты такого содержания. Я видел такое только от ярых, невменяемых линуксоидов. Типа все фигня и длинный перечень пунктов без обоснования.
Если все фигня, то предлагай адекватный вариант.

КЛ>1. запутанная и часто неудобная объектная модель
понятная и адекватная решаемым задачам объектная модель

КЛ>2. чтобы спрятать одну кнопку зачастую приходится порождать по 5 классов.
может плохо читаем документацию/изучаем библиотеку?

КЛ>3. исходники отвратительны в плане оформления
ты библиотеку покупаешь чтобы исходники читать? Мне, например, приходилось заглядывать туда всего два раза и оба для большего понимания работы XPO. В графическую лазать вообще не приходилось. Не было нужды. Все решалось теми возможностями которые уже предоставлены.

КЛ>Кароче, имхо они умеют только хорошо рисовать
учитывая пункт 0, надо полагать остальные не умеют даже этого.
К тому же, извини, но то, что умеет делать их GRID, ... это же просто иногда большая часть функционала клиентских мест (если конечно адекватно обучить персонал).

Здравствуйте, AngeL B., Вы писали:

AB>Здравствуйте, Константин Л., Вы писали:

КЛ>>0. отстой. лучше чем component one & infragictics, но все же отстой:
AB>Меня поражают посты такого содержания. Я видел такое только от ярых, невменяемых линуксоидов. Типа все фигня и длинный перечень пунктов без обоснования.
AB>Если все фигня, то предлагай адекватный вариант.


КЛ>>1. запутанная и часто неудобная объектная модель
AB>понятная и адекватная решаемым задачам объектная модель

а вот по мне — часто неадекватная

КЛ>>2. чтобы спрятать одну кнопку зачастую приходится порождать по 5 классов.
AB>может плохо читаем документацию/изучаем библиотеку?

нет, и читаем хорошо, и изучаем хорошо

КЛ>>3. исходники отвратительны в плане оформления
AB>ты библиотеку покупаешь чтобы исходники читать? Мне, например, приходилось заглядывать туда всего два раза и оба для большего понимания работы XPO. В графическую лазать вообще не приходилось. Не было нужды. Все решалось теми возможностями которые уже предоставлены.

просто наводит на мысли

КЛ>>Кароче, имхо они умеют только хорошо рисовать
AB>учитывая пункт 0, надо полагать остальные не умеют даже этого.
AB>К тому же, извини, но то, что умеет делать их GRID, ... это же просто иногда большая часть функционала клиентских мест (если конечно адекватно обучить персонал).

а что же он умеет такого крутого? сортировка, группировка? хехе...

у меня есть уйма примеров, на досуге напишу

Здравствуйте, Константин Л., Вы писали:

КЛ>а что же он умеет такого крутого? сортировка, группировка? хехе...
Ну даже не знаю что сказать

1) Сортировка — рантайм, в том числе по нескольким полям
2) Фильтрация строк — рантайм, с возможностью написания своего окна для редактирования фильтра
3) Группировка — рантайм, в том числе на произвольную глубину с подсчетом сумм для каждой группы/подгруппы
4) Сортировка по суммам групп
5) Редакторы — возможность определять уникальный редактор (из множества всей библиотеки или свой) для каждой(!)ячейки — рантайм
6) Cell Merging (сводные таблицы) — рантайм
7) Отображение одной записи в виде нескольких строк
8) Master-Detail любой глубины и с любым количеством Detail (в виде табов) на одном уровне вложенности

и при этом возможность переложить большинство операций на сторону сервера...
Чего-то не хватает??? Может конечно и да, но наверное это что-то уж очень хитрое

Здравствуйте, Константин Л., Вы писали:

КЛ>3. исходники отвратительны в плане оформления

Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.

Здравствуйте, AngeL B., Вы писали:

AB>Здравствуйте, Константин Л., Вы писали:

КЛ>>0. отстой. лучше чем component one & infragictics, но все же отстой:
AB>Меня поражают посты такого содержания. Я видел такое только от ярых, невменяемых линуксоидов. Типа все фигня и длинный перечень пунктов без обоснования.
AB>Если все фигня, то предлагай адекватный вариант.

КЛ>>1. запутанная и часто неудобная объектная модель
AB>понятная и адекватная решаемым задачам объектная модель

КЛ>>2. чтобы спрятать одну кнопку зачастую приходится порождать по 5 классов.
AB>может плохо читаем документацию/изучаем библиотеку?

КЛ>>3. исходники отвратительны в плане оформления
AB>ты библиотеку покупаешь чтобы исходники читать? Мне, например, приходилось заглядывать туда всего два раза и оба для большего понимания работы XPO. В графическую лазать вообще не приходилось. Не было нужды. Все решалось теми возможностями которые уже предоставлены.

КЛ>>Кароче, имхо они умеют только хорошо рисовать
AB>учитывая пункт 0, надо полагать остальные не умеют даже этого.
AB>К тому же, извини, но то, что умеет делать их GRID, ... это же просто иногда большая часть функционала клиентских мест (если конечно адекватно обучить персонал).

Меня поражают посты подобного содержания. Люди, использующие библиотеку только в дизайнере лают людей, которые долбят голову об попахивающие исходники.

DevExpress — это библиотека, которую можно использовать на уровне их же примеров. Исходники — просто тихий ужас. Саппорт отвратительный — на все вопросы круче чем "как вставить нод в дерево" они отвечают "наша библиотека это не поддерживает". Большая часть исходников перенесена с 1.1. Коментарии в исходниках фактически отсутствуют. Исключения глотают.

Вывод: если нужно больше, чем "бросить на форму, установить парочку свойств дизайнером" — однозначно НЕТ, НЕТ и еще раз НЕТ! Запомните следующее: DevExpress работает на уровне их примеров; DevExpress тормозит; DevExpress предпочитает слово "Delivered" слову "Quality".

Здравствуйте, http://chabster.blogspot.com/, Вы писали:

HCB>Меня поражают посты подобного содержания. Люди, использующие библиотеку только в дизайнере лают людей, которые долбят голову об попахивающие исходники.
Во-первых, успокойся, тут никто никого не лает. Тут это немного не принято.
Во-вторых, когда мне хочется покопаться в исходниках я лезу в Nemerle, Scheme или играюсь с генерацией функций в C# 3.0.
В третьих, я воспринимаю DevExp не как пример хорошо сделанных исходников, а как _инструмент_ для создания программ. И пока этот инструмент отвечает моим требованиям мне все равно какие у него исходники. Если ты мне предложишь инструмент с красивыми исходниками и отличным программным дизайном, но мне придется дописывать пару десятков возможностей самому, я назову этот инструмент плохим, поскольку в комерческих проектах моя задача не "крутые" исходники, а сданный и готовый к обозримому масштабированию проект.
Если же ты выбираешь библиотеку для реализации проектов на основании "запаха" исходников, то у нас с тобой просто разные подходы.

HCB>DevExpress — это библиотека, которую можно использовать на уровне их же примеров. Исходники — просто тихий ужас.
саппорт меня устраивает (может я мало туда обращался). Насчет исходников я уже высказался вверху. Да, форматирование исходного кода убогое, но вполне читабельное.

HCB>Запомните следующее: DevExpress работает на уровне их примеров; DevExpress тормозит; DevExpress предпочитает слово "Delivered" слову "Quality".
а) логично, т.к. примеры фирмы охватывают практически полное функциональное поле библиотеки (чего о многих других библиотеках сказать нельзя, кстати)
б) у меня у клиентов при использовании Ribbon и скинов не тормозит (Celeron 1700, 512 Mb)
в) поскольку DevExpress это комерческая фирма, работающая на комерческий рынок, она предпочитает законченые решения готовые к использованию абстрактным идейным соображениям.

Здравствуйте, http://chabster.blogspot.com/, Вы писали:

Да, совсем забыл.
Раз всё так плохо в DevExp, приведите примеры библиотеки с соизмеримыми возможностями и хорошими на Ваш взгляд исходниками/программным дизайном. Ведь ветка обсуждения для этого и создавалась.
Может и я перейду на лучшее

КЛ>>3. исходники отвратительны в плане оформления
AVK>Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.
В чём может быть смысл удаления комментариев ?
А исходники таки да, из того что я вплотную столкнулся (XtraReports), это просто обнять и плакать.

Здравствуйте, AngeL B., Вы писали:

AB>5) Редакторы — возможность определять уникальный редактор (из множества всей библиотеки или свой) для каждой(!)ячейки — рантайм

А как это делается для каждой ячейки, я чтото не понял.

Здравствуйте, AngeL B., Вы писали:

AB>...поскольку в комерческих проектах моя задача не "крутые" исходники, а сданный и готовый к обозримому масштабированию проект.
AB>Если же ты выбираешь библиотеку для реализации проектов на основании "запаха" исходников, то у нас с тобой просто разные подходы.

К своей работе ты так же относишься, "сданный и готовый ... проект" предпочитая "запаху исходников"?

Здравствуйте, AndrewVK, Вы писали:

КЛ>>3. исходники отвратительны в плане оформления

AVK>Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.

Ни чего себе Вот инфрагистик, каким бы не идеальным он не казался ни снаружи, ни изнутри, всё таки вызывает уважение именно что качеством коментариев: Не редко над какими-то строчками написано, какой разработчик когда, что и почему добавил или, наоборот, закоментарил .

Здравствуйте, _FRED_, Вы писали:

_FR>К своей работе ты так же относишься, "сданный и готовый ... проект" предпочитая "запаху исходников"?
хотя вопрос и провокационный, ответ — нет. Ты почему-то выбросил "готовый в обозримому масштабированию". А масштабирование подразумевает и возможность быстро понимать исходный код и хорошее проектирование, чтобы потом всё не переписывать.

Во фразе я имел в виду не свои исходники, а исходники в том числе библиотек которыми я пользуюсь. А вот качество их кода, это проблемы разработчиков библиотек. Они вообще могли не предоставлять исходники.
Получается какая-то дурацкая ситуация, тех, кто свои исходники не дает, судят по функционалу и возможности использования, а тех кто дает, обливают г... потому что они исходники написали не так как Вам понравилось. Бред просто. (моё мнение конечно)

Здравствуйте, _FRED_, Вы писали:

_FR>Ни чего себе Вот инфрагистик, каким бы не идеальным он не казался ни снаружи, ни изнутри, всё таки вызывает уважение именно что качеством коментариев: Не редко над какими-то строчками написано, какой разработчик когда, что и почему добавил или, наоборот, закоментарил .

Вот опять же продолжение темы исходников. Даже не , а и .
Но я не выберу эту библиотеку только на основании того что там крутые коментарии, потому что конечные программы я пишу не на основе коментариев, а на основе функционала.
Вот если бы были две равные (хотя бы примерно) библиотеки, тогда да. Выбор уже начинается по другим критериям нежели функционал и удобство использования.

Здравствуйте, AngeL B., Вы писали:

_FR>>К своей работе ты так же относишься, "сданный и готовый ... проект" предпочитая "запаху исходников"?
AB>хотя вопрос и провокационный, ответ — нет. Ты почему-то выбросил "готовый в обозримому масштабированию".

Только что бы не затруднять чтение длинными цитатами, но это имел в виду так же.

AB>А масштабирование подразумевает и возможность быстро понимать исходный код и хорошее проектирование, чтобы потом всё не переписывать.

Тогда, если я тебя правильно понимаю, нельзя считать DevExpress масштабируемым, с твоей позиции? Ведь, имея исходники низкого качества, ты не модешь полноценно отлаживать библиотеку, для тебя неимоверно затруднено понимание её работы (и, что более важно, не работы, если не повезёт). Как можно быть уверенным в отсутствии ошибок, когда "каждая последняя — предпоследняя"? Если ошибки в библиотечном коде возможны, то надо быть уверенным, что вы с ними справитесь к нужному моменту. Как тебе удаётся решать такие проблемы? Всегда вовремя выручает их техподдержка?

AB>Во фразе я имел в виду не свои исходники, а исходники в том числе библиотек которыми я пользуюсь. А вот качество их кода, это проблемы разработчиков библиотек. Они вообще могли не предоставлять исходники.

Вот с чем не могу согласиться. Не верю в качественные библиотеки, собранные из не выдерживающего критики кода. Конечно, код, который они на самом деле используют для компиляции может быть и не таким, но у тебя нет возможности (вернее, она сильно затруднена) писать свои фиксы\дополнения к библиотеке. Это связывает руки.

AB>Получается какая-то дурацкая ситуация, тех, кто свои исходники не дает, судят по функционалу и возможности использования, а тех кто дает, обливают г... потому что они исходники написали не так как Вам понравилось. Бред просто. (моё мнение конечно)

А кто не даёт? Какой в этом смысл? Даже майкрософт и та уже показывает то, что есть.

Между прочим, мне кажется, если бы DexExpress не отдавали исходники, то объём их продаж был бы значительно меньше (ранок, на котором они существует требует этого). Если бы никто на рынке неотдавал исходники, тогда, возможно, ситуация была бы другая и процветало бы что-то с сорс-форжа и т.п.

Например, если бы появились СУБД уровня сиквела или оракла с открытыми исходниками, то и производители на этом рынке так же должны были бы прогнуться в этом направлении.

Здравствуйте, AngeL B., Вы писали:

AB>Но я не выберу эту библиотеку только на основании того что там крутые коментарии, потому что конечные программы я пишу не на основе коментариев, а на основе функционала.

О! А это уже будет интересно: почему ДевЕкспресс, а не Инфрагистик? Мне все эти "лидеры" кажутся на одно лицо У ДевЕкспресса, правда, если какая-то модель для объектов представления? Что для тебя стало решающим?

Dog>>В чём может быть смысл удаления комментариев ?
Dog>>А исходники таки да, из того что я вплотную столкнулся (XtraReports), это просто обнять и плакать.
MH>Не удаления комментов, а обработка, которая включает в себя удаление комментов.
MH>Это может быть сделано для того, что бы затруднить копирование кода из библиотеки.
Хм... они же сорцы продают. И как каменты могут затруднить копирование? Там сами сорцы это затрудняют

Здравствуйте, Dog, Вы писали:

MH>>Это может быть сделано для того, что бы затруднить копирование кода из библиотеки.
Dog>Хм... они же сорцы продают. И как каменты могут затруднить копирование? Там сами сорцы это затрудняют

Копирование текста в клипборд комменты никоим образом не затрудняют

Здравствуйте, _FRED_, Вы писали:

_FR>Тогда, если я тебя правильно понимаю, нельзя считать DevExpress масштабируемым, с твоей позиции? Ведь, имея исходники низкого качества, ты не модешь полноценно отлаживать библиотеку, для тебя неимоверно затруднено понимание её работы (и, что более важно, не работы, если не повезёт).
Это передергивание. С тем же успехом можно заявить, что VS является немасштабируемой, так как у нас нет её полных исходников. Зачем же ты её тогда используешь?
Ещё раз объясняю — я рассматриваю библиотеки как _инструмент_ для создания программ. Если мне приходиться отлаживать код библиотеки, то я уже считаю что она плохая и начинаю искать другую или материть поддержку. При ошибках я ищу способ обойти её и решить _свою_ задачу.
Может будет лучше, если я объясню на другом примере. Если ты купил бензопилу, а она начинает барахлить, ты что будешь делать: изучать строение бензиновых двигателей и чинить движок или отдашь её в гарантийку/купишь новую? Я сделаю второе, потому что безнопила для меня _инструмент_. Почему тогда я должен к библиотекам применять другую логику? Меня интересует чтобы библиотека выполняла заявленные функции и делала это безотказно.
Вот если бы библиотеку писал я ...

_FR>Как можно быть уверенным в отсутствии ошибок, когда "каждая последняя — предпоследняя"? Если ошибки в библиотечном коде возможны, то надо быть уверенным, что вы с ними справитесь к нужному моменту. Как тебе удаётся решать такие проблемы? Всегда вовремя выручает их техподдержка?
Я не помню случаев когда бы их ошибки стали для нас поперек горла.

Здравствуйте, AngeL B., Вы писали:

_FR>>Тогда, если я тебя правильно понимаю, нельзя считать DevExpress масштабируемым...
AB>Это передергивание. С тем же успехом можно заявить, что VS является немасштабируемой, так как у нас нет её полных исходников. Зачем же ты её тогда используешь?

Я не программирую с использованием её АПИ, а вот те, кто програмируют, плюются. И в этом я вижу очень большую разницу: то, что я делаю не зависит от качества кода студии. Процесс — да, зависит. Но сколько лет на рынке MSVS и какие возможности по тестированию есть у её производителя по сравнению с кем-то другим? То-то.

AB>Ещё раз объясняю — я рассматриваю библиотеки как _инструмент_ для создания программ. Если мне приходиться отлаживать код библиотеки, то я уже считаю что она плохая и начинаю искать другую или материть поддержку. При ошибках я ищу способ обойти её и решить _свою_ задачу.

Тогда дальше спорить не считаю нужным — наши позиции уже тут далеко расходятся и вовсе нефакт что я прав на 100% . Ответ на свой вопрос (почему могут быть не важны исходники) я получил и более чем ясный. Спасибо

КЛ>отстой. лучше чем component one & infragictics, но все же отстой:

Так что же вы предложите в качестве достойной замены глюкавому и кривому DevExpress?

Здравствуйте, Igor Trofimov, Вы писали:

КЛ>>отстой. лучше чем component one & infragictics, но все же отстой:
iT>Так что же вы предложите в качестве достойной замены глюкавому и кривому DevExpress?

Мои любимые — http://www.divelements.com/net

Здравствуйте, globus, Вы писали:

G>Здраствуйте!

G>Посоветуйте пожалуйста лучшую коммерческую .нет библиотеку с поддержкой скинов и кучи полезных контролов да так чтоб без глюков и тормозов прорисовок
G>На данный момент не находжу ничего лучшего чем Nevron. Возможно все же есть альтернативы?

G>Заранее благодарен!!!

Сделал на DevExpress собственноручно 4 коммерческих проекта на данной библиотеке. 5 — в продакшене.
Библиотека не без изъянов — но мои задачи покрывает практически полностью.

Здравствуйте, _FRED_, Вы писали:

[]

_FR>Между прочим, мне кажется, если бы DexExpress не отдавали исходники, то объём их продаж был бы значительно меньше (ранок, на котором они существует требует этого). Если бы никто на рынке неотдавал исходники, тогда, возможно, ситуация была бы другая и процветало бы что-то с сорс-форжа и т.п.

Кстати, я бы не рискнул что-то у них править. Во-первых дохрена, во-вторых оч сложно разобраться. Того и гляди что-то сломаешь.

[]

Здравствуйте, AngeL B., Вы писали:

[]

имхо, их проблема в том, что они не проводят анализ фич со стороны, как пользователи. Поэтому многие простые и очевидные вещи либо никак не реализованы, либо через попу. Посмотри хотя-бы LookupEdit. Он может только сам искать в датасорсе. То-есть если у меня есть какой-то здоровый датасорс и я хочу сам в нем искать и отдавать результаты — фиг. Лажа в общем.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>3. исходники отвратительны в плане оформления

AVK>Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.

да там просто позорное оформление кода.

Здравствуйте, Константин Л., Вы писали:

AVK>>Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.

КЛ>да там просто позорное оформление кода.

То есть у них на самом деле в рабочем коде нет ни одного комментария?

Здравствуйте, Константин Л., Вы писали:

КЛ>да там просто позорное оформление кода.

А что там не нравится. Как по мне, вполне нормальные исходники.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Константин Л., Вы писали:

AVK>>>Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.

КЛ>>да там просто позорное оформление кода.

AVK>То есть у них на самом деле в рабочем коде нет ни одного комментария?

неа

Здравствуйте, Константин Л., Вы писали:

AVK>>То есть у них на самом деле в рабочем коде нет ни одного комментария?

КЛ>неа

Извини, но в это мне совсем не верится.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Константин Л., Вы писали:

AVK>>>То есть у них на самом деле в рабочем коде нет ни одного комментария?

КЛ>>неа

AVK>Извини, но в это мне совсем не верится.

ну дело твоё.

открываю солюшн Scheduler'а:
find all "//" — пусто
find all "/\*.+" — пусто

Визуально тоже проверил

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>открываю солюшн Scheduler'а:
КЛ>>find all "//" — пусто
КЛ>>find all "/\*.+" — пусто

КЛ>>Визуально тоже проверил

AVK>Вот именно. Очень похоже на то, что просто исходники обрабатываются перед публикацией каким то тулом. Он же наверняка и форматирование портит в тех местах, где комментарии были. Опять же, референс по библиотекам очень похоже что по доккоментам генерится, а доккоментов то и нету.

ну пусть так. только при чем здесь это? Сам стиль написания кода мне не нравится. отступы там, переносы и тп

Здравствуйте, Константин Л., Вы писали:

КЛ>ну пусть так. только при чем здесь это?

При том что ругать DevExpress на основании качества форматирования тех исходников, что идут в поставке, некорректно.

КЛ>Сам стиль написания кода мне не нравится. отступы там, переносы и тп

Во-первых как раз про отступы и переносы я и писал. А во-вторых, если ты считаешь, что выбранный и соблюдаемый единый стиль форматирования может быть плохим и хорошим, это, как бы помягче сказать, непрофессионально.

Здравствуйте, AndrewVK, Вы писали:

AVK>А во-вторых, если ты считаешь, что выбранный и соблюдаемый единый стиль форматирования может быть плохим и хорошим, это, как бы помягче сказать, непрофессионально.

Гхм У Макконелла в CodeComplete есть рассуждения на тему хорошего оформления кода (в частности, расстановке фигурных скобок в конструкциях). Это не профессионально?

Здравствуйте, _FRED_, Вы писали:

_FR>Гхм У Макконелла в CodeComplete есть рассуждения на тему хорошего оформления кода (в частности, расстановке фигурных скобок в конструкциях). Это не профессионально?

Нет. Потому что, если какие то правила кодирования есть, это главное. А какие уж они конкретно, пока они остаются в рамках разумного, не суть важно. Вкусы у всех разные. Что же касаемо Макконела, то у него там довольно много весьма спорных рекомендаций по оформлению было.

Здравствуйте, AndrewVK, Вы писали:

_FR>>Гхм У Макконелла в CodeComplete есть рассуждения на тему хорошего оформления кода (в частности, расстановке фигурных скобок в конструкциях). Это не профессионально?

AVK>Нет. Потому что, если какие то правила кодирования есть, это главное. А какие уж они конкретно, пока они остаются в рамках разумного, не суть важно. Вкусы у всех разные.

Это только первый дан Когда все более-менее до него дотянутся, начнётся достижение второго\третьего\… Ведь действительно — идеал, когда у всех одинаково _и всех это устраивает_ (хотя б процентов на 95%). Для того, что б к идеалу придти, обсуждать\осуждать\спорить очень полезно.

AVK>Что же касаемо Макконела, то у него там довольно много весьма спорных рекомендаций по оформлению было.

Как-то не встречал публичного обсуждения негде… Имхо, просто никто не читает эти места или же не понимает\не считает нужным Тогда действительно спорить неочем, потому что не с кем

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, _FRED_, Вы писали:

_FR>>Гхм У Макконелла в CodeComplete есть рассуждения на тему хорошего оформления кода (в частности, расстановке фигурных скобок в конструкциях). Это не профессионально?

AVK>Нет. Потому что, если какие то правила кодирования есть, это главное. А какие уж они конкретно, пока они остаются в рамках разумного, не суть важно. Вкусы у всех разные. Что же касаемо Макконела, то у него там довольно много весьма спорных рекомендаций по оформлению было.

имхо, оформлять код таким образом не совсем профессионально:

#region IXXXUpdateHandler implementation
        void IXXXUpdateHandler.OnFirstBeginUpdate() {
            this.changed = false;
        }
        void IXXXUpdateHandler.OnBeginUpdate() {
        }
        void IXXXUpdateHandler.OnEndUpdate() {
        }
        void IXXXUpdateHandler.OnLastEndUpdate() {
            if (changed)
                UpdateRelatedControls();
        }
        void IXXXUpdateHandler.OnCancelUpdate() {
        }
        void IXXXUpdateHandler.OnLastCancelUpdate() {
        }
        #endregion

public XXXXXX(YYY viewInfo) {
            if (viewInfo == null)
                Exceptions.ThrowArgumentNullException("viewInfo");
            this.viewInfo = viewInfo;
            contentCalcualtorHelper = CreateContentLayoutCalculatorHelper();
        }
        public AppointmentDisplayOptions AppointmentDisplayOptions { get { return viewInfo.AppointmentDisplayOptions; } }
        protected internal AppointmentContentCalculatorHelper ContentCalcualtorHelper { get { return contentCalcualtorHelper; } }
        protected internal ISchedulerViewInfoCore ViewInfo { get { return viewInfo; } }
        protected internal TimeOfDayInterval NightTimeInterval { get { return nightTimeInterval; } set { nightTimeInterval = value; } }

        public virtual AppointmentStatusDisplayType GetAppointmentStatusDisplayType() {
            return ViewInfo.AppointmentDisplayOptions.StatusDisplayType;
        }

а уж тем более если ты вырезаешь родные комменты... Нечестно. Не хочешь чтобы твоими исходниками можно было полноценно воспользоваться — не отдавай их.

Здравствуйте, _FRED_, Вы писали:

_FR>Это только первый дан

Это как раз черный пояс. А даны, это когда пытаются рассказать про правильные и неправильные стили.

_FR>Ведь действительно — идеал, когда у всех одинаково _и всех это устраивает_ (хотя б процентов на 95%).

Нет, идеял, это когда тебя любой приличный стиль не создает проблем.

_FR> Для того, что б к идеалу придти, обсуждать\осуждать\спорить очень полезно.

Ага, примерно так же полезно, как спорить о вкусах.

_FR>Как-то не встречал публичного обсуждения негде…

Да как то пробегало.

Здравствуйте, AndrewVK, Вы писали:

[]

AVK>Во-первых как раз про отступы и переносы я и писал. А во-вторых, если ты считаешь, что выбранный и соблюдаемый единый стиль форматирования может быть плохим и хорошим, это, как бы помягче сказать, непрофессионально.

тут очень важна поправка: адекватный стиль. единый но неадекватный критиковать и можно и нужно. я считаю что у них неадекватный

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, Константин Л., Вы писали:

КЛ>>имхо, оформлять код таким образом не совсем профессионально:

_FR>Да не работаюи они с таким кодом. Это то, что отдаётся наружу. То, в чём они _програмируют_, думаю, всё несколько по-другому выглядит, поэтому обсуждать качество _их кода_ по распространяемым исходникам — бесполезно, это две разные версии исходников.

тогда зачем давать фуфло, простите? Вот ты бы стла такой код отдавать? еще раз говорит о качестве компании.

Здравствуйте, _FRED_, Вы писали:

AVK>>Нет, идеял, это когда тебя любой приличный стиль не создает проблем.

_FR>Ну как тебе сказать… Я у десятка разных людей (в совершенно разных компаниях) видел такое:
_FR>

_FR>qqqqq();
_FR>tttt();

_FR>if(condution)
_FR>{
_FR>  aaaa();
_FR>  bbbb();
_FR>}
_FR>else
_FR>  ccc();
_FR>  ddd();

_FR>qqqqq();
_FR>tttt();
_FR>

_FR>и даже раз сам себя на подобном ловил.

Ну и при чем тут стиль кодирования?

_FR>мне этого одинажды хватило для того, что бы считать отсутствие кавык в простых случаях чем-то дурнопахнущим.

Каких кавык?

_FR>Чайникам лучше действительно не спорить о вкусах

Спецам тоже.

_FR>, однако спецЫ (и в поварском деле, и в модельерном) очень даже мерюются, пытаясь достичь идеала. Почему бы и нам не?

Потому как те, которые меряются, они в основном понты продают, поэтому пенисометрия им полезна.

Здравствуйте, Константин Л., Вы писали:

КЛ>тут очень важна поправка: адекватный стиль

Адекватный чему?

Здравствуйте, AndrewVK, Вы писали:

_FR>>Ну как тебе сказать… Я у десятка разных людей (в совершенно разных компаниях) видел такое:

_FR>>qqqqq();
_FR>>tttt();

_FR>>if(condution)
_FR>>{
_FR>>  aaaa();
_FR>>  bbbb();
_FR>>}
_FR>>else
_FR>>  ccc();
_FR>>  ddd();

_FR>>qqqqq();
_FR>>tttt();

_FR>>и даже раз сам себя на подобном ловил.

AVK>Ну и при чем тут стиль кодирования?

Стиль кодировани определяет, ставить ли кавыки в "простых случаях", таких как этот:

if(condition)
  action();

Так вот если правила оформления кода позволяют такое (опускать кавыки), то не редко можно увидеть ошибки (в моём примере автор хотел, что бы ddd(); вызвалось в случае "else", а получилось так, что вызывается во всех случаях). Если бы стили оформления не допускали неуказания кавык в "простых" случаях, то код аыглядел бы так:

if(condution) {
  action();
}//if

и теперь ошибиться стало бы невозможно (в разумных пределах).

Здравствуйте, _FRED_, Вы писали:

_FR>Так вот если правила оформления кода позволяют такое (опускать кавыки), то не редко можно увидеть ошибки

Использую такой стиль уже лет 6 — описанной проблемы не было ни разу. А при установленном решарпере добится такого форматирования это специальным образом поизвращаться надо.

Здравствуйте, AndrewVK, Вы писали:

_FR>>Так вот если правила оформления кода позволяют такое (опускать кавыки), то не редко можно увидеть ошибки
AVK>Использую такой стиль уже лет 6 — описанной проблемы не было ни разу. А при установленном решарпере добится такого форматирования это специальным образом поизвращаться надо.

Ты, извини уж за фамильярность, уже не мальчик И можешь позволить себе внимательно относиться к тому, что пишешь. Для меня было бы легче завести предлагаемое мной правило в команде, чем собрать команду из нескольких таких, как ты

Здравствуйте, _FRED_, Вы писали:

_FR>Ты, извини уж за фамильярность, уже не мальчик И можешь позволить себе внимательно относиться к тому, что пишешь. Для меня было бы легче завести предлагаемое мной правило в команде, чем собрать команду из нескольких таких, как ты

ИМХО проще пару раз вправить мозги за вредительство, нежели плодить по всему коду массу скобок, ухудшая читаемость. Но, как я уже говорил, вобщем то это неважно.

Здравствуйте, http://chabster.blogspot.com/, Вы писали:


HCB> А смысл? Я уверен, что для большинства проектов не руководствуются требованими к интерфейсу, а берут "самую крутую" библиотеку и за рамки ее функционала не вылазят. Кому нужен этот скиннинг тормозящий? Кому нужны монстрообразные контролы, напичканные функционалом, который нужно выбрасывать постоянно?

HCB>Если нужен конкретный элемент управления, я выбираю самый легкий контрол согласно требованиям. И если такого не нахожу — менеджмент, как правило, принимает правильное решение писать либо с нуля, либо на основе стандартного элемента управления (WinForms).

HCB>Месяца три назад решили использовать TreeList. Правда, от оригинального трилиста мало что осталось. И, поверь, копаться в их недокументированных исходниках — та еще радость. Если от контрола требуется то, чего нет в их примерах — туши свет. К примеру, нам нужен был TreeList, данные которого обновляются в режиме реального времени. Я поменял половину его исходников, чтобы убрать дикие тормоза, связанные с пересчетом всей геометрии при изменении значения одной ячейки. Причем в саппорте сказали, мол "контрол слишком сложный, поэтому пересчет и связанные с ним тормоза убрать нельзя". Остается лишь поблагодарить ДевЕкспресс за всю ненужную ерунду и связанный с ней еффорт. Для интереса — полистай саппорт. Там везде или "нельзя" или "этот дефект by design" или просто морозятся от ответа на поставленный вопрос.

забавно. Вам же приводили пример с бензопилой. Могу его расширить. Например, если вы купили пилу и стали ее использовать для того, чтобы колоть дрова, или копать землю — и при этом требовать от производителя бензопилы, чтобы он улучшил данные свойства. Как думаете, куда вас пошлет производитель пилы? .
Приблизительна таже история из компонентами. Невозможно написать универсальный TreeList или Grid, который одинаково хорошо будет работать при абсолютно разных сценариях. Как правило, выбираются основные направления и реализуется их максимальная поддержка. Разумеется никто изначально не закладывался на real-time дерево — предпологалось, что это будет либо статика, либо постепенно обновляемое/редактаруемое дерево. Что устраивает 99% его пользователей.


HCB>Форматирование кода — вовсе не проблема. Проблема в качестве кода и полнейшем отсутствии документирования (я даже не о комментариях). Представь, что контролы WinForms документированы строго на уровне свойств дизайнера. Как можно использовать такую библиотеку?

Понятие "качества" у всех очень разное. А документирование кода, это один из видов его хренового качества — если код нуждается в документации, значит он странно написан.

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Константин Л., Вы писали:

КЛ>>3. исходники отвратительны в плане оформления

AVK>Есть подозрение, что они чем то обработаны. Ну не верю я, что в таком большом проекте нет ни одной строчки комментария.
Скажем так, это предположение отчасти верно. Но комментариев в "реальном" коде минимум. Это как правило, либо закомментаренный старый код,
либо //TODO . Так как в 99% случаев код документирует себя сам. Или юнит тесты помогают дополнить картину.
(о вырезании документации из кода: документация генерируется не из кода, а из sql базы)

Здравствуйте, mike27, Вы писали:

M>Понятие "качества" у всех очень разное. А документирование кода, это один из видов его хренового качества — если код нуждается в документации, значит он странно написан.

А как же на счёт пред\пост условий? Прикажете смотреть так: "Ага, метод делает такой-то if, значит ему можно передавать это вот"? Бред: Коментарий нужен, как минимум, для описания контракта. Так же, нестандартные и неявные решения рекомендуется коментировать, а то они в первую очередь падут жертвой рефакторинга.

Здравствуйте, AngeL B., Вы писали:
AB>... есть Evaluation ... полностью функциональна ... нет исходников, при запуске программы выдается Evaluation окно и в отчетах внизу надпись соответсвующая.

Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, mike27, Вы писали:

M>>Понятие "качества" у всех очень разное. А документирование кода, это один из видов его хренового качества — если код нуждается в документации, значит он странно написан.

_FR>А как же на счёт пред\пост условий? Прикажете смотреть так: "Ага, метод делает такой-то if, значит ему можно передавать это вот"? Бред: Коментарий нужен, как минимум, для описания контракта. Так же, нестандартные и неявные решения рекомендуется коментировать, а то они в первую очередь падут жертвой рефакторинга.

для этого ведь и существуют юнит тесты. — чтобы избегать таких проблем.
в компонентах, комментарии я делал только в случае "//todo " или workaround'a чужих проблем — в данном случае MS.

Здравствуйте, Константин Л., Вы писали:

КЛ>Здравствуйте, AngeL B., Вы писали:

AB>>Здравствуйте, globus, Вы писали:

AB>>Мы пользуемся этим (DevExpress).
AB>>Просто в восторге...

КЛ>отстой. лучше чем component one & infragictics, но все же отстой:

КЛ>1. запутанная и часто неудобная объектная модель
КЛ>2. чтобы спрятать одну кнопку зачастую приходится порождать по 5 классов.
КЛ>3. исходники отвратительны в плане оформления
КЛ>4. забывают делать очевидные вещи для extensibility

КЛ>Кароче, имхо они умеют только хорошо рисовать

КЛ>Из плюсов — адекватный и быстрый саппорт

Это ты просто Stingray не пробовал

Здравствуйте, mike27, Вы писали:

M>Приблизительна таже история из компонентами. Невозможно написать универсальный TreeList или Grid, который одинаково хорошо будет работать при абсолютно разных сценариях.

Верная мысль. Собственно, два разных компонента с общей базой завсегда предпочтительнее одного монстра. Чем мне собственно и не нравится дизайн VCL/Winforms/etc.

Здравствуйте, Mr.Cat, Вы писали:

MC>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
Ограничены 30 календарными днями.

Здравствуйте, AngeL B., Вы писали:

AB>Здравствуйте, Mr.Cat, Вы писали:

MC>>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
AB>Ограничены 30 календарными днями.
Согласно лицензии.

Здравствуйте, AngeL B., Вы писали:

MC>>>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
AB>>Ограничены 30 календарными днями.
AB>Согласно лицензии.

Спасибо. Просто было желание воспользоваться одним из компонентов для реализации прототипа приложения, и ограничение в 30 дней совсем некстати приходится.

Здравствуйте, Mr.Cat, Вы писали:

MC>Здравствуйте, AngeL B., Вы писали:

MC>>>>Я правильно понимаю, что evaluation-версии devexpress-компонентов неограничены по времени использования?
AB>>>Ограничены 30 календарными днями.
AB>>Согласно лицензии.

MC>Спасибо. Просто было желание воспользоваться одним из компонентов для реализации прототипа приложения, и ограничение в 30 дней совсем некстати приходится.
ограничение прописано только в тексте. программных ограничений нет.

Здравствуйте, mike27, Вы писали:
M>ограничение прописано только в тексте. программных ограничений нет.
Это уже лучше. Но все же попробую уложиться в месяц. Как-никак надо проявлять уважение к разработчикам.