КРАЙНЕ ПОЛОЖИТЕЛЬНО!!!

имею несчастье использовать в своем проекте MFC грид с codeproject.
такое кривописье еще поискать...
короче начинал я грид раза 3, обламывался, там как минимум 5-7 чел/мес чистой работы, вот если бы с кем-то...

давай! прикол

2 alex_k
да, примерно...

я сразу разрабатывал 3 класса в иерархии:
1. Берет сообщения виндоуз и преобразует их в вызов виртуальных функций, отвечает за "диспечерезацию", вызов прорисовки, "таскание" хедеров и пр. Класс большей частью виртуальный, все остальное ему подают наследники...

давай код, если что - можно попробовать на какой-нить CVS забабахать.

куда ж ты пропал? ни ответа ни привета

сорри,
во-первых - разница во времени,
во-вторых - делал срочную демонстрашку на C#, домой доехал только в 2 ночи, посмотрю сегодня обязательно, уже кое-что меня там прикололо...

так, все ясно,\r
сходи плиз по этой ссылке\r
прикол?\r
\r
я ту либу начал разрабатывать именно для того, чтобы грид на ней сделать \r
\r
делать его на MFC - себя не уважать\r
\r
в промежуточных результатах я продвинулся чуть дальше, ты дальше в работающем прототипе, похвально\r
\r
если есть столько энергии и времени, могу свою либу закинуть для затравки,\r
у меня, к сожалению, времени в обрез в последнее время, максимум могу 1 час в день этим заниматься, но оно того стоит, надеюсь, что немного погодя (в начале декабря) появиться чуть больше времени\r
\r
смотрю все чаще народ от MFC и ATL отходит, пральна

действительно просто,
замечания есть

1. что-то грид себя ведет не очень :)
2. ничего страшного, если виртуальных методов будет больше
3. подход, мягко говоря, "в лоб"
4. модель грида представляю себе сложнее, как минимум надо отделить:
- сам грид
- источник данных
- продумать систему событий, причем "человеческую", а не через сообщения Windows или только лишь через виртуальные функции

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

----
Что подразумевает под собой разработка своей GUI-либы, как минимум:
#1 управление потоками, т.к. все события на конкретное окно приходят только в рамках того потока, в котором это окно было создано,
#2 из #1 вытекает необходимость разработки (раз уж на то пошло) всей "обвески" для управления процессами, потоками, памятью, событиями, синхронизацией, task-ами, таймерами и т.д. и т.п.
#3 достаточная объектная модель визуальных компонентов, надо отходить от понятия "окно" (UIWindow) и переходить к более абстрактным Control->ControlContainer->Form->MDIMainForm и т.д. Почему? Хотя бы потому, чтобы иметь одну и ту же объектную модель для обычного контрола и window-less контрола.
#4 обработка сообщений Windows, у тебя все на этом построено, а я это прячу в одном из базовых классов, т.е. ты можешь свой некий класс (своя кнопка, к примеру), унаследовать как от обычного контрола, так и от Window-less контрола, что позволит тебе легко и единообразно разработывать сложные GUI элементы
#5 независимость от MFC/ALT/WTL - гут! но надо продумать схему взаимодействия с другими окнами для этих ситуаций
#6 нужна своя модель для графических ресурсов и систему слежения за этими ресурсами

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

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

Если у тебя есть время и силы на эксперименты, с удовольствуем помогу, блин, просто не хватает человека, который бы этим занимался все время. К тому же, надеюсь (почти уверен), что к этому делу с удовольствием присоединятся еще несколько человек. :)

---
Повторюсь, в любом случае - похвально, хотя и бажит :)
Есть желание повторить на чуть более серьезном уровне?

Шутка?) на самом деле реализовать грид - это примерно 2 недели работы..причем не напрягаясь

Шутка? А сколько элементов управления для РЕДАКТИРОВАНИЯ ячеек в таком гриде.
Для примера, в переделанном мною MFC Grid от codeproject их 10 и только их разработка заняла в общей сумме на неделю больше.

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

дело-то не в этом.

Знаешь, я сначала тоже думал что нужно плясать от ячейки, но потом понял - это тупиковый вариант. Получается в конце концов, что каждая ячейка должна быть производной от какого-то базового класса. Типов ячеек - может быть мульён. Вот например:
1) данные в ячейке должны быть представлены определенной bmp
2) данные в ячейке не просто строка - а несколько строк например:сумма в рублях/ сумма в валюте
Попробуй такую фигню реализовать на стандартных гридах? может быть и сможешь, но во что тебе это станет?

1)это да, ПОЧТИ каждая. Используя продумманную объектную модель можно обыграть случаи, когда ячейка уникальна для каждой клеточки, или когда имеем регулярную структуру типа грида для отображения/редактирования таблицы БД, тогда ячеек надо столько, сколько колонок и не больше.
2) кто мешает сделать тип ячейки - "контейнер ячеек", которая при своей перерисовке и обработке событий просто передает их дочерним элементам?

А нет стандартных гридов, ActiveX - не в счет.
А Infragistics - мощщщща, но торррррмозззз....

2) vdimas
Когда я еэто всё писал у меня была цель не создать каку-то монолитную библиотеку, а просто некоторый набор конкретных ресурсов, любой из которых можно было бы выделить и не использовать всё остальное.
Пример с MFC - попробуй допустим взять там какой-то один компанент и использовать только его, Пусть даже хотябс CComboBox. Это просто невозможно. А я сделал так, что если тебе нужен только Grid (который у меня называется UICage -клетка) то бери только его.

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

а че тут обсуждать?

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

тоже самое от бухгалтера, когда он выписку из банка на 150 строк набивает...

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