Форум 'Виртуальный грид' на RSDN.RU

Не хватает файла IVirtualGrid.resx

Thu, 09 Dec 2010 14:37:46 GMT

Доброе время суток.
Скачал VirtualGrid.rar, попытался его скомпилировать, в результате получил ошибку об отсутствии файла в проекте IVirtualGrid.resx
Где можно получить данный файл?

Owner Draw

Mon, 17 Apr 2006 08:26:50 GMT

Добрый день.

А можно ли самому управлять отрисовкой в TreeGrid?

То есть, я перекрыл методы DrawItem() и DrawSubItem() у данного компонента, то в отладчике вижу, что данные методы даже не выполняются.
Я понимаю, что я могу поправить OnDrawItem() в самом компоненте, но как я понимаю, это не совсем верно.

... << RSDN@Home 1.2.0 alpha rev. 643>>

Rev.38

Tue, 29 Nov 2005 16:39:09 GMT

Серьезно пересмотрел и отрефакторил вертикальный скроллинг, убрал мелкие баги. А как быть с горизонтальным? У нас есть типы горизонтальной прокрутки — плавный и по столбцам. Плавный-то не проблема, а как быть со вторым, ведь у нас столбцов нет. Обращаться к Callback-у наследника? Создавать события?
В репозитории появились два дополнительных файла солюшена. Один — для GTK# под Windows (нужно иметь инсталляцию GTK#), второй — для счастливых обладателей Monodevelop (Linux-only). Надеюсь, они не причинят неудобств.

Оживим покойничка???

Tue, 23 Aug 2005 13:01:50 GMT

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

Пока, на досуге, решил проверить наш "продукт" на... кроссплатформенность. Поскольку языком проекта является C#, то особого выбора не было — речь пойдет о Линуксе. Ведь там, как известно, имеется Mono.

Изучив вопрос на сайте первоисточника — www.-mono-project.com, я пришел к следующим выводам:

— в Линуксе нужно использовать оконную среду GNOME, т.к. Mono "любит" Гном;
— для GUI лучше использовать библиотеку Gtk# (она, кстати, кроссплатформенная,
есть версия и для Windows);

Почему я остановился на Gtk# (gtk-sharp)? А других вариантов и не было. Gtk — "родная" GUI библиотека для GNOME. Кроме того, отрисовку в Gtk# можно осуществлять, используя обычные средства System.Drawing.

Чем отличается Gtk# от WinForms? В первую очередь тем, что Контрол (Control) там называется Виджетом (Widget) . Ну а если серьезно, то обе эти библиотеки являются событийно-управляемыми, обе имеют приблизительно одинаковый набор элементов управления (контролов, то бишь виджетов). Главное отличие — способ позиционирования контролов. Если в WinForms мы можем, к примеру, взять панель и положить на нее какой-нибудь TextBox, назначив координаты его правого верхнего угла (10,10), то в Gtk# такой номер не пройдет. Там вообще нет никаких координат.

Для размещения (или, по терминологии Gtk, упаковки) дочерних виджетов существуют родительские виджеты-контейнеры. Эти контейнеры могут содержать один или несколько слотов (ячеек) для упаковки дочерних виджетов или других контейнеров. Эти слоты могут быть расположены либо по вертикали, либо по горизонтали, либо в виде таблицы, причем любые смежные слоты одного контейнера могут быть объединены. И главное правило: один слот — один дочерний виджет. Дочерние виджеты могут расширяться на весь слот по вертикали и/или горизонтали, сжимать родительский слот под свой размер, устанавливать размер отступов от границ слота. Поначалу трудно привыкнуть к этим правилам, но потом убеждаешься, что они удобны.

Для визуального редактирования форм используется специальное средство — Glade. Это аналог дизайнера форм WinForms. Первое время Glade управляет тобой, но вскоре ты его одолеваешь и управляешь Glade'ом сам . Glade сохраняет всю иерархию виджетов в отдельный файл в формате XML. Этот файл может быть программно подключен в приложении, допустим, в конструкторе главной формы.

Одно плохо в Gtk# — слабоватая документация. Есть on-line вариант — в составе Mono Documentation Library (www.go-mono.com/docs), для Линукса есть его оффлайн аналог — Monodoc. Но там просто перечислены классы и прототипы методов и свойств. Очень мало примеров, очень мало описаний технологий — "How To...". Основной способ отыскать какую-либо информацию — ключевые слова, Google — и вперед по форумам и блогам. Ну да это дело временное...

