Высвободил более 5 Гигабайт на диске, удалив файлы etl. Что это и можно ли удалять?
Заметил, что накопился существенный объем файлов с расширение etl в папке C:\ProgramData\Microsoft\Diagnosis\ETLLogs. Откуда они берутся и можно ли их безболезненно удалить?
Сама аббревиатура ETL расшифровывается как Extract, Transform и Load, то есть извлечение, преобразование и загрузка. Подобные файлы накапливают в себе разные системные события, журналы обращений к диску, различные события ядра операционной системы и объединяют их в единое хранилище. Windows 10 хранит в них данные телеметрии, что наводит на мысль о их никчёмности для конечного пользователя.
Стоит отметить, что это не какое-то эксклюзивное изобретение Microsoft и такие данные собираются сейчас повсеместно и используются различными сервисами при машинном обучении, исследовании маркетинговых данных и бизнес-аналитики, да много для чего.
Теоретически, Windows записывает туда различные предупреждения, ошибки или другие события, которые должны использоваться для устранения потенциальных проблем. По заверениям Майкрософт, отправляется только минимальный объем данных, необходимый для защиты Windows. Что там происходит на практике, остаётся только догадываться, но объём этих данных я бы не назвал маленьким. Так на терминальном сервере с 20 пользователями за месяц набегает около 1.5 Гигабайт данных!
Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Сборки для сбора данных и предварительные сборки
(Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds.)
Параметру «Разрешить телеметрию» (Allow Telemetry) выставляем значение 0 или «Отключена». Насколько я понимаю, полностью отключить телеметрию в Windows всё-таки не получится, но таким образом можно существенно снизить объёмы накопление логов.
Если считаете статью полезной, не ленитесь ставить лайки и делиться с друзьями.
Комментариев: 2
Большое вам спасибо
Жаль, что не предусмотрели Reg-файл для Windows Home
Накопился большой объем файлов C:\ProgramData\Microsoft\Diagnosis\ETLLogs с расширение etl
Гуглю. но пока в голове не очень укладывается что это.
Что, это, как с ними быть? Чистить? И можно ли отрегулировать политиками?
Ответы
Нашел еще в шедулере задачи Microsoft Compatibility Appraiser «Сбор телеметрических данных программы при участии в программе улучшения качества ПО»
Могли бы уточнить, если указанная задача активна?
Сообщите пожалуйста если следующие службы на сервере активны?
Для того чтобы просмотреть в политике если Телеметрия включена, необходимо выполнить следуюшие шаги(на английском):
Если верить строномиму источнику, то этот файл лог отностится к телеметрии, и если это так, то его можно удалить, но лучше дождаться еще ответов от других участников форума. Также перед тем, как его удалить желательно понять, какая задача способствует наполнению данных в указанный лог событий.
Avis de non-responsabilité: Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Автор: Алексей Ширшов The RSDN Group Источник: RSDN Magazine #1-2003
Опубликовано: 12.06.2003 Исправлено: 10.12.2016 Версия текста: 1.1
Предисловие
Библиотека WTL делает маленький шаг в сторону больших библиотек. Он маленький потому, что WTL – это всего лишь тонкая обертка над WinAPI. Однако огромное количество рутинных операций WTL берет на себя, позволяя создавать компактные и эффективные приложения (такие же, как и при использовании голого WinAPI), используя при этом красивые объектно-ориентированные обертки. Ювелирное применение шаблонов делает WTL очень гибкой и элегантной библиотекой. WTL очень компактна и полностью доступна в исходных кодах. Мне многое в ней не нравится, но я понял и научился использовать ее мощь. Она намного сложнее MFC (главным образом из-за тех же шаблонов и большого количества макросов), но те, кто программировал на WinAPI, должны ее усвоить с легкостью.
С помощью стандартных и нестандартных инструментов библиотеки WTL вы можете создавать пользовательский интерфейс, ничем не уступающий WinForms, при этом последняя будет «тянуть» с собой огромный рантайм. Выводы делайте сами, я же предпочитаю гибкость, независимость и прозрачность.
Обзор стандартных классов
В этом разделе рассмотрены стандартные классы библиотеки WTL, которые почему-то не нашли должного отражения в статьях RSDN, CodeProject и др. Здесь представлены их назначение, функциональные возможности и баги.
CAppModule
Класс приложения, пришедший на смену CComModule, предназначен для хранения циклов сообщений (CMessageLoop) потоков приложения, а также для рассылки сообщения WM_SETTINGCHANGE всем подписавшимся окнам. Внутренние члены класса CAppModule не защищены критическими секциями, что можно рассматривать как баг.
Для чего нужны несколько циклов обработки сообщений? Для того чтобы каждый желающий класс мог создать и обрабатывать свои Idle-обработчики и фильтры. Для чего нужно создавать подписку на сообщение WM_SETTINGCHANGE? Дело в том, что это сообщение рассылается только окнам верхнего уровня (окна, не имеющие родителей) и не рассылается дочерним. Для того чтобы дочернее окно могло обрабатывать сообщение WM_SETTINGCHANGE, его нужно подписать на это сообщение с помощью функции AddSettingChangeNotify. Механизм рассылки следующий: класс CAppModule создает скрытое окно верхнего уровня, и в его оконной процедуре обрабатывает сообщение WM_SETTINGCHANGE, перебирая массив подписчиков и посылая им это сообщение. Вот часть кода:
На этом можно завершить обзор класса CAppModule, но хочется сказать об еще одной то ли ошибке, то ли особенности. Ни один из стандартных классов WTL, а это CCommandBar, CScrollImpl, CSplitterImpl и др., имея в карте сообщений обработчик WM_SETTINGCHANGE, не подписывается на это сообщение. То ли забыли ребята из Microsoft подписаться на WM_SETTINGCHANGE, то ли забыли, как работает сообщение, но факт остается фактом: при приходе WM_SETTINGCHANGE окнам верхнего уровня ни один из стандартных control-ов WTL его не получает.
CServerAppModule
Этот класс предназначен для использования в приложениях, являющихся одновременно Automation-серверами. Он включается в проект вместо CAppModule, если вы установите галочку «Create as COM server» при работе мастера создания проектов. CAppModule является базовым классом для CServerAppModule. Вот список переопределенных и новых функций класса:
Класс работает следующим образом: в функции WinMain после инициализации разбирается командная строка (при этом почему-то не используются функции ParseCommandLine). Если приложение запущено не для регистрации/дерегистрации, вызывается функция StartMonitor. Она создает поток, в котором, в конечном счете, вызывается функция класса приложения MonitorShutdown. Этот поток «засыпает» в ожидании события. После вызова StartMonitor вызывается функция регистрации фабрики класса в ROT (RegisterClassObjects). Если все прошло успешно, вызывается либо глобальная функция Run, приводящая к созданию главного окна приложения, либо функция Run локально созданного цикла сообщений (CMessageLoop). При уменьшении счетчика ссылок модуля до нуля, событие устанавливается в сигнальное состояние, что приводит к завершению дополнительного потока и посылке главному потоку сообщения WM_QUIT. Если приложение запущено интерактивно (в командной строке не присутствуют «Automation» или «Embedding»), после создания главного окна приложения счетчик ссылок модуля увеличивается, что препятствует завершению приложения после удаления последнего объекта.
После выхода из главного цикла главного потока приложения, производится очистка: фабрика класса удаляется из ROT и вызывается функция класса приложения Term.
Видимых багов в классе замечено не было, однако код написан очень посредственно. Например:
Я бы поставил здесь ATLASSERT для проверки входного параметра. То же касается функций ParseCommandLine и RegisterAppId. Внутренние члены не защищены критической секцией.
CThreadManager
Этот класс создается мастером создания проектов, если вы выбираете тип Multi SDI Application. Такое приложение отличается от обычного SDI тем, что оно поддерживает несколько окон (как MDI), но для каждого создается свой элемент в таскбаре (TaskBar). Так работает, например, Internet Explorer. Все появляющиеся в таскбаре окна принадлежат одному процессу, однако исполняются в разных потоках.
Данный класс изобилует всевозможными багами, о чем речь пойдет ниже. Класс очень прост в использовании. Для создания нового окна просто вызывайте:
Так как окна исполняются в одном процессе, у вас не должно возникать проблем с передачей данных между ними. К сожалению, сейчас нельзя передать для вновь создаваемых потоков параметры командной строки, но это довольно легко исправить. Можно также установить в функции RunThread обработчик исключений SEH, чтобы ошибка одного потока не привела к завершению всего процесса.
Так как память, выделенная под _RunData, освобождается только в функции потока RunThread, ошибка при создании потока приводит к потере этой памяти. Должно быть:
Как видите, структура _RunData не освобождается при возникновении ошибки создания главного окна. Должно быть:
Проблема впервые описана в http://groups.google.com/groups?q=CTheardManager&hl=ru&lr=&ie=UTF-8&oe=UTF-8&scoring=d&selm=ehrCNPukAHA.2176%40tkmsftngp03&rnum=1. Вкратце суть ее в том, что, если перед запуском главного потока приложения (CThreadManager::Run) вызвать модальный диалог, то процесс не завершается после закрытия всех окон.
Если честно, то я не понял, почему возникает проблема, но решил ее. Дело в том, что после закрытия диалогового окошка и вызова CThreadManager::Run функция ожидания сообщений и хендлов потоков:
возвращает управление сразу, dwRet при этом равен 1. Управление передается проблемному коду, описанному выше, и главный поток «зависает» на функции GetMessage().
После закрытия всех окон соответствующие дочерние потоки, созданные с помощью AddThread, завершаются, но возвращения из функции GetMessage для главного потока так и не происходит, поэтому процесс не завершается. Кроме этого, функция AddThread принимает первым параметром аргумент типа LP T STR, в проблемном коде передается LPSTR. Вот как может выглядеть решение:
CSplitterWindow и CHorSplitterWindow
Классы реализуют окна-контейнеры с разделителями. Это дочерние окна от базового, шаблонного класса CSplitterWindowT, реализованные в файле atlsplit.h. Иерархия классов представлена на рисунке 1.
Рисунок 1.
Все сообщения, посылаемые контейнеру дочерними окнами, переадресуются родительскому окну контейнера. Делается это с помощью добавления в карту сообщений макроса
который разворачивается в вызов функции Atl3ForwardNotifications. Этот макрос появляется в классе CSplitterWindowT.
Пример переключения из/в одиночный режим
Ниже приводится пример, в котором скрывается левая или верхняя область, а при повторном вызове восстанавливается нормальный режим.
Пример создания контейнера с разделителем
В примере создаются контейнер с разделителем и ListView, и затем ListView назначается правой области контейнера.
Отметим последнюю строчку: если в качестве клиентского окна для главного окна приложения не указать окно-контейнер, вас ждут крупные неприятности! Окно контейнера отрисовываться не будет, как и все его дочерние окна.
Ошибки
Особых ошибок замечено не было, за исключением описанного выше, связанного с подпиской на сообщение WM_SETTINGCHANGE.
CPaneContainer
Класс предназначен для создания контейнеров, имеющих определенный заголовок и кнопку закрытия. Вид заголовка примерно такой же, как и у стандартной программы «Проводник» (Explorer). Класс реализован в файле atlctrlx.h. Рассмотрим наиболее важные его функции и члены.
При нажатии на кнопку закрытия окна, родительскому окну посылается сообщение WM_COMMAND с идентификатором ID_PANE_CLOSE.
Пример создания контейнера с вертикальным заголовком
Так как вертикальный заголовок не может иметь названия, второй параметр функции создания контейнера можно было опустить.
Пример создания дочернего окна
Очень часто бывает необходимо в MDI-приложении размещать статические окна, как, например, ClassView в VisualStudio 6.0. С помощью класса CSplitterWindow этого добиться очень легко. Рассмотрим по шагам необходимые действия:
1. В функции OnCreate класса CMainFrame создаем окно с разделителем.
2. Создаем окно CPaneContainer.
3. Подключаем окно контейнера к левой области окна с разделителем.
4. Создаем дочернее окно MDI (MDI Client) и подключаем его к правой области окна с разделителем.
5. Делаем окно с разделителем родителем дочерних окон MDI.
6. Делаем окно с разделителем клиентским окном главного окна MDI.
7. Теперь нужно исправить одну неточность, которую создает мастер при генерации проекта. В функции главного фрейма приложения OnFileNew:
В принципе, теперь можно запускать проект на компиляцию. Однако после запуска приложения вы увидите, что клиентские окна не активизируются. Это связано с тем, что некоторые сообщения теперь поступают не в главный фрейм приложения, а в окно с разделителем.
8. Для решения этой проблемы нужно добавить обработчик сообщения WM_MDIACTIVATE в MDI-окно:
Результат моей бурной фантазии приведен на рисунке 2. При написании этого пользовательского интерфейса использовалась библиотека Tab Controls, о которой мы поговорим позже.
Рисунок 2.
Обзор дополнительных классов
В этом разделе мы рассмотрим дополнительные классы, которых нет в стандартной библиотеке, но которые часто бывают нужны. Все классы находятся в пространстве имен AWTL или начинаются с префикса AWTL_.
CSplitter
Этот класс не имеет ничего общего с описанным выше классом CSplitterWindow. Основное его достоинство в том, что он может использоваться не как контейнер, а как дополнение к control-у «собственного изготовления». Ниже я приведу пример создания ListBox-control-а с разделителем. Сейчас рассмотрим функции класса:
Сплиттер может быть вертикальным или горизонтальным, это определяется параметром в конструкторе, а не параметром шаблона, как в WTL.
Пример использования
Ниже приводится практически полный пример subclassing-а ListBox-а со сплиттером.
ListBox выводит строки элементов и разделитель. Разделитель можно перетаскивать, при окончании изменения его позиции вызывается функция OnEndTrack. В ней запоминается позиция разделителя, который отрисовывается функции DrawItem. Использовать данный класс очень просто. В функции инициализации диалога вставьте следующий код:
, где list – это поле экземпляра класса CSplitterListBox.
ПРИМЕЧАНИЕ
ListBox должен иметь стили LBS_OWNERDRAWVARIABLE, LBS_NOTIFY и LBS_HASSTRINGS.
Если вы обратили внимание на карту сообщений класса CSplitterListBox, первый макрос переадресует сообщения в дочерний класс сплиттера. Зачем? Дело в том, что если вы в каком-либо обработчике CSplitterListBox не присвоите параметру bHandled значения FALSE, то последующий обработчик этого же сообщения не вызовется. Таким образом, если макрос переадресации сообщений сплиттеру будет стоять последним в карте сообщений, вполне возможно, он не будет правильно работать. Сам же сплиттер хоть и обрабатывает сообщения, но честно устанавливает параметр bHandled в FALSE, так что они доходят до карты сообщений класса CSplitterListBox.
ПРЕДУПРЕЖДЕНИЕ
Не забудьте включить макрос REFLECT_NOTIFICATIONS() в карту сообщений диалога. Это нужно для того, чтобы сообщение WM_DRAWITEM, посылаемое родительскому окну, то бишь диалогу, передавалось обратно в ListBox.
CDialogResize
Данный класс позволяет автоматически изменять размеры control-ов при изменении размеров диалога. Для того чтобы это стало возможным, вы должны написать специальную карту масштабирования. Более подробную информацию можно найти в [1].
Класс всем хорош, однако у него имеется одно серьезное ограничение: вы не можете изменять размер control-ов, расположенных на диалоге, «собственноручно». Если у вас, например, используется тот же сплиттер, то вам нужно изменять размеры control-ов в функции OnEndTrack, но для control-ов, участвующих в карте масштабирования, это невозможно. Ниже приводится класс, который решает эту проблему:
У него всего две функции: первая устанавливает размеры заданного control-а, а вторая возвращает их. Если вам необходимо изменить размеры control-а вручную, вы запрашиваете (с помощью GetControlRect) размеры контрола, изменяете их, добавляя или вычитая из соответствующих координат значения, и затем, с помощью функции SetControlRect, устанавливаете новые размеры и позицию control-а.
CParentContainedWindow
Этот класс является наследником класса CContainedWindow, который позволяет обрабатывать сообщения некоторого дочернего окна в родительском, вернее в карте сообщений класса родительского окна. CContainedWindow – стандартный класс библиотеки ATL. Достаточно подробную документацию по нему можно найти в MSDN.
Класс CParentContainedWindow предназначен для использования карты сообщений, отличной от карты сообщений родительского окна. С помощью этого класса можно обрабатывать сообщения control-а (по существу, задавать его поведение) в классе, чье окно не является родительским для данного control-а. Эта схема приведена на рисунке 3:
Рисунок 3
Даже если вы не хотите изменять поведение control-а, этот класс очень полезен. Использование этого класса позволяет обрабатывать все сообщения WM_COMMAND, WM_NOTIFY и другие в связанном классе, что создает впечатление, будто он является родителем control-а.
Интерфейсная часть у класса изменилась ненамного – добавилось всего две функции:
Механизм работы класса: при создании дочернего control-а указывается хендл окна реального, настоящего родителя. Оконная процедура подменяется (вызовом метода SubclassWindow) для того, чтобы перехватывать определенные сообщения, отправляемые данным control-ом. При создании control-а указывается карта сообщений (по существу, процедура ProcessWindowMessage), куда будут поступать перехваченные сообщения. Так как по карте сообщений нельзя определить, к классу какого окна она принадлежит, можно установить хендл псевдородителя с помощью функции SetUnrealParent, чтобы обработчики данной карты сообщений первым параметром получали этот хендл. Если его не установить, в качестве хендла окна в обработчиках будет значение 0.
Самая важная процедура класса – это перехватчик сообщений:
Как видите, процедура довольно большая, но не сложная. Она проверяет определенные сообщения и, если они пришли от «нашего» control-а, передает их в указанную при создании карту сообщений. Если сообщение там не обработано, вызывается функция родительского окна.
ПРИМЕЧАНИЕ
Более точно картина выглядит так: все оконные сообщения данного control-а попадают в его оконную процедуру, которая вызывает функцию ProcessWindowMessage, передающую управление в карту сообщений, указанную при создании control-а. Так как одна карта сообщений может содержать несколько секций, номер нужной секции также задается при создании control-а. Сообщения, предназначенные для родительского окна, попадают в нашу процедуру, где перенаправляются в ту же карту сообщений, только всегда в секцию с номером 0.
Для правильной работы класса нужно исправить кое-какую недоработку CContainedWindow, которая в определенных случаях может приводить к ошибке. Дело в том, что CContainedWindow регистрирует новый оконный класс, но не дерегистрирует его при уничтожении. Проблема и один из способов ее решения описаны в Q248400. Разработчики класса CContainedWindow просто забыли включить вызов функции OnFinalMessage при поступлении сообщения WM_NCDESTROY в оконную процедуру, так как это сделано для класса CWindowImplBase. Это и лишило их возможности проводить освобождение ресурсов при уничтожении окна. Классу CParentContainedWindow такая очистка необходима, поэтому пришлось несколько модифицировать код оконной процедуры WindowProc класса CContainedWindow:
Перед включением файла atlwin.h необходимо определить макрос FINAL_MESSAGE_IN_CONTAINED_WINDOW. Теперь нужно определить функцию OnFinalMessage в классе CContainedWindow:
Использование данного класса связано с одним ограничением. Дело в том, что CWindowImplRoot содержит внутреннюю переменную «const MSG* m_pCurrentMsg;», в которую перед вызовом ProcessWindowMessage помещается указатель на копию текущей структуры MSG. Это поле используется рядом функций, например DefWindowProc() без параметров. Так как нет никакой возможности установить его из нашей функции перехвата, нельзя пользоваться следующими функциями:
Пример
Возьмем класс CSplitterListBox и сделаем так, чтобы сообщения от кнопки Cancel обрабатывались в нем, а не в диалоге.
Первым делом нужно добавить в класс диалога поле AWTL::CParentContainedWindowT m_btn. Затем, в конструкторе, произвести инициализацию:
Этим мы говорим о том, что будет использоваться карта сообщений control-а list с номером 1.
Теперь нужно подправить карту сообщений класса CSplitterListBox:
Сообщение WM_COMMAND с кодом BN_CLICKED будет обрабатываться в главной карте, а все сообщения от кнопки – в альтернативной карте с номером 1.
ПРИМЕЧАНИЕ
Даже если вы не хотите обрабатывать никакие сообщения от кнопки, необходимо создать альтернативную карту сообщений, так как в противном случае сработает следующий кусок кода функции ProcessWindowMessage:
Для того чтобы заработал класс CParentContainedWindow, осталось только заменить оконную процедуру кнопки в функции инициализации диалога:
Полный пример использования класса можно найти в прилагаемом к статье исходном коде.
Обзор классов сайта CodeProject
Очень сложно создать конкурентоспособный продукт только стандартными средствами. WTL обеспечивает нас мощными инструментами создания «продвинутого» пользовательского интерфейса, но их все-таки недостаточно. В этом разделе я познакомлю вас с несколькими независимыми разработками, которые бесплатно распространяются в Internet, а именно – являются частью портала для программистов CodeProject. Как мне показалось, эти библиотеки очень слабо освещены в оригинальных статьях, поэтому я решил включить их обзор в эту статью.
Библиотека DockWins
Материал данного раздела основан на статье автора библиотеки Сергея Климова [2].
Ниже приведена сильно урезанная диаграмма классов в UML-нотации.
Рисунок 4.
Подготовка проекта
Изменение главного фрейма MDI- или SDI-проектов
Включите файл DockingFrame.h в заголовочный файл главного фрейма приложения.
Поменяйте базовый класс главного фрейма приложения на dockwins::CDockingFrameImpl для SDI-приложения или на dockwins::CMDIDockingFrameImpl для MDI-приложений. Замените все упоминания старого базового класса на новый.
Добавьте в обработчик OnCreate функцию инициализации InitializeDockingFrame(). Ее параметры рассматриваются ниже.
Включите файл ExtDockingWindow.h в заголовочный файл клиентского окна.
Поменяйте базовый класс клиентского фрейма приложения на dockwins::CTitleDockingWindowImpl. В качестве одного из параметров шаблона базового класса укажите специальный класс, производный от CDockingWindowTraits, определяющий стили и свойства прилипающего (docking) окна. Они будут рассмотрены ниже.
Вот и все – компилируйте и запускайте проект. Если вам вдруг захочется, чтобы прилипающие окна автоматически скрывались (как это сделано в VC 7.0) – просто добавьте в stdafx.h заголовочный файл DWAutoHide.h.
Наиболее часто используемые функции класса CDockingFrameImplBase
Практически все функции этого класса в качестве параметра используют структуру DFDOCKPOS. Она объявлена следующим образом:
Остальные параметры не так важны: nBar задает индекс области (начиная с нуля), к которой будет присоединено окно. Атрибут имеет значение, только если не менее двух окон присоединяются к одному краю.
Основные функции класса CTitleDockingWindowImpl
Если включена поддержка автоматического скрытия окон, функция PinUp скрывает окно за кромкой главного фрейма приложения. В качестве параметра указывается одно из значений, приведенных в предыдущей таблице.
Библиотека довольно сложна. В ней почти невозможно разобраться без помощи автора, так как комментарии практически отсутствуют, а информации в [2] чрезвычайно мало.
Библиотека Tab Controls
В данном разделе рассматривается библиотека tab-controls или, по-русски, библиотека закладок. Автором ее является Daniel Bowen, оригинальный обзор библиотеки можно найти в [3]. Ниже приведена диаграмма классов в UML-нотации. Методы и свойства опущены, так как в противном случае диаграмма не влезла бы ни в какие рамки.
Рисунок 5.
Библиотека реализует различные tab-control-ы (производные от CСustomTabCtrl), а также несколько классов для использования этих control-ов в SDI- и MDI-приложениях.
Список функций класса CCustomTabCtrl:
Ниже приведен список наиболее часто используемых функций закладок (CCustomTabOwnerImpl):
Класс CTabbedFrameImpl является базовым для CTabbedChildWindow и CTabbedPopupFrame, которые предназначены для дочерних или всплывающих (popup) окон. Список функций класса CTabbedFrameImpl:
Класс CTabbedMDIFrameWindowImpl переопределяет функциональность базового стандартного класса CMDIFrameWindowImpl для поддержки просмотра дочерних окон как закладок в MDI-приложении. Наиболее часто используемые функции класса:
Функции класса CTabbedMDIClient, который предназначен для переопределения окна стандартного класса MDIClient. Наиболее часто используемые функции класса:
Примеры
Начнем с простого примера – создадим MDI-приложение, для дочерних окон которого организуются специальные закладки.
1. Создайте простое MDI-приложение.
2. Добавьте в stdafx.h следующие файлы.
Для того чтобы компилятор нашел последние два файла, зайдите в Tools->Options->Directories и добавьте новую директорию в категорию Include files.
3. Главный фрейм приложения нужно унаследовать не от стандартного CMDIFrameWindowImpl, а от CTabbedMDIFrameWindowImpl.
4. Вместо стандартного CMDICommandBarCtrl нужно использовать CTabbedMDICommandBarCtrl:
5. Дочерний фрейм приложения нужно унаследовать от CTabbedMDIChildWindowImpl:
Вот и все, компилируйте и запускайте приложение. Оно должно выглядеть примерно так:
Рисунок 6.
Для SDI-приложения необходимо выполнить следующие шаги:
1. Добавьте в stdafx.h следующие файлы:
2. Добавьте новое поле в класс CMainFrame – оно будет клиентским окном.
3. Функцию OnCreate класса CMainFrame измените так:
Это все. Теперь можете компилировать и запускать приложение. Для добавления других представлений (view) создайте соответствующий класс, затем в функции OnCreate создайте окно данного представления и добавьте его к окну закладок с помощью функции DisplayTab.
Рассмотрим наиболее часто используемые стили закладок:
Константа
Значение
CTCS_BOTTOM
0x0002
Закладки располагаются внизу.
CTCS_CLOSEBUTTON
0x0008
Появляется кнопка закрытия. При ее нажатии приходит сообщение WM_NOTIFY с кодом CTCN_CLOSE. Надо заметить, что класс CTabbedMDIFrameWindowImpl устанавливает этот стиль и обрабатывает соответствующее извещение автоматически.
CTCS_BOLDSELECTEDTAB
0x2000
Название активной закладки выделяется жирным шрифтом.
CTCS_TOOLTIPS
0x4000
Для закладки выводится всплывающая подсказка.
У любой закладки должно быть имя. Имя обычно берется из названия клиентского окна, добавляемого с помощью функции DisplayTab. DisplayTab также пытается получить иконку окна с помощью сообщения WM_GETICON и функции GetClassLong(GCL_HICONSM). Если это не удается, закладка выводится без иконки. Если окно не имеет текста и иконки, можно воспользоваться функцией AddTabWithIcon. Она позволяет указать для добавляемого окна как текст закладки, так и ее иконку.
Функция SetReflectNotifications управляет тем, будут ли в карте сообщений Tab-а отражаться уведомления от дочерних control-ов. В случае control-а CustomDraw нужно вызвать эту функцию, передав в качестве параметра значение true, в противном случае вы не сможете обрабатывать соответствующие уведомления о прорисовке и проч.
Параметр шаблона CTabbedChildWindow задает тип закладки или ее вид. Более подробную информацию об этом можно получить в [3].
Совместное использование библиотеки TabControls и DockWins
Чтобы создать пользовательский интерфейс, подобный VS 7.0, нужно проделать следующие шаги:
1. Создайте с помощью мастера MDI-проект.
2. Включите в проект (в файл stdafx.h) следующие файлы:
3. В заголовочный файл главного фрейма приложения (mainfrm.h) включите файл DockingFrame.h.
4. Замените базовый класс главного фрейма CMDIFrameWindowImpl на dockwins::CMDIDockingFrameImpl.
5. Создайте поле в классе главного фрейма приложения типа CTabbedMDIClient >.
6. Замените тип поля m_CmdBar с CMDICommandBarCtrl на CTabbedMDICommandBarCtrl. После это класс главного фрейма приложения должен выглядеть примерно так:
7. В обработчик OnCreate главного фрейма приложения вставьте следующий код:
8. Исправьте ошибку, вносимую мастером создания проекта – обработчик OnFileNew главного фрейма приложения:
9. После этого остается только исправить в дочернем фрейме приложения (CChildFrame) базовый класс с CMDIChildWindowImpl на CTabbedMDIChildWindowImpl
Это все! Компилируйте и запускайте проект. У вас должно получиться что-то вроде этого
Рисунок 7.
ПРИМЕЧАНИЕ
Если при компиляции проекта у вас возникает ошибка «fatal error C1076: compiler limit : internal heap limit reached;», не пугайтесь. Для компиляции такого огромного количества шаблонов у компилятора просто не хватает памяти. Увеличить объем кучи можно опцией Zm. В Project Options добавьте ключ /Zm200, что расширит объем кучи до двухсот мегабайт.
Еще одно изменение касается простых, не MDI-окон (таких, как окно Output на рисунке). Чтобы они работали в новом проекте, необходимо заменить базовый класс dockwins::CTitleDockingWindowImpl на dockwins::CBoxedDockingWindowImpl, а так же стиль dockwins::COutlookLikeTitleDockingWindowTraits на dockwins::COutlookLikeBoxedDockingWindowTraits. После изменений класс окна должен выглядеть примерно так:
Более продвинутые возможности этих библиотек можно изучить по исходным кодам из [2] и [3], или заходя на наши форумы. 🙂
CSSFileDialog
С выходом Windows 2000 появился новый стандартный диалог открытия/сохранения файлов. Он отличается от обычного диалога наличием тулбара в левой части, позволяющего быстро переключаться на специальные папки (Рабочий стол, Мои документы и проч.).
Все вы прекрасно знакомы со структурой OPENFILENAME, которая используется для создания диалогов открытия/сохранения в старом стиле. Если открыть файл CommDlg.h, можно увидеть такое определение этой структуры (если в вашем файле ее нет, скачайте новый Platform SDK).
Как видите, для использования новых возможностей необходимо объявить макрос _WIN32_WINNT со значением, равным или большим 0x0500 (версия Win2k). Также необходимо правильно заполнить поле lStructSize и указать нужные расширенные флаги (FlagsEx). В данный момент определено только одно значение (файл commdlg.h)
Таким образом, при указании нулевого значения стандартный диалог представляется в расширенном виде, с тулбаром слева. При указании единицы, диалог появляется в старом стиле.
Более подробную информацию об этом, а также пример реализации на MFC стандартного диалога расширенного стиля можно найти в колонке С++ Q&A августовского номера журнала MSDN Magazine за 2000 год.
Заключение
Напоследок хочется сказать, что WTL создавалась и поддерживается небольшой группой энтузиастов, официально не поддерживается Microsoft, и вряд ли уже когда-нибудь это изменится. Это объясняет текущие недостатки библиотеки, связанные с проектированием и многочисленными ошибками. Но, несмотря на эти недостатки, я считаю, библиотека имеет будущее, так как является очень гибкой, расширяемой и открытой.
