Комментарии 16
мы используем MFC для разработки пользовательского интерфейса.
Мои вам соболезнования!
Не совсем понятно-вы унаследовались от стандартного грида или сами реализовали с нуля?
И еще-что за странный тип данных UINT_t?
И еще-что за странный тип данных UINT_t?
«Стандартного грида» вроде как нет. Реализовали с нуля — наследование от основного оконного класса CWnd.
Вся платформенная специфика локализована в двух классах: GridWindow — контрол управления и DrawContext — рисовальщик. Всё остальное написано на C++/STL.
UINT_t это typedef на какой-то беззнаковый целочисленный тип (можно для себя решить: использовать «большие» 64bit или «маленькие»32bit числа).
Вся платформенная специфика локализована в двух классах: GridWindow — контрол управления и DrawContext — рисовальщик. Всё остальное написано на C++/STL.
UINT_t это typedef на какой-то беззнаковый целочисленный тип (можно для себя решить: использовать «большие» 64bit или «маленькие»32bit числа).
UINT_t это typedef на какой-то беззнаковый целочисленный тип
а как же общепринятый size_t?
В целом, UINT_t это единственная придирка к стилю, так все красиво и читабельно.
Ждем на github!
size_t опасен, если будете его сохранять куда-то в бинарном виде, а потом мигрировать проект с 32 на 64 бита.
По поводу github — думаю сначала написать еще заметку — есть еще что рассказать. Реально по срокам, думаю, после новогодних каникул появится что-то более-менее юзабельное.
По поводу github — думаю сначала написать еще заметку — есть еще что рассказать. Реально по срокам, думаю, после новогодних каникул появится что-то более-менее юзабельное.
пистолет тоже очень опасен, если стрелять им в себя. да и UINT_t может поменяться, судя по вашим же словам!
По-честному, если речь о количестве строк или столбцов, то 64-битный беззнаковый тут точно не нужен, это уже наверняка привычка к корпоративному Coding Style в вас говорит :)
По-честному, если речь о количестве строк или столбцов, то 64-битный беззнаковый тут точно не нужен, это уже наверняка привычка к корпоративному Coding Style в вас говорит :)
пистолет тоже очень опасен, если стрелять им в себя. да и UINT_t может поменяться, судя по вашим же словам!Я лишь хотел сказать, что пользователь этой библиотеки вначале для себя решит каким будет у него UINT_t и потом никогда-никогда его не менять.
По-честному, если речь о количестве строк или столбцов, то 64-битный беззнаковый тут точно не нужен, это уже наверняка привычка к корпоративному Coding Style в вас говорит :)Согласен, например нам вполне достаточно unsigned int.
Хотя если заниматься лихачеством — можно создать грид с неописуемым количеством строк и задать текстовую модель, которая сама ничего не хранит, а лишь выдает строковое представление номера строки. По идее этот грид должен на этом синтетическом примере тоже работать и память не особо кушать.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Так вы просите показать половину возможностей DevExpress, а что конкретно в эту половину должно входить не говорите :)
Я так понимаю, вы просто хотите сказать, что уже есть решения с очень богатым функционалом (правда за деньги и на одной платформе). Я с вами соглашусь. Могу привести еще один подобный пример QTitan. «Тягаться» с ними в одиночку тяжело, и, я думаю, не нужно.
Мне нравиться один из принципов, которым руководствовался Страуструп, когда создавал C++. Он говорил — Вы не должны платить за то, чем не пользуетесь. Например, если вы не пользуетесь полиморфизмом — вы не должны платить за косвенные вызовы функций, они должны вызываться так же быстро как и в С или даже по возможности встраиваться.
Этот принцип я попытался воплотить и здесь. Грид должен позволять использовать себя и как простой список (ListBox) и как аналог Excel (с дикими раскладками ячеек, возможностью задавать итоговые поля и т.п.). Это похоже на gentoo. Первый пользователь собирает грид с небольшим набором стандартных Views и получает небольшой и шустрый контрол. Второй пользователь собирает грид с другим набором классов (их будет больше и их логика работы будет сложнее и тормознее) — и получает увесистый модуль. Так вот, первый пользователь не платит за всё многообразие, которое потенциально может получить.
Опять же, проведу аналогию с С++. Есть грид, который, как у меня описано, может отображать Views. Сам по себе грид малополезен (как и С++). Но есть реализованный набор стандартных Views (для selection/column-rows resizing/filtering/sorting и т.п.) — это аналог стандартной библиотеки. Таким образом гридом уже можно сносно пользоваться «из коробки». Но если грид позволяет реализовывать дополнительные Views, которые могут сочетаться со стандартными Views или написанными кем-то еще. И все их можно комбинировать в одном контроле (это аналог С++ библиотек). Вот тут появляется мощь. Грубо говоря — если кто-то сделал view для отрисовки цвета, не как у меня в примере в квадратике, а, например, в кружочке и опубликовал этот view, то грид автоматически для всех обогатился новой возможностью.
Моя цель именно такая — постараться найти такую архитектуру грида, при которой повторное использование разных кастомизаций будет легким и естественным. Постараюсь более внятно написать в следующей статье.
Я так понимаю, вы просто хотите сказать, что уже есть решения с очень богатым функционалом (правда за деньги и на одной платформе). Я с вами соглашусь. Могу привести еще один подобный пример QTitan. «Тягаться» с ними в одиночку тяжело, и, я думаю, не нужно.
Мне нравиться один из принципов, которым руководствовался Страуструп, когда создавал C++. Он говорил — Вы не должны платить за то, чем не пользуетесь. Например, если вы не пользуетесь полиморфизмом — вы не должны платить за косвенные вызовы функций, они должны вызываться так же быстро как и в С или даже по возможности встраиваться.
Этот принцип я попытался воплотить и здесь. Грид должен позволять использовать себя и как простой список (ListBox) и как аналог Excel (с дикими раскладками ячеек, возможностью задавать итоговые поля и т.п.). Это похоже на gentoo. Первый пользователь собирает грид с небольшим набором стандартных Views и получает небольшой и шустрый контрол. Второй пользователь собирает грид с другим набором классов (их будет больше и их логика работы будет сложнее и тормознее) — и получает увесистый модуль. Так вот, первый пользователь не платит за всё многообразие, которое потенциально может получить.
Опять же, проведу аналогию с С++. Есть грид, который, как у меня описано, может отображать Views. Сам по себе грид малополезен (как и С++). Но есть реализованный набор стандартных Views (для selection/column-rows resizing/filtering/sorting и т.п.) — это аналог стандартной библиотеки. Таким образом гридом уже можно сносно пользоваться «из коробки». Но если грид позволяет реализовывать дополнительные Views, которые могут сочетаться со стандартными Views или написанными кем-то еще. И все их можно комбинировать в одном контроле (это аналог С++ библиотек). Вот тут появляется мощь. Грубо говоря — если кто-то сделал view для отрисовки цвета, не как у меня в примере в квадратике, а, например, в кружочке и опубликовал этот view, то грид автоматически для всех обогатился новой возможностью.
Моя цель именно такая — постараться найти такую архитектуру грида, при которой повторное использование разных кастомизаций будет легким и естественным. Постараюсь более внятно написать в следующей статье.
Писать велосипеды под MFC в 2013 году это круто, уважуха!
Вспомнил старый FlexCell. Когда-то в 2004-м использовал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Элемент управления Grid