Проверим работу Gtk# в Windows для .Net Framework 1.1. По этому адресу скачиваем инсталляторы gtksharp-runtime-1.9.3.1-win32-0.0.exe и gtksharp-1.9.3.1-win32-0.2.exe (всего около 16 Mb). После инсталляции мы можем создавать в VS проекты типа "Glade Project" и "Gtk# Project". Они отличаются тем, что в первом можно использовать вышеупомянутый дизайнер Glade.

Технически переход на платформу Gtk# для виртуального грида осуществляется довольно легко. Ведь ВГ был спроектирован так, чтобы максимально абстрагироваться от конкретной платформы. Нужно только заменить зависящие от платформы PalControl , PalView и DrawContext. PalControl — это родительский контрол, к которому подключается собственно грид. PalView — физическая область отображения грида. DrawContext — контекст отрисовки.Кстати, DrawContext для Gtk# практически идентичен контексту Gdi, т.к., повторюсь, мы можем делать отрисовку в Gtk# средствами System.Drawing. Просто чуть-чуть другая инициализация. Ну и конечно, главная форма для Gtk# будет совершенно другая. Там нужно подключать .glade файл, особым образом привязывать PalControl.

Надо сказать, что мне не удалось пока реализовать скроллинг, а только отображение скроллбаров. Ведь для платформы WinForms мы скроллинг, грубо говоря, "хакнули", импортировав API функции, а с Gtk# такой номер не пройдет, нужно подумать... И MultiView (возможность отображения грида сразу в нескольких окнах) я пока не занимался. Немного другой подход в Gtk...

Здесь лежит скриншот с обзором всего хозяйства под Windows. В верхней части находятся служебные окна Glade, в нижней — работающие приложения на платформах Gtk# и WinForms. Как видно, Gtk# для Windows отлично поддерживает темы XP.

Теперь опробуем наш проект в другой ОС — Линуксе.

Линуксом у меня является Debian-подобный Ubuntu. Это легковесный (всего на 1 CD) дистрибутив, в последнее время набирающий популярность. Некоторые называют его "бедноватым", но я так не думаю. Главное для меня, что в нем, как правило, используется свежий Гном, да и остальной софт последних версий. Mono устанавливаем версии 1.1.8.3 — это последний билд. Кстати, я не ожидал такой "продвинутости" от Mono. Та же .Net Framework 1.1, я различий не заметил , по крайней мере, для своих задач. Мало того, в нем можно компилировать и запускать простые приложения WinForms. А может, уже и не простые — я не пробовал... Правда, приложения WinForms пока не поддерживают тем Gtk. Авторы Mono придумали для окон и контролов какой-то серовато-невзрачный стиль а-ля Classic тема в Windows, но обещают исправить положение в будущем. Т.е. никакой Gtk# в будущем и не нужен будет, я так понимаю .

Установив Mono, в Линуксе можно скомпилировать и запустить наш проект из командной строки. Но я захотел протестировать "местную" среду разработки для Mono — MonoDevelop. Эта среда является портом проекта SharpDevelop для библиотеки Gtk#. Насколько я понял, она полностью написана на C#.

Впечатления от MD остались скорее положительные, чем отрицательные. Основные фичи IDE присутствуют, есть автозаполнение, компиляция быстрая. В официальном последнем билде (версия 0.7) есть даже поддержка Debug. Правда, пока она выражается только в остановке програмы по Breakpoint. Функции Watch, Stack Trace пока не работают. Я брал версии MonoDevelop из SVN репозитария, и по исходникам видел, что работа над этим ведется. C# — не единственный язык MonoDevelop. Есть поддержка .NET версий Java (ikvm) и Python (boo), а также VB.NET.

Также заявлена поддержка системы контроля версий и интеграция основных серверов баз данных в Линуксе — MySQL, PostgreSQL, и т.д. Есть еще и Add-In для тестирования написанных приложений — NUnit. Я бы рассказал об этом поподробнее, но мне ни разу (!) не удалось собрать последний билд из репозитария MonoDevelop. Очевидно, разработчики не обязывают себя заливать в рабочий репозитарий компилирующийся проект, или мне как-то с этим не везло. Кстати, официальный релиз, выложенный на сайте monodevelop.com, тоже не скомпилировался с включенной опцией подержки Debug. Пришлось долго гуглевать и искать решение. И еще негативный момент. Дело в том, что файлы солюшена и проекта в VS.NET и MonoDeveloop имеют разный формат. Так вот, для этого, в MonoDevelop есть специальная команда — Import Visual Studio .NET Project. И, самое печальное, что этот импорт не работает . MD просто вылетает. Это тоже лечится, но как-то руки не дошли. Пришлось самому создавать солюшн и все проекты для него.

