Microsoft windows common controls что это

Microsoft Windows Common Controls (общие элементы управления для Microsoft Windows) — это набор графических компонентов, предоставляемых операционной системой Windows, которые можно использовать для создания интуитивно понятных и удобных в использовании пользовательских интерфейсов.

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

Использование Common Controls позволяет сократить время и усилия, затрачиваемые на разработку пользовательского интерфейса, так как большинство элементов уже разработано и настроено Microsoft. Разработчикам остается только использовать их в своих приложениях.

Одной из особенностей Common Controls является их гибкость и адаптивность к различным версиям операционной системы Windows. Учитывая то, что Microsoft активно разрабатывает и поддерживает эти элементы управления, разработчики могут быть уверены в их корректной работе на разных версиях Windows.

Описание Microsoft Windows Common Controls

Common Controls включает в себя множество компонентов, таких как кнопки, поля ввода, списки, деревья и т. д. Они предоставляются в виде динамически загружаемых библиотек, которые можно использовать в своих приложениях.

Использование Microsoft Windows Common Controls упрощает процесс создания пользовательского интерфейса и улучшает его внешний вид. С помощью этого набора разработчикам не нужно создавать элементы интерфейса с нуля, они могут использовать готовые компоненты, которые уже оптимизированы для работы с операционной системой Windows.

Особенностью Microsoft Windows Common Controls является их приспособленность для различных версий операционной системы Windows. Это означает, что код, написанный с использованием Common Controls, будет работать на более старых и новых версиях Windows без необходимости дополнительного изменения или обновления.

Это лишь небольшой набор элементов, доступных в Microsoft Windows Common Controls. Всего их существует значительное количество, и каждый из них имеет свои уникальные возможности и характеристики.

Общее представление о Microsoft Windows Common Controls

Среди основных элементов управления из набора Microsoft Windows Common Controls можно выделить:

• Кнопки (Button) — элементы, предназначенные для вызова определенных действий или функций приложения.
• Текстовые поля (Edit) — области, в которые пользователь может вводить и редактировать текст.
• Списки (List) — компоненты, позволяющие отображать и выбирать элементы из списка.
• Деревья (Tree) — элементы, предназначенные для организации информации и навигации в виде иерархической структуры.
• Вкладки (Tab) — компоненты, используемые для разделения интерфейса приложения на несколько вкладок, каждая из которых содержит свой набор элементов управления.
• Строки состояния (Status Bar) — области, в которых отображается текущее состояние приложения или дополнительная информация.
• Флажки (Check Box) и переключатели (Radio Button) — элементы, позволяющие пользователю выбрать один или несколько вариантов из предложенных.

Microsoft Windows Common Controls предназначены также для привлекательного и интуитивно понятного представления информации, облегчая взаимодействие пользователя с приложением. Они являются неотъемлемой частью разработки программного обеспечения под Windows и позволяют создавать легкую в использовании и привлекательную графическую оболочку для приложений.

Использование Microsoft Windows Common Controls

Для использования Microsoft Windows Common Controls необходимо выполнить следующие шаги:

1. Добавить в проект ссылку на соответствующую библиотеку Common Controls.
2. Добавить элемент управления на форму приложения с помощью инструментов разработки.
3. Настроить свойства элемента управления в соответствии с требованиями приложения.
4. Написать код для обработки событий элемента управления и реализации требуемой логики.

Элементы управления Microsoft Windows Common Controls предлагают широкий спектр возможностей, таких как ввод текста, выбор элементов из списка, отображение даты и времени, маскирование ввода и многое другое. Каждый элемент управления имеет свои уникальные свойства и события, которые можно настроить и обрабатывать в коде приложения.

Использование Microsoft Windows Common Controls позволяет создавать приложения с современным и интуитивно понятным интерфейсом. Они обеспечивают единообразный стиль элементов управления, что повышает удобство использования приложения для пользователей операционной системы Windows.

Особенности Microsoft Windows Common Controls

Особенности Microsoft Windows Common Controls включают:

