psilogic | Небольшая авантюра :)

Небольшая авантюра :)

И до чего же мне ~~остопи...~~ осточертели разнообразные глюки виндового контрола ListView. В один прекрасный день я осознал, что на периодический отлов и исправление подобных глюков было потрачено много дней. Ну и решился я на такую авантюру: написать этот класс "ручками", так сказать, под себя. Пока получается. Позавчера сделал отображение и скроллинг, вчера - множественный выбор и перетаскивание/растягивание заголовков. Как там говорится в одной программистской поговорке: никогда не находится время, чтобы сделать что-то необходимое, но всегда находится время, чтобы переделать ;)

Это, кстати, к вопросу, как дела с bard-ом. Нормально дела, вовсю идет работа над новой версией.

Flat | Top-Level Comments Only

у нас на работе - тоже. а это - не "для дяди", это для себя :]

а «для себя» так Qt и вовсе бесплатен же…

дело не в цене, а в удовольствии :)

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

это уж кому как :) особенно, если выбор между чужим и непонятным и своим понятным ;)

Qt весьма понятна. в отличие от моего кода. %-)

А у меня наоборот - мне проще свое написать или разобраться в своем старом (да, да, я комментов пишу в достатке), чем разобраться в чужом.

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

Ну, видимо, кому как, я не отказываюсь совсем от чужого кода, просто после какой-то границы (зависящей от разных факторов) мне оказывается проще написать свой. В данном случае QT не подходит по ряду причин. Основная - продукт делаю я сам, сам опредеяю требования к нему, и требования кросс-платформенности среди них нет и не будет :) Страдания линуксоидов не тронут мое жЫстокое серЦэ. :)

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

>Основная — продукт делаю я сам, сам опредеяю требования к нему, и требования
>кросс-платформенности среди них нет и не будет
Qt — ещё и мощный тулкит, где зиллионы всего уже написаны и отлажены. %-)
алсо, QT — это QuickTime. %-)

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

Qt — ещё и мощный тулкит :)

Win SDK - тоже =)

можно мне в WinSDK увидеть аналоги хотя бы QHash, QMap, сигнало-слотовой системы? %-)

нет, stl не предлагать. %-)

[ сигнало-слотовой системы ]

такого говна даже микрософт не написало :)

что касается hash, map - то это вообще не платформо-зависимый уровень, пользуйся чем хошь, хоть STL-ем, хоть еще чем...

ты знаешь что-то лучше сигналослотов? для цпп, натурально.

виртуальные функции классов :)

ну-ну. и с ними совсем-совсем без гемора делаются связи "многие ко многим", например? и я в рантайме могу переназначать реакции? это какое-то очень сильное колдунство, это компилятор c++ и исходники надо в рантайме иметь. и технологию патчинга рабочего кода. ты считаешь, это менее черезжопно? %-)

у меня обработка событий идет так. изначально событие получает некий контрол (обычно тот, который сам его породил). потом событие передается вверх по иерархии layout-ов до родительского окна. на каждом уровне событие может быть "поглощено", чтобы не распространяться дальше. такой схемы мне хватает в 95% случаев.

а в оставшихся 5% я использую "аддоны". это значит, что к любому контролу можно прихреначить (на runtime) энное количество "обработчиков", которые будут перехватывать события, предназначенные окну, и делать что-то такое хитроуебищное... например, обслуживать drag-drop-ы или "резиновые контуры"...

и нахер мне тогда связи многие-ко-многим и переназначение реакций? если такое и понадобится, то раз в год, и раз в год мне не в падлу написать цикл.

забавная схема. у меня обычно не «всплывают», а наоборот, «тонут».

однако же схема с «хуками» не есть красива, ящитаю. ну и Qt ещё умеет сам привинцивать сигналы на обработчики с соотв. именами. понятно, что это можно ручками один раз написать массажёра и всё, но лень же — уже написано.

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

мне кажется, всплывающие разумнее. вот прикинь: есть контрол, который обрабатывает "Enter". например, многострочное поле ввода multi-line-edit. тот же "Enter" может обработать диалог как "заставь сработать default button". если фокус стоит на multi-line-edit, то он обрабатывает Enter и "съедает" его. а если это не multi-line-edit, то клавишу потом получит диалог, который его выбросит, обработает или отдаст кому-то конкретному, если знает, кому (той же клавише по-умолчанию).

если же то же самое делать сверху-вниз, тогда ты должен рекурсивно опрашивать всех child-ов "тебе Enter не надо? а тебе Enter не надо?". получится перебор всех контролов вместо однократного прохода ветки снизу-вверх.

"не есть красива" - понятие субъективное. по-моему очень даже есть красива :) по мне так одно слово "moc" однозначно решает все вопросы на тему красоты - и не в пользу той библиотеки, которая этот moc использует :)

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

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

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

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

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

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

>но ведь такая функциональность нужна лишь немногим контролам, нафиг тогда
>вызывать эти функции у всех контролов?
правильно. у кого обработчика сигнала нет — тот и не откликнется. %-)

зыж что-то у нас хилый какой-то холивар получается.

а я не холиварю, я мыслю, может, ты че умное подскажешь ;)

ежели оно всплыло до диалога, то дальше все на этом. либо у диалога есть поинтер на что-то конкретное, дополнительное, тогда это еще плюс один вызов. а всем подряд сувать - какой смысл? в том примере прикинь, если в окне есть multi-line-edit и дерево (как в студии с редактором и деревом проекта), фокус стоит на дереве. деерву Enter не нужен, и зачем тогда совать Enter в первый попавшийся multi-line-edit? это уже излишество :)

>ежели оно всплыло до диалога, то дальше все на этом.
это как это «всё»? это, то есть, диалог должен, например, знать о сущности «дефолтная кнопка» и какие события туда роутить? O_O

а enter надо всем предложить, вдруг он кому нужен? мультилайн умный, он глянет, что фокус не у него — и не станет трогать клаву. а дефолтная кнопка тупая, она увидит enter — и зажрёт, и пофигу ей на фокусы. именно чтобы такие гады не хавали чужие события, сначала его надо утопить до контрола с фокусом.

плюс подхода — диспетчер событий вообще не должен быть осведомлён ни о чём, кроме того, какое его дитё имеет фокус. и скидывает мессагу дитю. дитё в свою очередь тоже является диспетчером, смотрит на своих. и так далее. если событие никому в пень не надо — оно всплывёт на уровень выше и будет скормлено следующему контролу. и так пока контролы не закончатся, после чего ещё на уровень выше всплывёт. просто, как топором по яйцам. оверхэдом можно пренебречь, это гуя — тут даже с сотней контролов не выйдет схему затормозить (ну, у меня не выходило даже на 286-х %-).

[ то есть, диалог должен, например, знать о сущности «дефолтная кнопка» и какие события туда роутить? ]

именно. а почему бы и нет?

[ он глянет, что фокус не у него — и не станет трогать клаву ]

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

и, кстати, "не предлагать" связные списки с обращением через ~~жопу~~ индекс :))

Flat | Top-Level Comments Only

Небольшая авантюра :)

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

no subject

no subject