Это было последним неприятным моментом. Проект собрался в Линуксе без малейшей коррекции исходников, которые я написал для Gtk# под Windows. Причем, скомпилировалась и часть проекта для Win32-платформы (правда я ее не запускал ). Результаты работы можно увидеть на этом скриншоте. На экране — MonoDevelop (правый верхний угол), окошки Glade слева вверху, работающая демо-версия грида — слева внизу. Кроссплатформенность.NET в действии, так сказать... Опять же отмечу поддержку тем.

Теперь можно разрабатывать Gtk#-версию грида хоть в Линуксе, хоть в Windows — благо, имеется SVN-сервис, любезно предоставленный RSDN .

Как среда разработки .NET-приложений под Линукс, MonoDevelop даже в таком виде может удовлетворить спрос, а через 6-8 месяцев, я думаю, между MD и VS уже не будет большой разницы. Не забывайте, что MD, как и Mono — свободное ПО. Кстати, название проекта "Mono" переводится с испанского как "обезьяна". Чувствую, что будут обезьянничать, пока не сделают продукт по возможностям один к одному.

Уже сейчас есть кросс-платформенная IDE среда для .NET, которую очень хвалят. Если вы не слышали о X-Develop, зайдите по адресу www.omnicore.com и убедитесь сами. До лета 2005 года эта среда отличалась от MonoDevelop большей навороченностью и стабильностью (а также ценой, т.к. MD бесплатна, а XD — отнюдь). А вот с июля в XD (с версии 1.1) появился дизайнер, который работает и с WinForms, и с Gtk#. Надо скачать trial-версию и посмотреть, что за зверь. Цена коммерческой версии, кстати, не такая уж и большая — то ли 300 баксов за одиночную лицензию, то ли около того.

Таким образом, мы убедились, что .NET-приложения можно создавать не только для MS-Windows. Не буду делать долгосрочных прогнозов (я не "Священный Воин" и не "Евангелист" ), но мне кажется, что через пару выходов новых версий Mono и MD число разработок .NET-приложений в секторе свободного ПО несомненно увеличится. Я показал здесь возможность кроссплатформенного решения на примере простенького GUI-проекта, но думаю, что и более сложные вещи (тот же Janus, например) можно будет реализовать.

Да, и самое главное . Приглашаю желающих к сотрудничеству в проекте "Виртуальный грид". Нужны свежие идеи — пора выходить из застоя...

Если проект еще жив.

Fri, 06 May 2005 10:31:28 GMT

Люди можно-ли попытаться подключится к проекту?
Если можно — скадите чем занатся.

ScrollManager

Fri, 25 Feb 2005 15:17:48 GMT

Я вот думаю, а не стоит ли нам вынести реализацию IScrollManager в отдельный класс. При инициализации грида создавать объект этого класса, и вынести его виртуальным защищенным readonly свойством, чтобы наследники могли подменять его при надобности. Необходимые методы будущего класса ScrollManager сделать тоже виртуальными, чтобы можно было наследоваться.
GridView для своей работы будет запрашивать IScrollManager у грида.

... << RSDN@Home 1.1.4 beta 4 rev. 328>>

Revision 5

Thu, 24 Feb 2005 12:54:11 GMT

Упорядочена поддержка коллекций GridView:

Решена проблема с инициализацией GridView их физическими воплощениями — реализаторами IPalView (Win32View для платформы Win32).
Проблема состояла в этом. И была решена по этой подсказке.

Действительно, пришлось реализовать в ПАЛ-контроле ISupportInitialize и в методе EndInit сверху донизу создавать для GridView соответствующие PalView по всей иерархии. Для этого в интерфейс IGridView был добавлен метод Initialize.

Кроме этого, решена проблема с корректной обработкой удаления GridView из коллекции. Во-первых, CollectionBase не реагировала на удаление своего элемента в дизайн-тайме. Пришлось перекрывать метод DestroyInstance в редакторе коллекции.
Во вторых, при удалении GridView, нужно удалить контролы PalView из всей нижестоящей иерархии. Для этого в интерфейс IGridView был добавлен метод Cleanup.

Результаты можно посмотреть в репозитории. Вью уже довольно осознанно могут создаваться, группироваться, удаляться.
Просьба протестировать.

Еще не очень четко работает докинг, мне кажется, что свойство Anchor тоже необходимо ввести. Собственно, оно и существует у всех контролов.