• Широкий набор элементов управления: обычные кнопки, флажки, переключатели, списки, деревья, полосы прокрутки и т. д.
• Гибкость настройки: разработчики могут настраивать внешний вид и поведение элементов управления в зависимости от своих потребностей.
• Поддержка различных стилей и тем: элементы управления могут быть отображены в различных стилях, соответствующих теме операционной системы или настройкам пользователя.
• Автоматическая поддержка доступности: элементы управления могут быть использованы людьми с ограниченными возможностями или использующими альтернативные устройства ввода и вывода.
• Возможности расширения: разработчики могут создавать собственные элементы управления, основываясь на Microsoft Windows Common Controls, чтобы расширить функциональность своих приложений.

Microsoft Windows Common Controls являются важным инструментом для разработчиков Windows-приложений, позволяющим создавать современные, удобные и интуитивно понятные пользовательские интерфейсы.

Время на прочтение
6 мин

Количество просмотров 59K

Недавно на руборде в разделе Программирование был задан вопрос: «Зачем Win32-приложению манифест? На что он влияет?». Первое, что сразу приходит в голову большинству программистов — это темы оформления. Но на самом деле в современных виндах манифест нужен не только для этого. Я подумал и написал пять ключевых аспектов, на которые влияет манифест или его отсутствие. После этого сразу несколько человек попросили оформить этот пост в виде более развернутой статьи.

Для начала предлагаю вспомнить, как вообще в Windows появились манифесты, и как они развивались.

История манифеста

В древние времена в мире Win95/98 царил ад, точнее DLL hell. Возник он из-за того, что Windows задумывалась как идеальная система. Все приложения в ней всегда должны были писаться с использованием самых свежих версий системных библиотек. А различные версии самих библиотек должны были быть взаимозаменяемыми. Реальность быстро доказала всем, что для популярной операционки это несбыточная мечта, так и возник ад. Каждое второе приложение во время инсталляции перезаписывало системные библиотеки нужными ему версиями. В результате после установки приложения X установленное ранее приложение Y начинало глючить. А после переустановки приложения Y глючить начинало приложение X. В общем юзерам жилось весело.

Для решения этой проблемы в Windows XP появилась технология Side-by-side Assembly (SxS). Суть ее заключалась в том, что приложение могло явно указать, с какой версией библиотеки оно желает работать. Эта информация могла указываться либо в специальном файле .manifest, либо в ресурсах приложения в разделе Manifest. В самой ХР на основе новой технологии реализовали одну из самых заметных новых фишек системы — темы оформления.

Типичный манифест:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    version="1.0.0.0"
    processorArchitecture="*"
    name="CompanyName.ProductName.YourApplication"
    type="win32"
/>
<description>Your application description here.</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

Всем был хорош SxS кроме одного — он был ужасно неудобен для программиста. В 99% случаев манифест применялся только для включения тех самых тем оформления, и ни для чего больше. Разработчикам винды стало ясно, что нужен новый, более простой в использовании способ указать поддерживаемые версии системных библиотек. Тогда они придумали простое правило: в пределах одной версии системы интерфейс и поведение этих библиотек не изменяется. Нужно было только каким то образом научится определять какая их версия требуется конкретному приложению. Так в Windows 7 в манифесте появилась секция Compatibility, где можно указать с какими версиями ОС тестировалось приложение.
Также в манифесте начиная с Windows Vista появилось еще несколько секций, обо всех о них ниже.

Функции манифеста

1. Активация тем оформления (Visual Styles)
   Эта технология появилась в ХР и полностью основана на SxS. Работает просто: вы запрашиваете у системы ComCtl32.dll шестой версии, и — вуаля — все стандартные контролы рисуются согласно с активированной в системе темой. Если же вы не упомянете в манифесте ComCtl32.dll, или манифест вообще будет отсутствовать в приложении, то система по умолчанию загрузит ComCtl32.dll пятой версии, которая отрисовывает контролы в стиле Win95. Кроме поддержки тем оформления, шестая версия ComCtl32.dll содержит кое-какой функционал, которого нету в пятой версии. Поэтому если отключить темы оформления, некоторые приложения будут работать и выглядеть не так, как задумывали их авторы.

   Справа тоже самое приложение без манифеста:

   

