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

имею несчастье использовать в своем проекте 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 строк набивает...

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

gardenman писал:Написать такое намного проще. Это еще ерунда, когда в таблице всего десяток колонок... А если таким образом нужно вводить не просто выписку, а платёжное поручение? сколько там всяких параметров может быть?
Скажи честно - формы тебе делать лень, и просто легче всё свалить на грид,
дескать указал тока колонки, а дальше хоть трава не расти.

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

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