Теперь в планах — сделать горизонтальный скроллинг (у нас его еще нет) и научить грид отображать фиксированные области.
С реализацией этого будет уже такскыть первый milestone в нашей работе.

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

Ну и изменить текст описания проекта, т.к. он безнадежно устарел.

ЗЫ. Влад, ты можешь зайти в солюшн в репозитории и сделать там проект Test1 стартовым в конце концов!

... << RSDN@Home 1.1.4 beta 4 rev. 328>>

Объектная модель (review)

Sat, 19 Feb 2005 12:14:21 GMT

После просмотра текущих исходников у меня возник ряд вопросов/замечаний.

1. Сильная связанность
То, что проектировалось красивыми интерфейсами на деле оказалось собрано в кучу и сильно завязано между собой.
Например, интерфейсы IInputTranslator, IScrollManager, IHighlightManager (пусть даже пока не определились с его структурой) оказались собраны в одном "God-like" интерфейсе (IGridView).
В большинстве увиденных мною случаев в качестве приема ОО композиции использовалось наследование. Следовательно, ни о каком повторном использовании кода говорить не приходится.
Во многих ситуациях, когда нужна реакция на какое-то событие, используются методы, а не делегаты. Для примера, можно поискать любой метод, имя которого заканчивается на "Changed".

2. Не нашел заявленных интерфейсов для отрисовки строк, столбцов, ячеек (IRowPainter, ICellPainter, IColumn, IRowStyle). Вместо этого вся отрисовка происходит силами класса SimpleGrid.

3. Очень запутанная ситуация с IPalView/IPalViewManager и IGridView/IGridViewManager.
IGridView наследует IGridViewManager.
IGridViewManager содержит ссылку на IPalViewManager.
IPalViewManager содержит ссылку на IGridView.

Насколько я понял, PAL — Platform Abstraction Layer ?

4. Win32Platform.Win32PALControl и Win32Platform.Win32View оба реализуют интерфейс IPalViewManager, причем Win32PALControl ссылается на Win32View. Зачем ?

5. IScrollManager, имхо, слишком нагружен. Если появится еще какой-нибудь способ скроллинга (помимо мыши, клавиш и GUI) — будем еще методы добавлять ?
По моему, там должен быть только один набор методов Scroll{Left/Right/Up/Down}, а реализации для конкретных устройств — в подклассах.
К тому же, читая исходники у меня создалось впечатление, что скроллинг — основная тема в гриде, т.к. метода для скроллинга / отображения скроллбаров присутствуют чуть ли не в каждом классе.

... << RSDN@Home 1.1.4 beta 2 >>

Columns

Sat, 19 Feb 2005 10:38:01 GMT

Не волнуйтесь, это еще не наш грид. Это JanusGridEX . Наш должен быть еще круче .

Но я бы обратил внимание на столбцы этого грида. Как видно на рисунке, в этом гриде имеется несколько наборов столбцов, т.к. здесь иерархически представлено несколько таблиц. А у нас в ВГ в планах имеется только одна коллекция столбцов, сквозная для всего грида. Непорядок... Какие будут предложения?

... << RSDN@Home 1.1.4 beta 4 rev. 328>>

Целесообразность вложенных GridView

Sat, 19 Feb 2005 09:57:37 GMT

Опять хочу обсудить этот вопрос.

Я полагаю, что фичи нужно делать только исходя из их целесообразности, а не "так, на всякий случай".

Зачем нужен режим Multiview для грида? IMHO только для удобства просмотра или редактирования.

В чем заключается "неудобство"? В том, что на экране не всегда одновременно присутствуют области, которые мы хотим просматривать/редактировать.

Почему не присутствуют? Да потому что размер грида может превышать размер окна просмотра GridView! У грида есть только две размерности — длина и ширина. Мы можем не видеть весь грид потому, что он не помещается в область просмотра либо по ширине, либо по длине. Одним из решений этой проблемы есть скроллинг. Но при прокрутке мы можем видеть только одну из нужных нам областей, в то время, как вторая исчезает из области просмотра.

Сколько независимых областей грида мы должны видеть на экране? В подавляющем большинстве — одну , для интенсивного просмотра/редактирования — две будет достаточно(IMHO в 99% случаев). Ну а если мы обладаем возможностями Юлия Цезаря, то тогда три, или четыре.