2. Взаимодействие с UAC имеет несколько аспектов:
   • Ключ requestedExecutionLevel.level позволяет указать требуемый приложению уровень прав пользователя. К примеру если указать requireAdministrator, то приложению будут предоставлены права администратора (если пользователь разрешит).

     Запрос разрешения пользователя:

     

   • Если вся секция по взаимодействию с UAC отсутствует в манифесте, к приложению будет применена виртуализация файловой системы и реестра. Если такое приложение попытается записать что то в защищенные папки типа «Program files», оно будет перенаправлено в папку “%userprofile%\AppData\Local\VirtualStore\Program files». Аналогично, попытки записи в раздел реестра HKEY_LOCAL_MACHINE будут перенаправлены в «HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE». Естественно, сделанные таким образом изменения будут видны только приложениям, запущенным в режиме виртуализации.

     Виртуализация файловой системы в деле:

     

   • Ключ requestedExecutionLevel.uiAccess позволяет приложениям, запущенным без прав администратора, взаимодействовать с окнами приложений, запущенных с правами администратора. Это может потребоваться экранным клавиатурам, приложениям типа AutoIt, экранным читалкам, тестовым и отладочным тулзам. Чтобы этот ключ сработал, приложение должно быть подписано сертификатом Microsoft Authenticode.

3. Управление DPI-масштабированием
   С древнейших времен винда имеет механизм масштабирования интерфейса в зависимости от DPI монитора (тут говорится, что все началось в XP, но мне кажется, что раньше). В те времена эта настройка выставлялась только вручную, наверное из-за отсутствия EDID. Популярностью она не пользовалась, возможно потому, что запрятана была далеко, а возможно потому, что мониторов с большим разрешением было очень-очень мало. Кроме того, большая часть работы, необходимой для поддержки масштабирования, была отдана на откуп самим приложениям и их авторам. А программисты, как известно, люди весьма ленивые, поэтому куча софта для винды писалась в предположении, что DPI всегда равен стандартному значению 96. Очень часто встречалась ситуация, когда в приложении использовались библиотеки поддерживающие нестандартный DPI, в то время как код самого приложения его не поддерживал. Это приводило к появлению ужасных артефактов в интерфейсе приложения, стоило пользователю выставить DPI, к примеру, в значение 120 (масштабирование 125%):

   

   Разработчики Висты не стерпели подобного безобразия, и заложили в DWM возможность производить масштабирование самостоятельно, а приложениям врать, что DPI по прежнему равен 96. Причем зависящие от него системные настройки, разрешение монитора и даже положение мыши, также пересчитываются. К сожалению разработчики Висты небыли волшебниками, поэтому масштабирование DWM производит с помощью простых алгоритмов растягивания изображений. И если интерфейс приложения нужно увеличить, то происходит замыливание картинки. Представьте что было бы, если бы разработчики Фотошопа не могли это отключить. Таких бунтов на корабле никто не хотел, поэтому появилась возможность указать в манифесте, что ваше приложение таки умеет нормально масштабировать свой интерфейс, и помощь DWM ему не нужна. За это отвечает параметр dpiAware. Тут правда следует отметить, что по умолчанию масштабирование силами DWM включается при увеличении 150% и выше. Видимо в Microsoft посчитали, что при масштабировании 125% артефакты как на скриншоте выше вполне терпимы.

   Слева масштабирование силами DWM, а справа — самого приложения:

   

   В Windows 8.1 появилась возможность указывать разный масштаб разным мониторам, если подключено сразу несколько. Соответственно у ключа dpiAware появилось новое значение «True/PM». Оно означает, что приложение умеет динамически изменять масштаб своего интерфейса при переносе окон с одного монитора на другой.

4. Декларирование совместимости
   Работает очень просто: программист тестирует свое приложение в определенной версии винды, и если все работает как надо, добавляет GUID этой версии в манифест.

   Пример:

   <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> 
         <application> 
           <!--This Id value indicates the application supports Windows Vista functionality -->
             <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> 
           <!--This Id value indicates the application supports Windows 7 functionality-->
             <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
           <!--This Id value indicates the application supports Windows 8 functionality-->
             <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
           <!--This Id value indicates the application supports Windows 8.1 functionality-->
             <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
         </application> 
     </compatibility>
   

   Наиболее интересен вопрос: «На что влияют эти GUID-ы?» Пока что список различий в поведении системных библиотек невелик. Наиболее интересно упоминание об оптимизации RPC. Получается что приложения, задекларировавшие совместимость с семеркой, будут работать быстрее.
   В будущем этот раздел манифеста наверняка будет играть большую роль чем сейчас. Ведь в винде полно разных хаков призванных обеспечивать совместимость. И теперь есть возможность оградить от них нормальные приложения.

   Если GUID-ы полностью отсутствуют в манифесте, то к приложению применяются правила как к совместимому с Вистой:

   

