Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, Orifiel, Вы писали:

O>>Что касается драйверов режима ядра, то здесь вы абсолютно правы. Хотя в
O>>последнее время даже такие серьезные модули можно писать на языках высокого уровня
O>>благодаря усилиям Compuware, Tetradyne, Vireo etc.

GN> А без фреймворка от того же CW разве можно только на асме?

Если речь идет об NT, можно на обычном С, являющимся языком среднего уровня.
Если VxD, то так и да на асме.

Здравствуйте, Orifiel, Вы писали:

O>Если речь идет об NT, можно на обычном С, являющимся языком среднего уровня.

Без каких-либо проблем пишу на C++. Ходят слухи, что и на Delphi пишут

O>Если VxD, то таки да на асме.

С этим лично не знаком, но таки не соглашусь:

 Содержимое папки \filemon\vxd

25.11.2005  19:03    <DIR>          .
25.11.2005  19:03    <DIR>          ..
24.09.2001  20:56            49 648 Filemon.c
31.10.2000  22:48             2 438 Filemon.h
24.09.2001  20:56             1 179 Filevxd.def
26.12.2000  12:48             1 586 FILEVXD.EXP
24.09.2001  20:56             1 756 Filevxd.lib
26.08.1999  16:54             7 024 Filevxd.map
06.09.2001  08:07               484 FILEVXD.RES
10.08.1998  22:04             1 972 Filevxd.sym
24.09.2001  20:58               370 Filevxd.vrc
24.09.2001  20:56            23 140 FILEVXD.VXD
26.12.2000  12:48               397 Makefile
              11 файлов         89 994 байт

Если есть какие-то проблемы с неподдерживаемой С конвенцией вызова — пишутся переходники, так что проблем быть не должно.

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>

SDB>Если непредвзято посмотреть — то в мфц уже в 92 году использовалось изрядное количество паттернов проектирования — одна серилизация чего стоит, тут тебе и фабрика и регистрация и двойная диспатчеризация и это повторяю в 92 году (книга Гаммы с сотоварищами, кстати, вышла много позже).

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

только к интерфейсу это имеет довольно-таки косвенное отношение
а document-view — да, правильно придумали

SDB>Это да, есть такое. Но опять-таки — неоднолетний опыт позволяет ИМХО справляться и с этим.

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

SDB>М-м-м... не соглашусь, но тут предмета для спора у нас нет — как и товарищей на вкус и цвет.

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

SDB>Приятно все-таки сойтись с "противником" без брызганья слюной и размахивания кулакакми...

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

Здравствуйте, Дарней, Вы писали:

Д>только к интерфейсу это имеет довольно-таки косвенное отношение

Ну, это я так, до кучи.

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

Вот в Видби они этим и начали заниматься — версия MFC под Windows CE переписана наново (правильнее говоря, наново портирована с десктопа). Так что по предварительным прогнозам фирму, где я работаю, ожидает в ближайшем будущем бурная сексуальная жизнь.

Д>упоминание этих трех букв не вызывает у меня ничего, кроме тихой радости, что больше мне иметь дело с этой штукой не придется

Не перевелись еще достойные последователи апокрифов Петцольда... Я это обязательно вверну эпиграфом к какой-нибудь своей статье.

Здравствуйте, Orifiel, Вы писали:

O>Прежде всего малым размером экзешников
MFC приложение с динамической линковкой будет еще меньше места занимать. При статич

O>и продуманным механизмом обработки сообщений.
Чем она принципиально отличается?

O>Также отмечу отсутствие всяких глупых классов-оберток вроде CServerSocket, CRecordset
O>и COleDispatchDriver.
А классы типа CRect, Cpoint и т.д. тоже глупые?

O>Кроме того, WTL куда рациональнее взаимодействует с COM, чем MFC.
Это заслуга ATL , a не WTL. Более того, имхо, написание COM клиента (не сервера) на MFC проще, чем на ATL/WTL.

Здравствуйте, Дарней, Вы писали:

Д>Потому и приходилось, чтобы ей пользоваться, разбираться досконально как работает каждый контрол. В какой версии шелла его ввели, в какой и как модифицировали, какие баги в нем есть. И не дай бог тебе сделать шаг влево или вправо — все отступники будут жестоко покараны
Это проблема не MFC, а WIN32 API

