Алекс Jenter - Программирование на Visual C++. Архив рассылки Страница 15

Второй недостаток гораздо серьезнее: из-за того, что объекты-страницы закладок у меня создаются и удаляются динамически  во время переключения, состояние их элементов не сохраняется. Это не имеет значения, если у вас там одни кнопки ;) но чаще всего бывает как раз наоборот.

Помните, я вам обещал рассказать про классы CPropertySheet и CPropertyPage? Время первого еще не пришло, а вторым мы сейчас как раз и займемся. Потому как использование его вместо CDialog в качестве родительского класса для наших страниц-закладок МОМЕНТАЛЬНО снимает первую проблему. Сообщение будет передаваться куда надо и как надо. Отметьте, что CProperyPage сама наследует от CDialog, и своим поведением отличается от него  в таких вот ситуациях. А еще обычно как-то упускается из виду, что CPropertyPage можно использовать отдельно, а не в связке с СPropertySheet. 

Таким образом, первый недостаток устранен, перейдем ко второму. Здесь тоже все несложно: необходимо выбрать – либо вы будете хранить настройки каждой из закладок в содержащем их диалоге, и при переключении каждый раз их сохранять/загружать (путь мазохиста). Либо же вы все нужные закладки создадите заранее (в массиве, например), при открытии содержащего их диалога. При его же закрытии, вы, если это необходимо, все нужные данные из классов закладок можете скопировать в отдельные переменные, а затем со спокойной совестью удалить весь набор. В таком случае переключение закладок будет выглядеть следующим образом:

CPropertyPage *m_Pages[];

CTabCtrl m_Tabs;

int m_iLastPage=-1;

...

void CMyDlg::OnSelChangeTab(NMHDR* pNMHDR, LRESULT* pResult) {

 if (m_LastPage != -1) m_Pages[m_iLastPage]->ShowWindow(SW_HIDE);

 int c = m_Tabs.GetCurSel();

 m_Pages[c]->ShowWindow(SW_SHOW);

 m_Pages[c]->UpdateWindow();

 m_iLastPage = c;

 *pResult = 0;

}

Еще письмо на тему отказа работать release-версии программы. И прошу не ворчать, потому что когда сами с такой проблемой встретитесь (скорее всего, когда программу показывать нужно уже через несколько дней), скажете этому человеку спасибо! 

Сам недавно столкнулся с "проблемой Release билда". Естественно, 95% всех подобных багов – это баги с памятью. Проблемы с NULL указателями ещё менее-более отслеживаются, а вот с "перетиранием" памяти – сложнее. 

Я решил эту проблему с помощью _CrtCheckMemory(). Вообще, в Windows есть минимальный набор механизмов для отладки, они все описаны в MSDN 'Debug Routines'. 

Т.е. сначала определяем с помощью внутреннего логгинга примерное место вылета проги – это нужно делать не в Debug build (там-то всё работает :), а в Release. Простой лог можно за полчаса набросать. Если прога не использует DirectX или OGL, то можно (наверное), использовать даже MessageBox. Главное – локализовать место появление бага. Надо сразу заметить, что, как правило, место, где прога вылетает, совсем не то же самое место, где есть баг. В моём случае баг был в инициализации, а валилась функция уже во время работы. Потом работаем с помощью assert(_CrtCheckMemory()); уже в Debug build, где есть дебаггер и всё такое. 

Если программа менее-более линейна и не сильно здоровая, то можно вставить assert( _CrtCheckMemory()); прямо по ходу выполнения, перед и после каждого подозрительного вызова. Он сработает, как только обнаружит поврежденный heap – мы сразу можем видеть где это происходит, и делать выводы. Надеюсь это хоть кому то поможет.

Ну вот и все на сегодня. До новых встреч и будьте здоровы!

Программирование на Visual C++

Выпуск №14 от 14 сентября 2000 г.

Приветствую вас!

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

Предлагаю вашему вниманию интересное письмо, пришедшее пока я был в отпуске.  В нем затрагивается очень больная тема для всех MFC-программистов:

Я только что подписался на Вашу рассылку и прочитал весь архив. В первую очередь хочу присоединиться ко всеобщим поздравлениям (хоть и с нескольким опозданием) и поблагодарить Вас за то что принялись за столь нелегкий и, насколько я понимаю, практически бесприбыльный труд. Так уж получилось, что в этой области работает очень много профессионалов и любителей, поэтому вопросов накопилось очень много. Я крайне рекомендую Вам почаще направлять вопрошающих на microsoft.public.ru.vc и microsoft.public.ru.russian.programming, где подобные вещи более уместны. Хоть это и самые активные русскоязычные конференции на тему, но они недотягивают то своих западных конкурентов, поэтому свежая кровь им явно не повредит.

[…] К делу: Может я и ошибаюсь, но насколько я знаком с психологией Microsoft, можно судить, что MFC доживает свои последние дни. Она морально устарела, скорее всего эта библиотека уйдет в небытие "оставлено для совместимости" уже со следующей версией VS. Я очень хочу, чтобы Вы в своей рассылке обратили внимание на WTL (Windows Template Library) – это библиотека шаблонов похожая на ATL, способная частично (или полностью) заменить MFC. Она входит в Platform SDK начиная с Jan'2000. Пока это пробный камень, поэтому практически недокументирована. Microsoft не слишком афиширует ее появление, и те немногие программисты, которые ее используют, вынуждены разбираться во всем самостоятельно. А выгод при ее использовании очень много. Например она значительно дружественнее к WinAPI, который активно рассматривается в рассылке, чем MFC. Возможно с выходом следующей версии VS WTL будет дополнена или даже изменена и выставлена как основное средство разработки приложений в VC, так как больше отвечает предназначению C++ – созданию компактных, быстрых и эффективных приложений. Именно по этим причинам я считаю очень полезным рассмотреть эту библиотеку в рассылке, а в будущем, возможно, уделить ей больше внимания чем MFC.

Итак, есть два вопроса. Вопрос первый – что будет с MFC в будущем?  Вопрос второй : что это еще за зверь – WTL?

На первый этих двух вопросов не существует однозначного ответа. Если я разверну дискуссию на эту тему в рассылке, то наверное вы не скоро дождетесь ее окончания, настолько это острый вопрос. Скорую смерть MFC предсказывали не раз и не два, но почему-то эта смерть все никак не наступит. Даже наоборот, сейчас трудно найти объявление о найме программиста на C++ под Windows, где не требовалось бы знание MFC (и чаще всего еще и ActiveX/COM). Работодатели задают тон, и поэтому MFC и сейчас так же популярен, несмотря на всю свою нелогичность, неудобство, малонадежность и множество других недостатков. Наверное, пока что его доствоиства (а они, надо признать, все-таки есть) плюс усилия всемогущей Microsoft по его поддержке перевешивают. Да и в обозримом будущем, скорее всего, ситуация мало изменится – в следующую версию Visual Studio (о которой я писал в выпуске №8) MFC, вне всякого сомнения, войдет. Будет ли это в виде "оставлено для совместимости"? Я думаю, вряд ли. MFC cлишком уж широко используемая библиотека. Хотя это, конечно, не более чем мое личное мнение.

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

СТАТЬЯ

ЧТО ТАКОЕ WTL?

О WTL шепчут уже более года, и был даже пущен слух, что эта библиотека используется внутри самой Microsoft, и что она базируется на ATL. Конечно же, это привлекло внимание сообщества ATL-разработчиков, которые создавали пользовательский интерфейс для элементов управления ATL еще со времени появления ATL 1.1, и обнаруживали, что код, который они писали, был большей частью чистым кодом Win32 GDI. Я могу кое-что вам сообщить: WTL построен по такому же принципу.

Является ли это разочарованием? Нет, потому что сама ATL – всего лишь тонкая обертка COM, и в этом-то и заключается ее сила. Конечно, вам необходимо знать COM для того, чтобы использовать ATL, но дополнительные усилия, затраченные на изучение ATL пренебрежимо малы по сравнению с теми, которые нужны для освоения COM. Сравните это с другими библиотеками классов, где основной упор делается на изучение самой библиотеки, а что вы фактически будете знать по окончании обучения? Не так уж много о COM, это определенно.

С WTL все в принципе так же. Вы должны уметь программировать, используя Win32 и GDI. Но если вы это знаете, тогда WTL для вас – не более чем глоток свежего воздуха. Если же вы не имеете представления о Win32 и GDI, тогда лучше вам писать пользовательский интерфейс на VB.