5. Управление прочими функциями
   Выше я описал только те функции, с которыми приходилось иметь дело лично. Но это далеко не все, чем можно управлять из манифеста: msdn.microsoft.com/en-us/library/aa374191.aspx К сожалению, документация по большей части остальных функций недоступна. Возможно ее опубликуют позже, как в свое время произошло с Magnification API.

Эпилог

На этом я, пожалуй, завершу рассмотрение возможностей манифестов Win32-приложений. Если у вас есть какие-либо исправления или дополнения, пожалуйста, изложите их в комментариях.

BEGIN_MESSAGE_MAP(CListView, CView)
    ON_NOTIFY( NM_DBLCLK,ID_LISTCTRL,OnDblClick )
END_MESSAGE_MAP()

void CListView::OnDblClick(NMHDR* /*k*/, LRESULT* /*j*/)
{
    int nItem, nFlags;
    char szTest[80];
    nFlags = LVNI_SELECTED;
    nItem = m_ListCtrl->GetNextItem(-1, nFlags );
    if ( nItem != -1 )
    {
        sprintf( szTest, "Selected Item %d", nItem);
        AfxMessageBox(szTest);
    }
}

[email protected], mfc-l, 7/21/95

6.4.4. Does CTreeCtrl support multiple selection?

No. Sorry! (I see this one all the time!)

[email protected]

If it’s accessible to you, Microsoft Systems Journal, July 1994, has an extensive look
at TreeViews, including a sample program that includes drag & drop. If you’re
developing for Windows 95, you don’t need a shareware implementation, MFC has a class for
it.

[email protected]

6.4.5. When I expand a node in my CTreeCtrl, there’s no visual
feedback, what to do?

Create the control with TVS_SHOWSELALWAYS style.

[email protected]

6.4.6. (The FAQ of the devil!) How do I implement multiple
selection, tooltips, editable nodes and multiple columns in my tree control?

Unfortunately, since the tree control lives in a binary DLL, it is not very extensible
and you are stuck without these features. There have been articles on how to try and
«hack» these features, but they do not work reliably.

We have a drop-in tree control replacement that implements all of these features and
more in Objective Toolkit. Demos are at http://www.stingray.com.

NEW!! 6.4.7.  How
do I tell a CListCtrl object to select the whole line and not just the left column, 
when you click on an item?

NEW!!  6.4.8. 
How do you turn off the sliding animation that happens when a TreeCtrl is expanded or
collapsed?

I have used LockWindowUpdate() and UnlockWindowUpdate() in the past
to achieve what you are asking using a CListCtrl. The functions are in CWnd and since
CTreeCtrl is derived from CWnd this should work the same.

Ted Dasler [ [email protected]
], mfc-l, 6/19/98

NEW!! 6.4.9. 
When implementing drag/drop operations, how do you get the different cursors: copy,
shortcut, circle with the slash, etc. ?

I believe you want to override the OnDragEnter() and OnDragOver()
methods. Returning DROPEFFECT_NONE will give you the circle with a slash. DROPEFFECT_LINK
will give you the arrow. DROPEFFECT_COPY will give you the plus sign. 

Cary Walker [[email protected]],
VCPP mailing list, 6/29/98

Microsoft Windows Common Controls

Microsoft Windows Common Controls provide features like ListView, TreeView, and ImageList, which are partly necessary for the interface of OL [LookForDuplicates]. The filename of the corresponding control is mscomctl.ocx and it resides in the system32 folder.

You can download mscomctl.ocx directly from Microsoft.

After decompressing into C:\WINDOWS\system32\ you need to register the control by running
regsvr32 C:\WINDOWS\system32\MSCOMCTL.OCX
in the Windows Run dialog ([Win]+R). In order to be available for OL [LookForDuplicates], the library has to be loaded in Outlook according to the Installation guide.

Additionally, you can have a look at the Microsoft Download Center for an updated version of the control.

It should be noted that Microsoft Windows Common Controls are only available for 32-bit editions of Microsoft Office Outlook.