Каким образом помогает режим Multiview посматривать или редактировать грид? Он позволяет видеть независимые области грида без скроллинга, путем предоставления нам окон для просмотра этих областей. Так, если нам не хватает ширины области для просмотра всех колонок грида данной строки, мы заводим два GridView, располагающихся рядом, справа и слева.
А если мы хотим просмотреть области в одном столбце, но в разных строках, мы заведем себе для этого два вью, расположенных сверху и снизу.

Всю эту философию я развожу здесь к тому, что большего, чем предоставляет нам в плане Multiview такое уважаемое приложение, как Excel, и делать-то не надо — для этого нет целесообразности.

Докажете мне обратное?

... << RSDN@Home 1.1.4 beta 4 rev. 328>>

RsdnGrid переведен под Subversion

Fri, 18 Feb 2005 23:35:41 GMT

RsdnGrid переведен под Subversion (он же SVN)

Путь к репозиторию:

svn://rsdn.ru/RsdnGrid

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

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Описание того как подключиться и где взять SVN можно почерпнуть в R#-овской статье (естественно заменив мысленно RSharp на RsdnGrid).

Перезжаем на SVN

Wed, 16 Feb 2005 19:53:59 GMT

Господа для продолжения проекта и урощения его администрирования нужно перехать на SVN.

Для этого просьсба прислать мне логин и пароль.

Так же личная просьба к Al-Ko, чтобы он выслал мне последнюю версию проекта, так как клиент ЦВС-а у меня отсутствует. Я залью проект в СВН.

... << RSDN@Home 1.1.4 beta 3 rev. 279>>

Проект мертв ?

Mon, 14 Feb 2005 23:09:13 GMT

Последний пост наблюдался в конце октября.
Разработка больше не ведется ?

Clipboard?

Sun, 10 Oct 2004 11:31:12 GMT

Всем привет

Вопрос такой — а поддержка буфера обмена будет? Например, как здесь? Если коротко, то этот контрол позволяет скопировать данные через clipboard в Excel, причем в Excel скопированные данные так же располагаются по ячейкам.

Устал от рефакторинга

Tue, 07 Sep 2004 09:10:25 GMT

У меня есть предложение. Я заливаю в проект свою последнюю версию (сохраненную до рефакторинга) и продолжаю работать дальше. По крайней мере, сейчас имеются две актуальные задачи:

— создание фичи фиксированных строк (только так, шоб все работало без глюков )
— создание возможности внятного удаления/добавления View.

А рефакторить можно потом, когда все будет работать.

Или?..

... << RSDN@Home 1.1.4 beta 2 rev. 0>>

Какие новости?

Sat, 21 Aug 2004 12:15:47 GMT

Я уже приехал. Как продвигаются дела?

... << RSDN@Home 1.1.4 beta 2 >>

Взял шашку в руки

Tue, 10 Aug 2004 12:27:01 GMT

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

2 Al-Ko: пожалуйста не используй коментарии типа

/// коментарий

такие коменты зарезервированы для xml-документации, и потом когда будем ее генерить компилятор будет варнинги кидать

И еще, в коментариях лучше говори зачем ты делаешь то или или другое, а не как ты это делаешь.
Например коментарий типа "увеличиваем в цикле смещение пока оно не станет больше шага скроллинга" (за точность цитаты не ручаюсь, но что-то в этом духе). Так вот, это я глядя на код и сам пойму, а вот зачем то делается пока не нарисуешь на бумажке строчки не понять (по-крайней мере мне).

В общем если кто не согласен, будем спорить ( ) ибо так рождается истина

... << RSDN@Home 1.1.4 beta 2 >>

Есть где-нибудь текущий снапшот?

Fri, 30 Jul 2004 11:52:44 GMT

subj собственно. Как например для RSharp?

нет файла IGridView

Fri, 30 Jul 2004 10:34:15 GMT

сабж

... << RSDN@Home 1.1.4 beta 2 >>

Фиксированные строки и столбцы

Wed, 28 Jul 2004 05:40:28 GMT

Думаю поковырять этот вопрос. Как я его вижу:

Для них надо выделить отдельные абстракции (FixedRow, FixedColumn) и регистрировать в... в IVirtualGrid? Располагаться фиксированные строки и столбцы могут только по краям области отображения. View используя информацию о них изменяет область прокрутки и пр. Вроде так... Ну и далее уже на базе например FixedRow надо будет реализовать заголовки столбцов.

Еще один вопрос, надо ли выделять абстракцию строки и колонки (Row и Column) которые будут знать давать информацию о ширине, высоте, параметрах отрисовки. Они будут использоваться как для работы с простыми строким, так и с фиксированными.

... << RSDN@Home 1.1.4 beta 2 >>