Здравствуйте, Al-Ko, Вы писали:
O>>Это не очень принципиально, я же написал. Но всё-таки мне кажется, что полосы прокрутки должны быть вокруг того, что прокручивается. Возьми, к примеру это окно (окно написания сообщения в янусе). Тут тоже есть Header и Message Body. Я думаю, тебя бы сильно удивило, если бы скроллер был бы от верха хидера до низа тела письма AK>ну мы же про грид говорим.
И что? Я считаю, что пользователь должен визуально сразу понимать, что именно будет скроллиться.
AK>>>а если ему ноги выдрать, обрабатывая WM_xSCROLL, все равно будет скроллить? Не пробовал, если честно, но надо будет заняться. O>>А смысл тогда им пользоватся? AK>скроллбары не будут входить в ClientRectangle...
В большинстве случаев ты им пользоваться не будешь. При отрисовке тебя больше Clip интересует, при тыканьи мышкой — зоны хидеров и строчек отдельно. В моём гриде ClientRectangle встречается один раз — в защищенном свойстве ListRectangle, которое занимает 8 строчек кода. А такое свойство всё равно писать придётся. К примеру, при минимизации формы все размеры всех контролов на ней тоже становятся (0,0). Поэтому просто так вычесть высоту хидера нельзя — отрицательное число получится. А втыкать проверки в каждом месте не очень приятно.
Здравствуйте, SiAVoL, Вы писали:
SAV> private bool _RowsHeightConst = true;
Вот это ненужно. Это не его ума дело. Будут егму отплевывать константу, будет высота строк одинаковой. Нет, и суда нет.
SAV> public bool RowsHeightConst SAV> { SAV> get { return _RowsHeightConst; } SAV> set { _RowsHeightConst = value; } SAV> }
Опять же, по тем же причинам.
SAV> private bool _ColumnsHeightConst = false; SAV> public bool ColumnsHeightConst SAV> { SAV> get { return _ColumnsHeightConst; } SAV> set { _ColumnsHeightConst = value; } SAV> }
Это вообще ред какой-то.
SAV> private VGColumnCollection _Columns = new VGColumnCollection(); SAV> public VGColumnCollection Columns SAV> { SAV> get { return _Columns; } SAV> set { _Columns = value; } SAV> }
Все префиксы идут лесом. Только если они имена пересикаются с постоянно используемыми (из стандартных пространств имен).
SAV> private VGHorScroller _HorScroller; SAV> public HorScroller HorScroller SAV> { SAV> get { return _HorScroller; } SAV> set { _HorScroller = value; } SAV> }
Здорово. Но почему не чистый интерфейс?
SAV>2. Интерфейс источника данных IVGDataSource — знает количество строк, предоставляет по запросу данные.
Вот это лишнее. Все должно быть универсально и без лишних приведений к object-ам. Интерфейс навигации должен заниматься исключительно навигацией. А данные должны отображаться пэинтерами строк. Которые и должны уже просить данные. ВГ в этом смысле только сборник алгоритомов. И алгоритмы отрисовки в его обязанности не входят.
SAV>
Во-во. И ты приплыл в да-баунд-модель.
SAV>4. Строка VGRow и коллекция строк VGRowCollection (на сколько я понимаю, наш грид полностью симметричен относительно колонок/строк)
И зачем вообще нужна коллекция строк? Он же виртуальный!
SAV>6. Некая абстракция для управления фокусом и выделением...
Во-во некая.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
AK>Если мы наследуемся от Control'а, то нам для обеспечения скроллинга нужно будет создавать свои контролы скроллбаров и лепить их к краям контрола.
Ну, почему? Можно и оконные скролеры поднять через виндузные средства. Главное, чтобы этим занимался отдельный класс.
AK>Преимущества такого подхода: не нужно лезть в WndProc и ловить WM_xSCROLL сообщения для окна, а обрабатывать только события Scroll этих скроллбаров. Недостатки: скроллбары будут находиться в клиентской области окна, поэтому придется каждый раз при вычислениях это учитывать;
Ну, это как раз фигня. Тут больше проблем с мерцанием будет. И с пересчетами при появлении/скрытии скроллеров.
AK> при одновременном появлении двух скроллбаров нужно лепить в правый нижний угол квадратик-панельку, для того, чтобы там не было дырки .
А это вообще никому не нужно. Ну, будет окно просчечивать и что?
AK>Если наследоваться от ScrollableControl или его наследников, то таких проблем не будет, но нужно будет работать с сообщениями окна.
Тоже не проблема. И вообще это задачи класса-скроллера.
AK>Короче, вроде как мы с Владом определились отталкиваться от второго варианта. Только надо вынести Scroller в отдельный класс, который потом можно будет заменить или изменить.
Вот именно. Причем последнее самое главное. Тогда по ходу можно будет махать все как хочешь.
AK>2. Интерфейс IVirtualGrid.
AK>Пока остановимся на этом:
AK>
AK> interface IVirtualGrid
AK> {
AK> int RowsCount
AK> int TopRow
ОК
AK> bool CacheRowsHeight
А это что? Кэш же вроде ВГ делает. Или я уже все заблыл?
AK> int GetBottomRow();
ОК.
AK>
Вот этот интерфейс больше похож на виртуальный.
AK>к этому интерфейсу будет обращаться грид-наследник.
Вопрос тольк с колонками. Если абстрагируем на уровне строки, то колонки ненужны. Если доходим до клонок, то их тоже нужно учесть.
AK>Дальше. Это частный случай, если строки и столбцы имеют неизменные размеры, это ОК:
SAV>> private bool _RowsHeightConst = true; SAV>> private bool _ColumnsHeightConst = false;
Вот и пусть частный случай обрабатывается наследниками. Не нужно в абстракции честности загонять.
AK>это здесь не нужно:...
Вот именно.
AK>скроллеры пока убираем: SAV>> private VGHorScroller _HorScroller; SAV>> }
А вот это не ясно почему. Это как раз мне кажется нужно оставить. Только для интерфейса никаких классов не нужно. Только интерфейсы и ссылки на них.
AK>Это не нужно, с данными работает наследник VirtualGrid.
Именно! Чувствуешь как тяжело проникает в массы идея чистой абстракции?
AK>3. Теперь о столбцах и их коллекции.
AK>Надо решить, делать ли Column компонентом (его наследником), как предложил Михалик (как DataGridColumnStyle), или не делать этого. AK>После этого нужно двигаться дальше.
Однозначно компонентом. Но Михалик высказал одну мудрую, на мой взгляд, мысль. А именно он предложил абстрагироваться еще на уровне строки, а не колонки. Это кстати красиво вписывает текстовые редакторы в иерархию виртуальных контролов. Ведь редактор это грид без колонок (ну, или с одной скрытой колонкой).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>Делать. Если у колонки появятся всякие события, например, HeaderRightClick, Sort или еще чего — тебе будет сложновато подписаться на эти события из дизайнера — придётся писать свой хитрый редактор коллекции с подпиской на сообщения, ну или делать это из кода. Кроме того, всё таки O>
O>// удобнее писать
O>clmName.ForeColor = Color.Red;
O>// чем
O>grid.Columns["Name"].ForeColor = Color.Red;
O>
O>Только не забыть поставить [DesignTimeVisible(false)], чтобы в Component Tray они не болтались почём зря.
Все намного сложнее. И кстати, случай цветных колонок очень редок. Более часто встречаются цветные строки или ячейки. И идея со стилями колонок начинает трещать по швам. В общем тут не все однозначно.
Мне больше нравится идея вообще не учитывать клонки в ВГ. Пусть этим занимется отдельный специализированный код.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>Так не получится. Как только у тебя появятся хидеры колонок, ты поимеешь кучу проблем с ScrollableControl, не говоря уж о тех проблемах, которые в нём есть от рождения — очень уж плохо управляется там скроллингом... Я пробовал и так и эдак, и через интероп — складывать скроллеры как внутренние контролы всяко удобнее.
Весь скролиг один фиг вручную переписывать. Так что это все фигня.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Al-Ko, Вы писали:
AK>Здравствуйте, orangy, Вы писали:
O>>Здравствуйте, Al-Ko, Вы писали:
AK>>>ScrollableControl нужен только для того, чтобы обеспечить наличие скроллбаров в клиентской области O>>Картинка такая на мой взгляд должна быть: AK>
Скажу честно... я разницы не вижу.
O>>и скроллер не должен продолжаться на них. AK>должен — посмотри на любой грид, да хоть бы на тот, что в Хоуме
Ну, он основан на ЛистВью — довольно примитивном и кривом контроле. Так что он не показателен.
AK>а если ему ноги выдрать, обрабатывая WM_xSCROLL, все равно будет скроллить? Не пробовал, если честно, но надо будет заняться.
И еще раз напомню, что в основном из-за очень некрасвивого дерганья при перемещении скроллеров (кода они отдельные окна). Ну, и еще раз скажу, что обстрагируя скролинг в отдельном классе вообще снимается эта проблема. Если чтоо вегда можно переписать все как нужно. Главное, чтобы сам ВГ и его потомки не лезли рулить скролингом напрямую.
Мне, например, важно чтобы грид мог бы легко быть портирован на Авалон (где сролеры станут менеджед).
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>Почитал ту ветку (честно скажу, по диагонали). Во многом не согласен с Владом, ну да это как обычно Например, я считаю абсолютно неверным рассчёт во время отрисовки.
Что ж в свою очередь скажу, что так же не согласен с безапеляционностью высказываний одного товарища в одной статье по этому поводу. Но дела это не меняет.
O> Мало того, что реакция контрола на требование перерисоваться замедляется, так еще и программно с ним работать сложнее становится.
Да по сравнению с отрисовкой замеделние просто незаметно будет. А вот по "программно с ним работать сложнее становится" ты в корен ошибаешся. Любое кэширование резко уложняет динамическое изменение контента.
В общем, тут могу скзать только одно. Я выполнял подобную работу уже не один раз, и пришел именно к таким выводам. Интересно на чем основано твое мнение?
O> Прикинь на досуге реализацию функций: O>
O>int GetRowAt(int x, int y); // для хит-тестов разных, например для драг-дропа
O>int GetRowBottom(int index); // для выпадающего меню, чтобы строку не загораживало
O>void ScrollRowIntoView(int index); // для программного показа строки, например свежедобавленой
O>
И в чем пробелма? Последнее вообще какое-то кривое воплощение. Правильно было бы сделать метод:
bool EnsureVisible(int row, int col, bool isPartialOK);
Хотя дела это не меняет. Все эти методы реализуются в лучшем виде.
Основной вопрос заключается в том, что при основные рассчеты или должны быть выполнимы во время отрисовки, или они будут дублироваться. Проверено на практике. В свое время именно отдельные рассчеты привели у нас к проблемам и плохой гибкости в их следсвии.
O>Конечно, это можно реализовать и так, и эдак, но всё-таки мне кажется, что лучше иметь готовый рассчитанный layout.
Он для каждой строки свой. Так что или придется считать все для каждой строки или оптимизировать как я говорил.
O> Да, не забудь про резиновые колонки, это очень полезная функция. Я имею ввиду возможность задавать не только фиксированную ширину (в пикселях), но и в процентах или в весах.
Если ввести абстракцию строку и пэинтер строк, то делать можно будет как угодно. Но совмещать в одной реализации гордого оленя и тепетную лать точно ненадо.
O>Что касается ScrollableControl и иже с ними... Попробуй с этим чудом поработать, сам поймёшь.
И что поймешь? Я как бы всю жизнь с ними работал и никаких проблем не испытывал.
O> Слишком много думать за программиста пытается. В этом вопросе с Владом я согласен, лучше делать свой скроллирующий контрол, но такой, какой надо.
Я не о контроле веду речь. Я о абстракции управляющей речь виду. Это разные вещи.
O> Насчёт же Авалона — я бы с этим пока не заморачивался, рано еще. Т.е. наследование может быть таким: Control -> ScrollableControlEx (это свой) -> VirtualGridBase -> ну и дальше клиенты.
Нет уж. Именно это и есть безграмотный подход. Короче, как делать скролеры уже вроде как давно решено. Что месить воду в ступе? Сроллер будет отдельным клкассом не унаследованным ни от кого. Просто классом. Получит в качестве инициализационных данных нужную информаци, ссылку на окно и т.п. и будет выплнять нужную работу. Захочет создаст скроблары отдельные, не захочет будет показывать скроллеры окна и общаться с ними по средствам месаг. Наследование тут (особненно в условиях отсуствия МН совсем ненужно).
O>Еще один момент. Не злоупотребляй интерфейсами. Они заставляют клиента (наследника VG) слишком много имплементировать.
Блин, где вы слова такие берете? Почему не реализовывать? Опять же все что нужно реализовывать пусть реализуют. В конце концов создать классы с референсными реализациями не сложно.
O> Например, если строки переменной высоты можно будет ресайзить, то должен быть предусмотрен какой-то механизм сообщения клиенту об этом для сохранения настроек.
Мля. Еще один. Прочти ту ветку что прочел вскльзь, но не вскльзь, а основательно. Тут ужу Михаликов м вредными советами хватает.
Виртуальный он на то и виртуальный, чтобы ничего не нужно было запоминать. Класс более верхнего уровня реализует все что нужно. ВГ же просто орабатывает свою логику. Его задача не сделать все самому, а увеличить уровень абстракции и взять на себя тот необходимый минимум который он в силах обработать без монстроизации.
O> А если оно совсем не нужно клиенту?
Пусть не дергается.
O> Не хотелось бы иметь VG, ради использования которого надо написать еще кучу кода, причём вида return false; или return null; Вообще не очень пониманию, зачем при общении базового класса с производным нужны какие бы то ни было интерфейсы, и так средств достаточно. Ну да вам виднее, вы уже много про это думали Удачи!
Непонимаешь потому что плохо читал ту ветку. И потму что еще не натрахался в доволь с озданием монструозных всеумеек "помогающих" пользователю. Я этого счастья наелся достыта. Спасибо, больше не надо.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>Это не очень принципиально, я же написал. Но всё-таки мне кажется, что полосы прокрутки должны быть вокруг того, что прокручивается. Возьми, к примеру это окно (окно написания сообщения в янусе). Тут тоже есть Header и Message Body. Я думаю, тебя бы сильно удивило, если бы скроллер был бы от верха хидера до низа тела письма
Ты когда в Ворде пишишь не сильно удевляешься, что скроллер заходит за линейки? А в Эксплорере что хидер захватывается? По мне так по фигу. Лиш бы работало.
O>А смысл тогда им пользоватся?
Скроллбарами? Ты сам то понял что спросил?
O>Не придётся. По-крайней мере, мне не пришлось в моём виртуальном деревянном гриде
Дык вопрос куда он при этом годится. Что же касается виртуального и деревянного — то это миф. Это невозможно в принципе. Как бы плавали...
O>Что-то вы, батенька, усложняете При нормально прописанной структуре контрола это элементарно всё...
В общем то сложного тут и правда не много. Но с оконными скроллерами и вообще ничего делать не нужно.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты когда в Ворде пишишь не сильно удевляешься, что скроллер заходит за линейки? А в Эксплорере что хидер захватывается? По мне так по фигу. Лиш бы работало.
Да фиг с ним, пусть будет хоть так, хоть эдак.
O>>А смысл тогда им пользоватся? VD>Скроллбарами? Ты сам то понял что спросил?
Не понял ты меня, речь о конкретном ScrollableControl c конкретно выдернутыми ногами. Перечитай еще раз.
O>>Не придётся. По-крайней мере, мне не пришлось в моём виртуальном деревянном гриде VD>Дык вопрос куда он при этом годится. Что же касается виртуального и деревянного — то это миф. Это невозможно в принципе. Как бы плавали...
Странный ты Влад, "это невозможно"... У меня живёт и работает, и данные подкачивает из базы через вирутальный источник данных, и иерархичность поддерживает без проблем, и быстрее твоего янусовского работает... Может в консерватории что-то подправить?
Здравствуйте, VladD2, Вы писали:
O>>Почитал ту ветку (честно скажу, по диагонали). Во многом не согласен с Владом, ну да это как обычно Например, я считаю абсолютно неверным рассчёт во время отрисовки.
VD>Что ж в свою очередь скажу, что так же не согласен с безапеляционностью высказываний одного товарища в одной статье по этому поводу. Но дела это не меняет.
Так что же статью не откомментировал соответственно? Я всё жду, жду, когда мне кто-нибудь по существу что-нибудь напишут...
O>> Мало того, что реакция контрола на требование перерисоваться замедляется, так еще и программно с ним работать сложнее становится. VD>Да по сравнению с отрисовкой замеделние просто незаметно будет.
Но будет. А надо?
VD>А вот по "программно с ним работать сложнее становится" ты в корен ошибаешся. Любое кэширование резко уложняет динамическое изменение контента.
Причём здесь кэширование? Это просто расчёт контрола, где что находится, где какие размеры, куда что выводится и в каком состоянии находится.
VD>В общем, тут могу скзать только одно. Я выполнял подобную работу уже не один раз, и пришел именно к таким выводам. Интересно на чем основано твое мнение?
Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам
VD>Основной вопрос заключается в том, что при основные рассчеты или должны быть выполнимы во время отрисовки, или они будут дублироваться. Проверено на практике. В свое время именно отдельные рассчеты привели у нас к проблемам и плохой гибкости в их следсвии.
Не очень понятно. Давай рассмотрим конкретно, есть отрисовка и есть клик мышкой. И там и там нужно знать прямоугольники для строк, колонок, хидеров и т.п. Для чего, надеюсь понятно. Если ты считаешь всё при отрисовке, ты потом пересчитывать при клике будешь, или сохранишь в отдельных структурах данных или еще как-то? Поясни, пожалуйста.
O>> Да, не забудь про резиновые колонки, это очень полезная функция. Я имею ввиду возможность задавать не только фиксированную ширину (в пикселях), но и в процентах или в весах. VD>Если ввести абстракцию строку и пэинтер строк, то делать можно будет как угодно. Но совмещать в одной реализации гордого оленя и тепетную лать точно ненадо.
Причём тут строка и painter? Размер резиновых колонок должен меняться при изменении размеров области данных грида, причём одна конкретная колонка или строка об этом и знать-то не должны. Это сущность выше строк и колонок. Можно конечно и потом прикрутить отдельный менеджер колонок или еще какую сущность, мне просто без этого никак, поэтому в моём гриде это есть. Вам может и не надо.
O>> Насчёт же Авалона — я бы с этим пока не заморачивался, рано еще. Т.е. наследование может быть таким: Control -> ScrollableControlEx (это свой) -> VirtualGridBase -> ну и дальше клиенты. VD>Нет уж. Именно это и есть безграмотный подход. Короче, как делать скролеры уже вроде как давно решено.
Ну что же, ваше дело.
O>>Еще один момент. Не злоупотребляй интерфейсами. Они заставляют клиента (наследника VG) слишком много имплементировать. VD>Блин, где вы слова такие берете? Почему не реализовывать?
Давай не будем о словах, ок? А то ты знаешь, что я могу на это сказать
VD>Непонимаешь потому что плохо читал ту ветку. И потму что еще не натрахался в доволь с озданием монструозных всеумеек "помогающих" пользователю.
Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно. Или я тебя не так понял?
Здравствуйте, orangy, Вы писали:
O>Так что же статью не откомментировал соответственно? Я всё жду, жду, когда мне кто-нибудь по существу что-нибудь напишут...
Я ее еще не дочитал. Всему свое время. Статья интересная... так что дочитаем и комментарии вставим.
Сейчас заняты разными клиент-серверами... так что не обессудь.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
VD>>Да по сравнению с отрисовкой замеделние просто незаметно будет. O>Но будет. А надо?
А есть проблемы? Оптимизировать нужно то что может дать выигрыш. Баросться за микросекунды когда основное время измеряется в десятых секунды просто глупо. К тому же от таких оптимизаций тормоза как раз и появляются.
O>Причём здесь кэширование?
А что такое по твоему предварительные рассчеты? Это и есть кэширование информации.
O> Это просто расчёт контрола, где что находится, где какие размеры, куда что выводится и в каком состоянии находится.
Во-во. И после него нужно после изменения содержимого менять еще и кэш. А так как реально рассчет проводимый в отрисовке аналогичен тому что до, то получаются лишние вычисления.
O>Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам
Примеры можно поглядеть. Мой тут ascDB.
O>Не очень понятно. Давай рассмотрим конкретно, есть отрисовка и есть клик мышкой. И там и там нужно знать прямоугольники для строк, колонок, хидеров и т.п. Для чего, надеюсь понятно. Если ты считаешь всё при отрисовке, ты потом пересчитывать при клике будешь, или сохранишь в отдельных структурах данных или еще как-то? Поясни, пожалуйста.
Зачем? Как раз при отрисовке все и рассчитывается. Потом можно уже пользоваться закэшированными данными. Хотя можно и посчитать. Клики мышами совершенно не требовательны к времени. Это тебе не отрисовка нескольких тысяч ячеек.
O>Причём тут строка и painter? Размер резиновых колонок должен меняться при изменении размеров области данных грида, причём одна конкретная колонка или строка об этом и знать-то не должны.
Ну, что могу понять. Хороший пример полного не понимания идеологии. Плохо ты читал ту ветку. Вот Al-Ko вроде бы меня понял. И как мне кажется оценил.
O> Это сущность выше строк и колонок.
Ложки нет (с)
O> Можно конечно и потом прикрутить отдельный менеджер колонок или еще какую сущность, мне просто без этого никак, поэтому в моём гриде это есть. Вам может и не надо.
Именно что можно. А раз можно, то нужно. Качественный грид — это очень сложная структура и чем больше будут абстрагированны отдельные конструкции, тем качественнее можно будет ее реализовать.
VD>>Блин, где вы слова такие берете? Почему не реализовывать? O>Давай не будем о словах, ок? А то ты знаешь, что я могу на это сказать
Ладно, следующий раз будем лепить минусы.
O>Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно.
Что-то это мнение расходится с мнением одного автора статей на нашем стайте.
O>Или я тебя не так понял?
То что ты назвал "чёткие небольшие контролы" на самом деле выраждается в слабые поделки. На горизонте нет ни одного приличного бесплатного грида или тривью, да и те что платные за частую не блещут. И виною тому как раз дизайн "все-в-одном"... который выливается в вечное создание убогого велосипеда.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
O>Странный ты Влад, "это невозможно"... У меня живёт и работает, и данные подкачивает из базы через вирутальный источник данных, и иерархичность поддерживает без проблем, и быстрее твоего янусовского работает... Может в консерватории что-то подправить?
Ага. Точноее в терминалогии. "Подкачивает" и "виртуальный" — это как бы две большие разница (с). Виртуальность подразумевает полное отсуствие хранения каких бы то нибыло ссылок на данные.
Что же касается "быстрее твоего янусовского работает", то это скорее всего пустые слова. Мой грид конечно не виртуальный, да и не писался как супер-пупер, но вот с объемистыми данными я его таки научил работать. В общем, исходники моего грида доступны... выкладывай свои потестируем.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
O>>Странный ты Влад, "это невозможно"... У меня живёт и работает, и данные подкачивает из базы через вирутальный источник данных, и иерархичность поддерживает без проблем, и быстрее твоего янусовского работает... Может в консерватории что-то подправить?
VD>Ага. Точноее в терминалогии. "Подкачивает" и "виртуальный" — это как бы две большие разница (с). Виртуальность подразумевает полное отсуствие хранения каких бы то нибыло ссылок на данные.
Ну пусть будет так Хорошо, что пришли к пониманию
VD>Что же касается "быстрее твоего янусовского работает", то это скорее всего пустые слова.
Это субъективное ощущение. Я писал как-то RSS-аггрегатор и в качестве теста залил в него свою янусовскую базу сообщений. Переключение между форумами происходило ощутимо быстрее, но не в разы, нет Тестить надо, не спорю, но см.ниже.
VD>В общем, исходники моего грида доступны... выкладывай свои потестируем.
Я рассматриваю вариант публикации своей библиотеки в open-source, даже с клиентом уже договорился, что на эту часть исходного кода он не претендует. Осталось найти время на документирование и приведение в порядок. Если всё пойдёт по плану, к лету будет доступно.
Здравствуйте, VladD2, Вы писали:
O>>Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам VD>Примеры можно поглядеть. Мой тут ascDB.
Я посмотрю на досуге.
<..поскипано по причине несоответствия идеологии..>
O>>Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно. VD>Что-то это мнение расходится с мнением одного автора статей на нашем стайте.
Да ну?
O>>Или я тебя не так понял? VD>То что ты назвал "чёткие небольшие контролы" на самом деле выраждается в слабые поделки.
Бывает и такое. Но если подходить к разработке контролов с умом, то получается хорошо.
Здравствуйте, orangy, Вы писали:
O>Здравствуйте, VladD2, Вы писали:
O>>>Я выполнял подобную работу уже не один раз и пришёл к совсем другим выводам VD>>Примеры можно поглядеть. Мой тут ascDB. O>Я посмотрю на досуге.
O><..поскипано по причине несоответствия идеологии..>
O>>>Не натрахался, точно. Зачем их вообще создавать? Лучше чёткие небольшие контролы, выполняющие именно то, что нужно. VD>>Что-то это мнение расходится с мнением одного автора статей на нашем стайте. O>Да ну?
Ага. Он как-то пел песню о том, что один универсальный контрол поддерживать проще чем... И чего это он?
O>Бывает и такое. Но если подходить к разработке контролов с умом, то получается хорошо.
И где их результаты? Кинь плиз ссылку.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, orangy, Вы писали:
VD>>Что же касается "быстрее твоего янусовского работает", то это скорее всего пустые слова. O>Это субъективное ощущение. Я писал как-то RSS-аггрегатор и в качестве теста залил в него свою янусовскую базу сообщений. Переключение между форумами происходило ощутимо быстрее, но не в разы, нет Тестить надо, не спорю, но см.ниже.
Ну, то что ты там заливал я не видел. И вообще проблемы производительности джета к гридам как бы отношение имеют опостедованное. Ты создай чистый тест, без БД и с одинаковыми характиристиками. Я на подобных добавлял миллион объектов, например. Попрбуй сделать это на своей реализации...
VD>>В общем, исходники моего грида доступны... выкладывай свои потестируем. O>Я рассматриваю вариант публикации своей библиотеки в open-source, даже с клиентом уже договорился, что на эту часть исходного кода он не претендует. Осталось найти время на документирование и приведение в порядок. Если всё пойдёт по плану, к лету будет доступно.
Ну, что же. Вот тогда и померяем.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ты создай чистый тест, без БД и с одинаковыми характиристиками. Я на подобных добавлял миллион объектов, например. Попрбуй сделать это на своей реализации...
Что значит миллион объектов? Миллион узлов? Сколько на верхнем уровне, сколько вложенных? Вложенные сразу добавлялись или по мере раскрытия веток? Подгрузка данных по мере показа узлов была или сразу всё заполнялось?
VD>Ну, что же. Вот тогда и померяем.
Всё бы тебе меряться
Например, я считаю абсолютно неверным рассчёт во время отрисовки.