Здравствуйте, AndrewJD, Вы писали:

AJD>Это проблема не MFC, а WIN32 API

если MFC не скрывает проблемы Win32 от программиста — то это проблема именно MFC

Дарней wrote:

> C>Запутаной я бы тоже ее не назвал — есть определенные сложности (роутинг
> C>сообщений, система Документ-Вид), но они скорее проистекают из
> сложности
> C>решаемых задач. Ну а простые классы диалогов или окон — куда уж проще.
> напомни-ка, как там у tree view чекбоксы включаются?

Устанавливаем стиль TVS_CHECKBOXES, а используем затем макрос TreeView_SetCheckState.

Ищется абсолютно просто — открываем в MSDN Windows Shell\Windows Controls\Individual Control Reference\Tree-View Controls\Constants\Styles.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Дарней, Вы писали:

AJD>>Это проблема не MFC, а WIN32 API
Д>если MFC не скрывает проблемы Win32 от программиста — то это проблема именно MFC

Не уверен. Shell менялся позже, чем вышла MFC.

Здравствуйте, Cyberax, Вы писали:

C>Устанавливаем стиль TVS_CHECKBOXES, а используем затем макрос TreeView_SetCheckState.

а почему нельзя в CreateEx его прописать, как все остальные стили?

C>Ищется абсолютно просто — открываем в MSDN Windows Shell\Windows Controls\Individual Control Reference\Tree-View Controls\Constants\Styles.

я знаю, как пользоваться MSDN

Дарней wrote:

> AJD>Это проблема не MFC, а WIN32 API
> если MFC не скрывает проблемы Win32 от программиста — то это проблема
> именно MFC

А зачем их скрывать? Чтобы они раскрывались в самый неподходящий момент?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, AndrewJD, Вы писали:

AJD>Не уверен. Shell менялся позже, чем вышла MFC.

никто ведь не запрещал обновить версию MFC после этого

Здравствуйте, Cyberax, Вы писали:

C>А зачем их скрывать? Чтобы они раскрывались в самый неподходящий момент?

значит — надо скрывать так, чтобы не раскрывались

Дарней wrote:

> C>А зачем их скрывать? Чтобы они раскрывались в самый неподходящий момент?
> значит — надо скрывать так, чтобы не раскрывались

Пока это получилось только у тех библиотек, которые полностью сами
рисуют виджеты.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Дарней, Вы писали:
Д>гуй — это как раз то место, где микрооптимизации не имеют ни малейшего смысла. Потому что их эффекта пользователь просто не заметит.
То-то я смотрю, что программы писанные левой пяткой, начинают дивно подмигивать и похрюкивать при банальном ресайзе формы. Одно действие, занявшее 10 мс вместо 1й, пользователь конечно не заметит. Но если у тебя перерисовка окна занимает 1с вместо 100 мс, то ресайз будет смотреться просто отвратительно.

Здравствуйте, Sinclair, Вы писали:

S>То-то я смотрю, что программы писанные левой пяткой, начинают дивно подмигивать и похрюкивать при банальном ресайзе формы. Одно действие, занявшее 10 мс вместо 1й, пользователь конечно не заметит. Но если у тебя перерисовка окна занимает 1с вместо 100 мс, то ресайз будет смотреться просто отвратительно.

Да уж. На компьютере, который в своё время продавал Ваш тёзка, такого никогда не было! Может он был намного быстрее?

Здравствуйте, Sinclair, Вы писали:

S>То-то я смотрю, что программы писанные левой пяткой, начинают дивно подмигивать и похрюкивать при банальном ресайзе формы. Одно действие, занявшее 10 мс вместо 1й, пользователь конечно не заметит. Но если у тебя перерисовка окна занимает 1с вместо 100 мс, то ресайз будет смотреться просто отвратительно.

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

надо просто писать программы руками, а не левой пяткой

Здравствуйте, Дарней, Вы писали:

Д>как правило, это связано с кривой логикой, которая обновляет то, что обновлять не нужно. и перерисовывает то, что не нуждается в перерисовке.
Д>быстродействие как таковое здесь вообще ни при чем
Не, там как правило фищка в том, что происходит решение системы уравнений методом последовательных приближений — типа "уменьшили окно->укоротили панель->изменили количество видимых записей в списке->надо пересчитать размер панели->потребовалось показать скроллер->уменьшилась видимая ширина" и т.п. И на каждом шаге происходит перерисовка, т.к. все свойства изменяются синхронно. Не последнюю роль в этом играет большое количество виртуальных и косвенных вызовов, хотя я лично не мерил потери именно на это. Теоретически, они почти ничего по сравнению с самой перерисовкой весить не должны.
Д>надо просто писать программы руками, а не левой пяткой
Гм. "Не левой пяткой" в частности, означает:
— аккуратно блокировать/разблокировать перерисовку. С учетом того, что это поддерживается далеко не всеми контролами, а теми, которыми поддерживается — поддерживается по-разному.
— Упрощать GUI, сокращая количество Panel и прочих элементов, введенных исключительно для позиционирования.

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

Здравствуйте, Sinclair, Вы писали:

S>Не, там как правило фищка в том, что происходит решение системы уравнений методом последовательных приближений — типа "уменьшили окно->укоротили панель->изменили количество видимых записей в списке->надо пересчитать размер панели->потребовалось показать скроллер->уменьшилась видимая ширина" и т.п. И на каждом шаге происходит перерисовка, т.к. все свойства изменяются синхронно.

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

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

я тоже так думаю

S>Гм. "Не левой пяткой" в частности, означает:
S>- аккуратно блокировать/разблокировать перерисовку. С учетом того, что это поддерживается далеко не всеми контролами, а теми, которыми поддерживается — поддерживается по-разному.

перехватить WM_PAINT (например) и добавить там необходимую обработку — что два байта переслать

S>- Упрощать GUI, сокращая количество Panel и прочих элементов, введенных исключительно для позиционирования.

совсем необязательно (ИМХО)

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

Здравствуйте, Дарней, Вы писали:

Д>кто-то мешает заблокировать перерисовку, пока размеры всех контролов не устаканятся?
Для тех, кто читает по диагонали, повторю еще раз:
Вообще-то блокировка перерисовки для всех контролов делается по разному. И работает не для всех.
Д>к тому же, если при ресайзе окна сдвигаются/меняются в размере все дочерние контролы, но с дизайном этого окна явно что-то не в порядке
На жаргоне это называется "резиновый дизайн", и, вообще говоря, является очень правильной мерой. потому что другого способа корректно адаптироваться к различным размерам окна нет. Обрати внимание, что почти все встроенные диалоги стали в XP резиновыми.

Д>перехватить WM_PAINT (например) и добавить там необходимую обработку — что два байта переслать
Да ну? Попробуй подавить таким способом обновление ListView. А я посмотрю на результат. Ты думаешь, микрософт от делать нечего добавила в него специальный способ для временного подавления отрисовки?

Д>что действительно нужно:
Д>удостовериться, что если контролу назначили "новый" размер, который не отличается от старого — то он не должен делать перерисовку
Это и так делают практически все контролы.
Д>если перерисовка все-таки нужна, то перерисовывать только ту часть, которая действительно в этом нуждается.
Угу. Я боюсь тебя разочаровать, но для большинства контролов вычисление этой новой части — весьма нетривиальная задача. Особенно это касается всяких контейнеров, которые плохо себе представляют, как отреагируют их дочерние контролы на ресайз или перепозиционирование.
Д>Если соблюдать эти простые правила, то быстродействие самой перерисовки может уменьшаться хоть в тысячу раз — разницы никто не заметит.
Смешной же ты. Это и есть микрооптимизации — тщательно проверять, какие перерисовки можно безопасно поскипать. Если бы все было так просто, то накидывания контролов и выставления анкоров было бы достаточно для обеспечения скоростной перерисовки.
Бета 2005й студии, к примеру, страшно тормозила при докинге окон. А релиз все делает мгновенно. Ты что думаешь, там архитектуру поменяли? Нет, просто сели, проанализировали все узкие места, и выкинули лишние перерисовки.