Введение в Win32 API. Разбираемся в WinAPI Типы данных Windows
Хочу сразу предупредить:
Я не претендую на звание гуру по C++ или WinAPI.
Я только учусь и хочу привести здесь несколько примеров и советов которые облегчают мне изучение функций и механизмов WinAPI.
В данной статье я предполагаю что вы уже достаточно ознакомились с С++, что бы уметь создавать классы и перегружать для них различные операторы и что вы уже «прятали» какие-то свои механизмы в класс.
Создание и использование консоли
Для отладки Win32 приложения или просто для того что посмотреть как оно там всё внутри происходит я всегда пользуюсь консолью.Так как вы создаете GUI приложение, а не консольное, то консоль не подключается. Для того что бы её вызвать в недрах интернета был найден вот этот код
If (AllocConsole())
{
std::ios::sync_with_stdio();
}
Для удобства советую обернуть его в функцию. Например:
void CreateConsole()
{
if (AllocConsole())
{
int hCrt = _open_osfhandle((long)GetStdHandle(STD_OUTPUT_HANDLE), 4);
*stdout = *(::_fdopen(hCrt, "w"));
::setvbuf(stdout, NULL, _IONBF, 0);
*stderr = *(::_fdopen(hCrt, "w"));
::setvbuf(stderr, NULL, _IONBF, 0);
std::ios::sync_with_stdio();
}
Вызванная консоль работает только в режиме вывода и работает он также как и в консольных приложениях. Выводите информацию как и обычно - cout/wcout.
Для работоспособности данного кода необходимо включить в прект следующие файлы:
#include
#include #include
и включить пространство имен std в глобальное пространство имён:
using namespace std;
Конечно же, если вы не хотите этого делать, то просто допишите std:: ко всем сущностям которые в ней находятся.
Наследование объектов для вывода и арифм. операций
При создании и изучении самих «окошек» мне всегда требовалось выводить в консоль какое-нибудь значение.Например:
Вы получаете размер клиентской области окна с помощью функции GetClientRect куда как параметр передается адрес объекта структуры RECT, что бы заполнить этот объект данными. Если вам нужно узнать размер полученной клиентский области вы просто можете вывести его в уже подключённую консоль
Cout< Но делать так каждый раз (особенно если вам часто приходиться делать что-то подобное) очень неудобно. Class newrect:public RECT Теперь просто выводите обьект с помощью cout/wcout: Cout< И вам в удобном виде будет выводиться всё так, как вам требуется. Один раз хорошенько продумав и написав такой класс вы облегчите себе жизнь и будете больше времени уделять обучению и оттачиванию навыков чем написанию одного и того же каждый раз. Тем более, я считаю это очень полезно - самому сделать такой класс и дополнять его по необходимости. Windows API - набор функций операционной системы
Аббревиатура API многим начинающим
программистам кажется весьма таинственной и
даже пугающей. На самом же деле Application Programming Interface
(API) - это просто некоторый готовый набор
функций, который могут использовать
разработчики приложений. В общем случае данное
понятие эквивалентно тому, что раньше чаще
называли библиотекой подпрограмм. Однако обычно
под API подразумевается особая категория таких
библиотек. В ходе разработки практически любого
достаточно сложного приложения (MyAppication) для
конечного пользователя формируется набор
специфических внутренних функций, используемых
для реализации данной конкретной программы,
который называется MyApplication API. Однако часто
оказывается, что эти функции могут эффективно
использоваться и для создания других приложений,
в том числе другими программистами. В этом случае
авторы, исходя из стратегии продвижения своего
продукта, должны решить вопрос: открывают они
доступ к этому набору для внешних пользователей
или нет? При утвердительном ответе в описании
программного пакета в качестве положительной
характеристики появляется фраза: «Комплект
включает открытый набор API-функций» (но иногда за
дополнительные деньги). Таким образом, чаще всего под API
подразумевается набор функций, являющихся
частью одного приложения, но при этом доступных
для использования в других программах. Например,
Excel, кроме интерфейса для конечного пользователя,
имеет набор функций Excel API, который может
использоваться, в частности, при создании
приложений с помощью VB. Соответственно Windows API - это набор
функций, являющийся частью самой операционной
системы и в то же время - доступный для любого
другого приложения, в том числе написанного с
помощью VB. В этом плане вполне оправданна
аналогия с набором системных прерываний BIOS/DOS,
который фактически представляет собой DOS API. Отличие заключается в том, что состав функций Windows API, с одной стороны,
значительно шире по сравнению с DOS, с другой - не включает многие средства
прямого управления ресурсами компьютера, которые были доступны программистам
в предыдущей ОС. Кроме того, обращение к Windows API выполняется с помощью обыкновенных
процедурных обращений, а вызов функций DOS - через специальную машинную
команду процессора, которая называется Interrupt («прерывание»). Несмотря на то что VB обладает огромным
множеством разнообразных функций, в процессе
более-менее серьезной разработки
обнаруживается, что их возможностей зачастую не
достаточно для решения необходимых задач. При
этом программисты-новички часто начинают
жаловаться на недостатки VB и подумывать о смене
инструмента, не подозревая, что на их компьютере
имеется огромный набор средств и нужно только
уметь ими воспользоваться. При знакомстве с Win API обнаруживается,
что многие встроенные VB-функции - не что иное,
как обращение к соответствующим системным
процедурам, но только реализованное в виде
синтаксиса данного языка. С учетом этого
необходимость использования API определяется
следующим вариантами: Следует также подчеркнуть, что
некоторые API-функции (их доля в Win API весьма
незначительна) не могут вызываться из VB-программ
из-за ряда ограничений языка, например из-за
отсутствия возможности работы с адресами памяти.
Но в ряде случаев могут помочь нетривиальные
приемы программирования (в частности, в случае с
теми же адресами). Личная точка зрения автора такова - вместо расширения от версии к версии
встроенных функций VВ следовало бы давать хорошее описание наиболее ходовых
API-функций. В то же время хочется посоветовать разработчикам не ждать появления
новой версии средства с расширенными функциями, а внимательнее изучить состав
существующего Win API - вполне вероятно, что нужные вам возможности можно
было реализовать уже в версии VB 1.0 выпуска 1991 года. Это не такой простой вопрос, если
учесть, что число функций Win32 API оценивается
величиной порядка 10 тысяч (точной цифры не знает
никто, даже Microsoft). В состав VB (версий 4-6) входит файл с
описанием объявлений Win API - WIN32API.TXT (подробнее
о его применении мы расскажем позднее). Но,
во-первых, с его помощью можно получить сведения
о назначении той или иной функции и ее параметрах
только по используемым мнемоническим именам, а
во-вторых - перечень функций в этом файле
далеко не полный. В свое время (семь лет назад) в VB
3.0 имелись специальные справочные файлы с
описанием функций Win16 API. Однако уже в v.4.0 эта
полезная информация с удобным интерфейсом
исчезла. Исчерпывающую информацию о Win32 API можно
найти в справочной системе Platform Software Development Kit,
которая, в частности, находится на компакт-дисках
MSDN Library, включенных в состав VB 5.0 и 6.0 Enterprise Edition и
Office 2000 Developer Edition. Однако разыскать там нужную
информацию и разобраться в ней совсем не просто.
Не говоря уж о том, что все описания там
приводятся применительно к языку C. Общепризнанным в мире пособием для
изучения API-программирования в среде VB являются
книги известного американского эксперта Даниэля
Эпплмана (Daniel Appleman). Его серия Dan Appleman’s Visual Basic
Programmer’s Guide to the Windows API (для Win16, Win32, применительно
к разным версиям VB) с 1993 года неизменно входит в
число бестселлеров для VB-программистов. Книгу Dan
Appleman’s VB 5.0 Programmer’s Guide to the Win32 API, выпущенную в 1997
году, автору привез из США приятель, который
нашел ее в первом же книжном магазине небольшого
провинциального городка. Эта книга объемом свыше 1500 страниц
включает описание общей методики
API-программирования в среде VB, а также более 900
функций. Прилагаемый компакт-диск содержит
полный текст книги и всех программных примеров, а
кроме того, несколько дополнительных глав, не
вошедших в печатный вариант. В 1999 году Дэн
Эпплман выпустил новую книгу Dan Appleman’s Win32 API Puzzle
Book and Tutorial for Visual Basic Programmers, которая включает
сведения о еще 7600 функциях (хотя и не столь
обстоятельные). Набор Win API реализован в виде
динамических DLL-библиотек. Далее речь фактически
пойдет о технологии использования DLL в среде VB на
примере библиотек, входящих в состав Win API. Однако,
говоря о DLL, необходимо сделать несколько важных
замечаний. В данном случае под DLL мы подразумеваем
традиционный вариант двоичных динамических
библиотек, которые обеспечивают прямое
обращение приложений к нужным процедурам -
подпрограммам или функциям (примерно так же, как
это происходит при вызове процедур внутри
VB-проекта). Такие библиотеки могут создаваться с
помощью разных инструментов: VC++, Delphi, Fortran, кроме VB
(посмотрим, что появится в версии 7.0) -
последний может делать только ActiveX DLL, доступ к
которым выполняется через интерфейс OLE Automation. Обычно файлы динамических библиотек
имеют расширение.DLL, но это совсем не обязательно
(для Win16 часто применялось расширение.EXE);
драйверы внешних устройств обозначаются с
помощью.DRV. Как мы уже отмечали, определить точное
число API-функций Windows и содержащих их файлов
достаточно сложно, однако все они находятся в
системном каталоге. В этом плане лучше выделить
состав библиотек, входящих в ядро операционной
системы, и основных библиотек с ключевыми
дополнительными функциями. А теперь несколько советов. Само обращение к DLL-процедурам в программе выглядит точно так же, как к «обычным»
процедурам Visual Basic, например: Call DllName ([список аргументов])
Однако для использования внешних DLL-функций (в том числе и Win API) их нужно
обязательно объявить в программе с помощью оператора Declare, который имеет
следующий вид: Declare Sub ИмяПроцедуры Lib _
“ИмяБиблиотеки” _
[([СписокАргументов])]
Declare Function ИмяФункции _
Lib “ИмяБиблиотеки” _
[([СписокАргументов])]
Здесь в квадратных скобках приведены
необязательные элементы оператора, курсивом
выделены переменные выражения, остальные
слова - ключевые. В справочной системе
приведено достаточно хорошее описание
синтаксиса оператора, поэтому сейчас мы только
отметим некоторые моменты. Объявления внешних функций должны
размещаться в секции General Declarations модуля. Если вы
размещаете его в модуле формы, то обязательно
нужно указать ключевое слово Private (это объявление
будет доступно только внутри данного
модуля) - таково ограничение для всех
процедур модуля формы. Набор Win32 API реализован только в виде
функций (в Win16 API было много подпрограмм Sub). В
большинстве своем - это функции типа Long,
которые чаще всего возвращают код завершения
операции. Оператор Declare появился в MS Basic еще во
времена DOS, причем он использовался и для
объявления внутренних процедур проекта. В Visual Basic
этого не требуется, так как объявлением
внутренних процедур автоматически является их
описание Sub или Function. По сравнению с Basic/DOS в новом
описании обязательно указывать имя
файла-библиотеки, где находится искомая
процедура. Библиотеки Wip API размещаются в
системном каталоге Windows, поэтому достаточно
привести только название файла. Если же вы
обращаетесь к DLL, которая находится в
произвольном месте, нужно записать полный путь к
данному файлу. Описание оператора Declare обычно занимает довольно много места и не помещается
в одну строку в окне кода. Поэтому мы рекомендуем придерживаться при написании
приложений какой-либо определенной схемы переноса строк, например: Declare Function GetTempPath _
Lib “kernel32” Alias “GetTempPathA” _
(ByVal nBufferLength As Long, _
ByVal lpBuffer As String) As Long
В этом случае все основные элементы описания разнесены на разные строчки и
поэтому хорошо читаются. Использование Win API и разнообразных
DLL-функций существенно расширяет функциональные
возможности VB и зачастую позволяет повысить
производительность программ. Однако расплата за
это - риск снижения надежности работы
приложения, особенно в процессе его отладки. Одним из самых важных достоинств среды
VB является надежность процесса разработки
программ: функционируя под управлением
интерпретатора, программный код теоретически не
может нарушить работу Windows и самого VB.
Программист может не очень внимательно следить
за правильностью передачи параметров в
вызываемые функции - подобные ошибки будут
легко обнаружены самим интерпретатором либо в
процессе трансляции кода, либо во время его
выполнения. В самом неприятном случае просто
произойдет прерывание режима обработки, причем с
указанием, где и почему произошла ошибка. Использование напрямую функций Windows API
или других DLL-библиотек снимает такой контроль за
передачей данных и процессом выполнения кода вне
среды VB. Поэтому ошибка в обращении к внешним
функциям может привести к неработоспособности и
VB и операционной системы. Это особенно актуально
на этапе разработки программы, когда наличие
ошибок - дело вполне естественное. Таким
образом, применяя более широкие возможности
функций базового слоя системы, программист берет
на себя ответственность за правильность их
применения. Проблема усугубляется еще и тем, что
разные языки программирования используют
различные способы передачи параметров между
процедурами. (Точнее, разные способы передачи
используются по умолчанию, так как многие языки
могут поддерживать несколько способов.) Win API
реализованы на C/C++ и применяют соглашения о
передаче параметров, принятые в этой системе,
которые отличаются от привычного для VB варианта. В связи с этим следует отметить, что появление встроенных в VB аналогов API-функций
оправданно именно адаптацией последних к синтаксису VB и реализацией соответствующего
механизма контроля обмена данными. Обратим также внимание, что на этапе опытной
отладки приложения при создании исполняемого модуля лучше использовать вариант
компиляции P-code вместо Native Code (машинный код). В первом случае программа
будет работать под управлением интерпретатора - медленнее по сравнению
с машинным кодом, но более надежно с точки зрения возможного ошибочного воздействия
на операционную систему и обеспечивая более удобный режим выявления возможных
ошибок. Использование функции API требует более
внимательного программирования с
использованием некоторых не очень привычных
методов обращения к процедурам (по сравнению с VB).
Далее мы будем постоянно обращаться к этим
вопросам. А сейчас приведем изложение
сформулированных Дэном Эпплманом советов на эту
тему (их первый вариант появился еще в 1993 году) с
некоторыми нашими дополнениями и комментариями. 1. Помните о ByVal.
Наиболее частая ошибка, совершаемая при обращении
к функциям API и DLL, заключается в некорректном использовании ключевого слова
ByVal: его или забывают ставить, или, наоборот, ставят, когда в нем нет необходимости. На этих примерах показано влияние оператора
ByVal на передачу параметров Здесь следует напомнить, что передача параметров в любой системе программирования,
в том числе и VB, выполняется двумя основными путями: по ссылке (ByRef) или
по значению (ByVal). В первом случае передается адрес переменной (этот вариант
используется в VB по умолчанию), во втором - ее величина. Принципиальное
отличие заключается в том, что с помощью ссылки обеспечивается возврат в вызывающую
программу измененного значения передаваемого параметра. Чтобы разобраться в этом, проведите эксперимент с помощью таких программ: Dim v As Integer
v = 2
Call MyProc(v)
MsgBox “v = “ & v
Sub MyProc (v As Integer)
v = v + 1
End Sub
Запустив на выполнение этот пример, вы получите сообщение со значением переменной,
равным 3. Дело в том, что в данном случае в подпрограмму MyProc передается адрес
переменной v, физически созданной в вызывающей программе. Теперь измените описание
процедуры на Sub MyProc (ByVal v As Integer)
В результате при выполнении теста вы получите v = 2, потому что в процедуру
передается лишь исходное значение переменной - результат выполненных с
ним операций не возвращается в вызывающую программу. Режим передачи по значению
можно поменять также с помощью оператора Call следующим образом: Sub MyProc (v As Integer)
...
Call MyProc((v)) ‘ (v) - скобки указывают режим _
передачи по значению.
Однако при обращении к внутренним
VB-процедурам использование в операторе Call
ключевого слова ByVal запрещено - вместо него
применяются круглые скобки. Этому есть свое
объяснение. В классическом случае (С, Fortran, Pascal)
различие режимов ByRef и ByVal зависит от того, что
именно помещается в стек обмена данными -
адрес переменной или ее значение. В Basic
исторически используется вариант программной
эмуляции ByVal - в стеке всегда находится адрес,
но только при передаче по значению для этого
создается временная переменная. Чтобы отличить
два этих варианта (классический и Basic),
используются разные способы описания режима ByVal.
Отметим, что эмуляция режима ByVal в VB обеспечивает
более высокую надежность программы: перепутав
форму обращения, программист рискует лишь тем,
что в вызывающую программу вернется (или не
вернется) исправленное значение переменной. В
«классическом» же варианте такая путаница может
привести к фатальной ошибке при выполнении
процедуры (например, когда вместо адреса памяти
будет использоваться значение переменной,
равное, скажем, нулю). DLL-функции реализованы по
«классическим» принципам и поэтому требуют
обязательного описания того, каким образом
происходит обмен данными с каждым из аргументов.
Именно этой цели служат объявления функций через
описание Declare (точнее, списка передаваемых
аргументов). Чаще всего передача параметров в
функцию Windows API или DLL выполняется с помощью
ключевого слова ByVal. Причем оно может быть задано
как в операторе Declare, так и непосредственно при
вызове функции. Последствия неправильной передачи параметров легко предугадать. В случае получения
явно недопустимого адреса вам будет выдано сообщение GPF (General Protection
Fault - ошибка защиты памяти). Если же функция получит значение, совпадающее
с допустимым адресом, то функция API залезет в чужую область (например, в ядро
Windows) со всеми вытекающими отсюда катастрофическими последствиями. 2. Проверяйте тип передаваемых параметров.
Не менее важны верное число
и тип передаваемых параметров. Необходимо, чтобы объявленные в Declare аргументы
соответствовали ожидаемым параметрам в функции API. Наиболее часто встречающийся
случай ошибки в передаче параметров связан с различием между NULL и строкой
нулевой длины - следует помнить, что это не одно и то же. 3. Проверяйте тип возвращаемого значения. VB довольно терпимо относится к несовпадению типов возвращаемых функцией значений,
поскольку числовые значения обычно возвращаются через регистры, а не через стек.
Следующие правила помогут определить корректное значение, возвращаемое функцией
API: 4. С большой осторожностью используйте конструкцию «As Any».
Множество
функций Windows API имеют возможность принимать параметры различных типов и
используют при этом обращение с применением конструкции As Any (интерпретация
типа выполняется в зависимости от значения других передаваемых параметров). Хорошим решением в этом случае может быть использование нескольких псевдонимов
(Alias) функции с созданием двух и более объявлений для одной и той же функции,
причем в каждом из описаний указываются параметры определенного типа. 5. Не забывайте инициализировать строки.
В Win API существует множество
функций, возвращающих информацию путем загрузки данных в передаваемые как параметр
строковые буферы. В своей программе вы можете вроде бы все сделать правильно:
не забыть о ByVal, верно передать параметры в функцию. Но Windows не может проверить,
насколько велик размер выделенного под строку участка памяти. Размер строки
должен быть достаточным для размещения всех данных, которые могут быть в него
помещены. Ответственность за резервирование буфера нужного размера лежит на
VB-программисте. Следует отметить, что в 32-разрядных
Windows при использовании строк производится
преобразование из Unicode (двухбайтовая кодировка) в
ANSI (однобайтовая) и обратно, причем с учетом
национальных установок системы. Поэтому для
резервирования буферов порой удобнее
использовать байтовые массивы вместо строковых
переменных. (Подробнее об этом будет рассказано
ниже.) Чаще всего функции Win API позволяют вам самим определить максимальный размер
блока. В частности, иногда для этого нужно вызвать другую функцию API, которая
«подскажет» размер блока. Например, GetWindowTextLength позволяет определить
размер строки, необходимый для размещения заголовка окна, получаемого функцией
GetWindowText. В этом случае Windows гарантирует, что вы не выйдете за границу. 6. Обязательно используйте Option Explicit. 7. Внимательно проверяйте значения параметров и возвращаемых величин.
VB
обладает хорошими возможностями по проверке типов. Это означает, что, когда
вы пытаетесь передать неверный параметр в функцию VB, самое плохое, что может
случиться, - вы получите сообщение об ошибке от VB. Но данный механизм, к сожалению,
не работает при обращении к функциям Windows API. Windows 9x обладает усовершенствованной
системой проверки параметров для большинства
функций API. Поэтому наличие ошибки в данных
обычно не вызывает фатальной ошибки, однако
определить, что же явилось ее причиной - не
так-то просто. Здесь можно посоветовать использовать
несколько способов отладки ошибки данного типа: Кроме того, нужно обязательно проверять результат выполнения API-функции. 8. Помните, что целые числа в VB и в Windows - не одно и то же.
В
первую очередь следует иметь в виду, что под термином «Integer» в VB понимается
16-разрядное число, в документации Win 32 - 32-разрядное. Во-вторых, целые
числа (Integer и Long) в VB - это величины со знаком (то есть один разряд
используется как знак, остальные - как мантисса числа), в Windows -
используются только неотрицательные числа. Это обстоятельство нужно иметь в
виду, когда вы формируете передаваемый параметр с помощью арифметических операций
(например, вычисляете адрес с помощью суммирования некоторой базы и смещения).
Для этого стандартные арифметические функции VB не годятся. Как быть в этом
случае, мы поговорим отдельно. 9. Внимательно следите за именами функций.
В отличие от Win16 имена
всех функций Win32 API являются чувствительными к точному использованию строчных
и прописных букв (в Win16 такого не было). Если вы где-то применяете строчную
букву вместо прописной или наоборот, то нужная функция не будет найдена. Следите
также за правильным использованием суффикса A или W в функциях, применяющих
строковые параметры. (Подробнее об этом – см. ниже.) 10. Чаще сохраняйте результаты работы.
Ошибки, связанные с неверным
использованием DLL и Win API, могут приводить к аварийному завершению работы
VB-среды, а возможно - и всей операционной системы. Вы должны позаботиться о
том, чтобы написанный вами код перед тестовым запуском был сохранен. Самое простое -
это установить режим автоматической записи модулей проекта перед запуском проекта
в среде VB. После прочтения предыдущего совета
может возникнуть мысль, что использование
функций Win API - дело рискованное. В какой-то
степени это так, но только в сравнении с
безопасным программированием, предоставляемым
самим VB. Но при умелом их применении и знании
возможных подводных камней этот риск минимален.
К тому же полностью отказаться от применения Win API
зачастую просто невозможно - они все равно
потребуются при сколь-нибудь серьезной
разработке. К тому же ранее мы упоминали о
«подводных» камнях для широкого класса DLL. В
случае с Win API все обстоит гораздо проще, так как
здесь четко унифицирована форма обращения к этим
функциям. При этом следует иметь в виду следующие
основные моменты: Declare Function name& ‘ тип функции _
определяется с помощью суффикса
Обращение к API-функции выглядит так: ВНИМАНИЕ!
При работе в среде VB для получения значения уточненного
кода ошибки лучше использовать свойство LastDLLError объекта Err, так как
иногда VB обнуляет функцию GetLastError в промежутке между обращением к
API и продолжением выполнения программы. Интерпретировать код, возвращаемый GelLastError, можно с помощью констант,
записанных в файле API32.TXT, с именами, начинающимися с суффикса ERROR_. Наиболее типичные ошибки имеют следующие коды: Однако многие функции возвращают значение некоторого запрашиваемого параметра
(например, OpenFile возвращает значение описателя файла). В таких случаях
ошибка определяется каким-либо другим специальным значением Return&,
чаще всего 0 или –1. С помощью переменных типа Long выполняется не менее 80% передачи аргументов.
Обратите внимание, что аргумент всегда
сопровождается ключевым словом
ByVal, а это, кроме всего прочего, означает, что выполняется односторонняя
передача данных - от VB-программы к API-функции. Б) ByVal ... As String
Этот тип передачи данных также встречается достаточно часто, причем с аргументом
также всегда
применяется ByVal. При вызове API-функции в стек записывается
адрес строки, поэтому в данном случае возможен двусторонний обмен данными.
При работе со строками нужно учитывать несколько опасностей. Первая - резервирование памяти под строку производится в вызывающей
программе, поэтому если API-функция будет заполнять строки, то нужно перед
ее вызовом создать строку необходимого размера. Например, функция GetWindowsDirectory
возвращает путь к каталогу Windows, который по определению не должен занимать
более 144 символов. Соответственно обращение к этой функции должно выглядеть
примерно так: WinPath$ = Space$(144) ‘ резервируем строку в _
144 символа
Result& = GetWindowsDirectory& (WinTath$, 144) _
‘заполнение буфера
‘ Result& - фактическое число символов в имени _
каталога
WinPath$ = Left$(WinPath, Result&)
Вторая проблема заключается в том, что при обращении к API-функции производится
преобразование исходной строки в ее некоторое внутреннее представление,
а при выходе из функции - наоборот. Если во времена Win16 эта операция
заключалась лишь в добавлении нулевого байта в конце строки, то с появлением
Win32 к этому добавилась трансформация двухбайтной кодировки Unicode в ANSI
и наоборот. (Об этом подробно говорилось в статье «Особенности работы со
строковыми переменными в VB», КомпьютерПресс 10’99 и 01’2000). Сейчас же
только отметим, что с помощью конструкции ByVal ... As String можно обмениваться
строками только с символьными данными. В) ... As Any
Это означает, что в стек будет помещен некоторый адрес буфера памяти, интерпретация
содержимого которого будет выполняться API-функцией, например, в зависимости
от значения других аргументов. Однако As Any может использоваться только
в операторе Declare - при конкретном обращении к функции в качестве
аргумента должна быть определена конкретная переменная. Г) ... As UserDefinedType
Такая конструкция также часто применяется, когда необходимо обменяться
данными (в общем случае в обе стороны) с помощью некоторой структуры. На
самом деле эта конструкция - некий вид конкретной реализации формы
передачи As Any, просто в данном случае функция настроена на фиксированную
структуру. Форма структуры данных определяется конкретной API-функцией, и на программисте
лежит ответственность правильным образом описать и зарезервировать ее в
вызывающей программе. Такая конструкция всегда
используется без
слова ByVal, то есть в данном случае выполняется передача по ссылке -
в стек записывается адрес переменной. Проиллюстрируем сказанное выше на примере использования двух полезных функций
работы с файлами - lopen и lread, которые описываются следующим образом: Declare Function lopen Lib “kernel32” _
Alias “_lopen” (_
ByVal lpFileName As String, _
ByVal wReadWrite As Long) As Long
Declare Function lread Lib “kernel32” _
Alias “_lread” (_
ByVal hFile As Long, lpBuffer As Any, _
ByVal wBytes As Long) As Long
В VB их аналогами - в данном случае
точными - являются операторы Open и Get (для
режима Binary). Обратим сразу внимание на
использование ключевого слова Alias в объявлении
функции - это как раз тот случай, когда без
него не обойтись. Настоящие названия функции в
библиотеке начинаются с символа подчеркивания
(типичный стиль для языка C), что не разрешается в
VB. Операция открытия файла может выглядеть следующим образом: Const INVALID_HANDLE_VALUE = -1 ‘ неверное _
значение описателя
lpFileName$ = “D:\calc.bas” ‘ имя файла
wReadWrite& = 2 ‘ режим “чтения-записи”
hFile& = lopen(lpFileName$, wReadWrite&) _
‘ определяем описатель файла
If hFile& = INVALID_HANDLE_VALUE Then _
‘ ошибка открытия файла
‘ уточняем код ошибки
CodeError& = Err.LastDllError
‘CodeError& = GetLastError _
‘ эта конструкция не работает
End If
Здесь нужно обратить внимание на два
момента: Далее можно читать содержимое файла, но это предполагает, что программист должен
иметь некоторое представление о его структуре (так же как это происходит при
работе с произвольными двоичными файлами). В этом случае обращение к функции
lread может выглядеть следующим образом: Dim MyVar As Single
wBytes = lread (hFile&, MyVar, Len(MyVar)
‘ чтение вещественного числа, 4 байта
‘ wBytes - число фактически прочитанных данных,
‘ -1 - ошибка...
Type MyStruct
x As Single
i As Integer
End Type
Dim MyVar As MyStruct
wBytes = lread (hFile&, MyVar, Len(MyVar))
‘ чтение структуры данных, 6 байтов
Еще раз обратите внимание: второй
аргумент функции передается по ссылке,
остальные - по значению. Dim MyVar As String
MyVar = Space$(10)
‘резервируем переменную для 10 символов
wBytes = lread (hFile&, ByVal MyVar, Len(MyVar))
‘ чтение символьной строки, 10 символов
Здесь видно важное отличие от
приведенного ранее примера - строковая
переменная обязательно сопровождается ключевым
словом ByVal. Чтение содержимого файла в массиве (для простоты будем использовать одномерный
байтовый массив) выполняется следующим образом: Dim MyArray(1 To 10) As Byte
wBytes = lread (hFile&, MyArray(1), _
Len(MyArray(1))* 10)
‘ чтение 10 элементов массива
Указывая первый элемент массива в качестве аргумента, мы передаем адрес начала
области памяти, зарезервированной под массив. Очевидно, что таким образом можно
заполнить любой фрагмент массива: WBytes = lread (hFile&, MyArray(4), _
Len(MyArray(1))* 5)
‘ чтение элементов массива с 4-го по 8-й
Здесь на основе предыдущего примера мы
раскроем суть четвертого совета Дэна Эпплмана. Работая с функцией lread, следует помнить, что при обращении к ней с использованием
строковой переменной необходимо использовать ключевое слово ByVal (иначе сообщения
о нелегальной операции не избежать). Чтобы обезопасить себя, можно сделать дополнительное
специальное описание этой же функции для работы только со строковыми переменными: Declare Function lreadString Lib “kernel32” _
Alias “_lread” (_
ByVal hFile As Long, ByVal lpBuffer As String, _
ByVal wBytes As Long) As Long
При работе с этим описанием указывать ByVal при обращении уже не нужно: WBytes = lreadString (hFile&, MyVarString, _
Len(MyVarString)) ‘
Казалось бы, синтаксис оператора Declare позволяет сделать подобное специальное
описание для массива: Declare Function lreadString Lib “kernel32”
Alias “_lread” (_
ByVal hFile As Long, lpBuffer() As Byte, _
ByVal wBytes As Long) As Long
Однако обращение WBytes = lreadArray (hFile&, MyArray(), 10)
неизбежно приводит к фатальной ошибке программы. Это продолжение разговора об
особенностях обработки строковых переменных в
Visual Basic: VB использует двухбайтную кодировку Unicode,
Win API - однобайтную ANSI (причем с форматом,
принятым в С, - с нулевым байтом в конце).
Соответственно при использовании строковых
переменных в качестве аргумента всегда
автоматически производится преобразование из
Unicode в ANSI при вызове API-функции (точнее, DLL-функции)
и обратное преобразование при возврате. Вывод из этого простой: с помощью
переменных String можно обмениваться символьными
данными, но нельзя использовать их для обмена
произвольной двоичной информацией (как это было
при работе с 16-разрядными версиями VB). В последнем
случае лучше использовать одномерный байтовый
массив. Как известно, тип String можно
использовать для описания пользовательской
структуры. В связи с этим нужно помнить
следующее: В случае строки переменной длины в составе структуры передается дескриптор
строки со всеми вытекающими отсюда последствиями в виде ошибки выполнения
программы. При этом производится соответствующее
преобразование кодировок. И последнее замечание: применять массив строковых переменных (как фиксированной,
так и переменной длины) при обращении к API-функции нельзя ни в коем случае.
Иначе появление «нелегальной операции» будет гарантировано. Вполне вероятно, что у вас возникнет
ситуация, когда вам потребуется написать
собственную библиотеку DLL-функций. Потребность в
этом неизбежно появится, если вы будете
использовать технологию смешанного
программирования - использования двух или
более языков программирования для реализации
одного приложения. Отметим в связи с этим, что смешанное
программирование - это вполне обычное
явление для реализации достаточно сложного
приложения. Действительно, каждый язык (точнее,
система программирования на базе языка) имеет
свои сильные и слабые стороны, поэтому вполне
логично использовать преимущества различных
инструментов для решения разных задач. Например,
VB - для создания пользовательского
интерфейса, С - для эффективного доступа к
системным ресурсам, Fortran - для реализации
численных алгоритмов. Мнение автора таково: сколь-нибудь
серьезное занятие программированием требует от
разработчика владения по крайней мере двумя
инструментами. Разумеется, в современных
условиях четкого разделения труда очень сложно
быть отличным экспертом даже по двум системам,
поэтому более логичной является схема «основной
и вспомогательный языки». Идея здесь заключается
в том, что даже поверхностное знание
«вспомогательного» языка (написание довольно
простых процедур) может очень заметно повысить
эффективность применения «основного». Отметим,
что знание VB хотя бы в качестве вспомогательного
является сегодня практически обязательным
требованием для профессионального программиста.
Кстати, во времена DOS для любого программиста, в
том числе Basic, было крайне желательным знание
основ Ассемблера. Так или иначе, но даже в условиях
групповой работы, когда каждый программист
занимается своим конкретным делом,
представление об особенностях процедурного
интерфейса в разных языках должны иметь все
участники проекта. И знать, что многие системы
программирования (в том числе и VB), кроме
интерфейса, используемого по умолчанию,
позволяют применять иные, расширенные методы
обращения к процедурам, которые дают возможность
адаптировать интерфейс к другому языку. При изучении межпроцедурного
интерфейса следует обратить внимание на
следующие возможные «подводные камни»: С учетом всего этого можно сформулировать следующие рекомендации: А что делать, если DLL-функция уже
написана, например, на Фортране, но ее входной
интерфейс не очень хорошо вписывается в
приведенные выше стандарты VB? Здесь можно дать
два совета. Первый: напишите тестовую DLL-функцию и
с ее помощью постарайтесь методом проб и ошибок
подобрать нужное обращение из VB-программы.
Второй: напишите процедуру-переходник на том же
Фортране, который бы обеспечивал простой
интерфейс между VB и DLL-функцией с преобразованием
простых структур данных в сложные (например,
преобразовывал многомерный байтовый массив в
строковый массив). Итак: используйте DLL-функции. Но сохраняйте бдительность... КомпьютерПресс 9"2000 Аббревиатура API,
Application Programming Interface (API) - это просто
некоторый готовый набор функций, который
могут использовать разработчики
приложений. В общем случае данное
понятие эквивалентно тому, что раньше
чаще называли библиотекой подпрограмм.
Однако чаще всего под API подразумевается
некоторая особая категория таких
библиотек. В ходе разработки
практически любого достаточно сложного
приложения (MyAppication) для конечного
пользователя формируется набор
специфических внутренних функций,
используемых для реализации данной
конкретной программы, который называется
MyApplication API. Часто оказывается, что эти
функции могут эффективно использоваться
также для создания других приложений,
в том числе другими программистами.
В этом случае авторы исходя из стратегии
продвижения своего продукта должны
решить вопрос - открывают ли они
доступ к этому набору для внешних
пользователей или нет? При положительном
ответе на него в описании программного
пакета, как его достоинство, появляется
фраза о том, что «комплект включает
открытый набор API-функций». Таким образом,
чаще всего под API подразумевается набор
функций, являющийся частью одного
приложения, но при этом доступных
для использования в других программах.
Например, Excel кроме интерфейса для
конечного пользователя имеет набор
функций Excel API, который может использоваться,
в частности, при создании приложений
с помощью VB. Соответственно,
Windows API - это набор функций, являющийся
частью самой операционной системы
и в то же время - доступной
для любого другого приложения. И в этом
плане вполне оправдана аналогия с набором
системных прерываний BIOS/DOS, который
фактически представляет собой DOS API. Отличие заключается
в том, что состав функций Windows API,
с одной стороны значительно шире,
по сравнению с DOS, с другой -
не включает многие средства прямого
управления ресурсами компьютера, которые
были доступны программистам в предыдущей
ОС. Кроме того, обращение к Windows API
выполняется с помощью обыкновенных
процедурных обращений, а вызов функций
DOS - через специальную машинную
команду процессора, которая называется
Interrupt («прерывание»). Win16 API и Win32 API Как известно смена
Windows 3.x на Windows 95 ознаменовала собой
переход от 16-разрядной архитектуры
операционной системы к 32-разрядной.
Одновременно произошла замена
16-разрядного Windows API (Win16 API) на новый
32-разрядный вариант (Win32 API) . В данном
случае нужно просто иметь в виду, что
за небольшим исключением набор
Win32 API является единым для семейств
Windows 9x и Windows NT. При знакомстве
с Win API обнаруживается, что многие
встроенные функции - не что иное,
как обращение к соответствующим
системным процедурам, но только
реализованные в виде синтаксиса
данного языка. Учитывая это, необходимость
использования API определяется следующим
вариантами: API-функции, которые
полностью реализованы в виде встроенных
функций. Тем не менее, иногда и в этом
случае бывает полезным перейти
к применению API, так как это позволяет
порой существенно повысить производительность
(в частности, за счет отсутствия
ненужных преобразований передаваемых
параметров). Встроенные функции
реализуют лишь частный случай
соответствующей API-функции. Это довольно
обычный вариант. Огромное число
API-функций вообще не имеют аналогов
в существующем сегодня варианте
компиляторов. Например, удалить каталог
нельзя средствами VB - для этого нужно
использовать функцию DeleteDirectory. Следует также
подчеркнуть, что некоторые API-функции
(их доля в Win API весьма незначительна)
не могут вызываться из программ
из-за ряда ограничений языка, например
отсутствие возможности работы с адресами
памяти. Но в ряде случаев могут
помочь нетривиальные приемы программирования
(в частности, в случае с теми же
адресами). Win API
и
Dynamic Link Library
(DLL)
Набор Win API реализован
в виде динамических DLL-библиотек. В данном случае
под DLL мы подразумеваем традиционный
вариант двоичных динамических библиотек,
которые обеспечивают прямое обращение
приложений к нужным процедурам -
подпрограммам или функциям (примерно
также как это происходит при вызове
процедур внутри проекта). Такие библиотеки
могут создаваться с помощью разных
инструментов - VC++, Delphi, Fortran, Assembler. Обычно файлы
динамических библиотек имеют расширение.DLL, но это совсем не обязательно.
Для Win16 часто применялось расширение.EXE, драйверы внешних устройств обозначаются
с помощью.DRV. Определить точное
число API-функций Windows и файлов,
их содержащих, достаточно сложно
(но все они находятся в системном
каталоге). В этом плане лучше выделить
состав библиотек, составляющих ядро
операционной системы, и основных
библиотек с ключевыми дополнительными
функциями. Библиотеки Win32 API
ядра операционной системы Windows 95/98: KERNEL32.DLL: низкоуровневые
функции управления памятью, задачами
и другими ресурсами системы; USER32.DLL: здесь
в основном находятся функции управления
пользовательским интерфейсом; GDI32.DLL: библиотека
Graphics Device Interface - разнообразные функции
вывода на внешние устройства; COMDLG32.DLL: функции,
связанные с использованием диалоговых
окон общего назначения. Основные библиотеки
с функциями расширения: COMCTL32.DLL: набор
дополнительных элементов управления
Windows, в том числе Tree List и Rich Text; MAPI32.DLL: функции
работы с электронной почтой; NETAPI32.DLL: элементы
управления и функции работы с сетью; ODBC32.DLL: функции
этой библиотеки нужны для работы
с различными базами данных через
протокол ODBC; WINMM.DLL: операции
доступа к системным средствам
мультимедиа. Интерфейс прикладного программирования WindowsAPI (applicationprogramminginterface) является интерфейсом системного программирования в пользовательском режиме для семейства операционных систем Windows. До выхода 64-разрядных версий Windows программный интерфейс для 32-разрядных версий операционных систем Windows назывался Win32 API, чтобы его можно было отличить от исходной 16-разрядной версии Windows API (которая служила интерфейсом программирования для начальных 16-разрядных версий Windows). Windows API состоит из нескольких тысяч вызываемых функций, которые разбиты на следующие основные категории: Описание WindowsAPI можно найти в документации по набору инструментальных средств разработки программного обеспечения - WindowsSoftwareDevelopmentKit (SDK). Эта документация доступна на веб-сайте www.msdn.microsoft.com. Она также включена со всеми уровнями подписки в сеть MicrosoftDeveloperNetwork (MSDN), предназначенную для разработчиков. Microsoft .NET Framework состоит из библиотеки классов под названием Framework Class Library (FCL) и управляемой среды выполнения кода -Common Language Runtime (CLR). CLR обладает функциями своевременной компиляции, проверки типов, сборки мусора и обеспечения безопасности доступа к коду. Предлагая эти функции, CLR предоставляет среду разработки, повышающую производительность работы программистов и сокращающую количество наиболее распространенных ошибок программирования. Среда CLR реализована, как классический COM-сервер, код которого находится в стандартной Windows DLL-библиотеке, предназначенной для работы в пользовательском режиме. Фактически все компоненты.NET Framework реализованы как стандартные Windows DLL-библиотеки пользовательского режима, наложенные поверх неуправляемых функций Windows API. (Ни один из компонентов.NET Framework не работает в режиме ядра.) Взаимоотношения между этими компонентами показаны на рисунке. Некоторые термины в пользовательской и программной документации Windows в разных контекстах имеют разные значения. Например, слово служба может относиться к вызываемой в операционной системе стандартной подпрограмме, драйверу устройства или к обслуживающему процессу. Что именно означают те или иные термины, показано в следующем списке: Интересно, что Win32 не планировался в качестве исходного интерфейса программирования для той системы, которая в ту пору называлась Windows NT. Поскольку проект Windows NT запускался в качестве замены для OS/2 версии 2, первоначальным интерфейсом программирования был 32-разрядный OS/2 PresentationManagerAPI. Но через год после запуска проекта произошел взлет поступившей в продажу Microsoft Windows 3.0. В результате этого Microsoft сменила направление и сделала Windows NT будущей заменой семейства продуктов Windows, а не заменой OS/2. В связи с этим и возникла необходимость выработать спецификацию Windows API - до этого, в Windows 3.0, API существовал только в виде 16-разрядного интерфейса. Хотя в Windows API намечалось введение множества новых функций, недоступных в Windows 3.1, Microsoft решила сделать новый API, по возможности, максимально совместимым по именам, семантике и используемым типам данных с 16-разрядным Windows API, чтобы облегчить бремя переноса существующих 16-разрядных Windows-приложений в Windows NT. Этим, собственно, и объясняется тот факт, что многие имена функций и интерфейсов могут показаться непоследовательными: так нужно было для обеспечения совместимости нового Windows API со старым 16-разрядным Windows API. C WinAPI — это основной набор программных интерфейсов (API) Microsoft, доступных в операционных системах Ранняя версия носила название Win32 API. C WinAPI — это интерфейс прикладного программирования, который используется для создания приложений Windows. Для начала работы начинающий пользователь должен загрузить SDK Windows, ранее известный как Platform SDK. Содержит файлы заголовков, библиотеки, образцы, документацию и инструменты, которые используются для разработки приложений. API для языков программирования C и C ++. Это самый прямой способ создания приложений в операционной системе от компании. C WinAPI можно разделить на несколько областей: базовые услуги; безопасность; пользовательский интерфейс; мультимедиа; оболочка Windows; сетевые службы. Базовые службы обеспечивают доступ к основным ресурсам. К ним относятся функции C WinAPI, файловые системы, устройства, процессы, потоки, реестр и обработка ошибок. Область безопасности предоставляет интерфейсы, объекты и другие элементы программирования для аутентификации, авторизации, криптографии и других связанных с безопасностью задач. Подсистема графики обеспечивает функциональность вывода графического содержимого на мониторы, принтеры и другие устройства вывода. Пользовательский интерфейс обеспечивает функциональность для создания окон и элементов управления. Компонент мультимедиа предоставляет инструменты для работы с видео, звуковыми и входными устройствами. Функции интерфейса оболочки позволяют приложениям получать доступ к функциям, предоставляемым оболочкой операционной системы. Сетевые службы предоставляют доступ к сетевым возможностям ОС Windows. При создании WinAPI C следует учитывать базовые возможности, предоставляемые Windows API, которые можно упорядочить в семи категориях. Рассмотрим каждую из них подробнее. Основные услуги предоставляют доступ к базовым системным ресурсам, доступным в Windows. Примеры: файловая система, периферийные устройства, процессы, доступ к системному реестру и система управления исключениями. Эти функции хранятся в файлах kernel.exe, krnl286.exe или krnl386.exe для 16-разрядных систем и kernel32.dll и advapi32.dll для 32-разрядных систем. Графический интерфейс обеспечивает доступ к ресурсам для отображения на мониторах, принтерах и другом периферийном оборудовании. Хранится в файле gdi.exe на 16-разрядных системах и gdi32.dll в 32-разрядных системах. Пользовательский интерфейс отвечает за просмотр и управление основными элементами, такими как кнопки и полосы прокрутки, получение информации о клавиатуре и мыши, а также связанные с ними функции. Эти функции хранятся в файле user.exe в 16-разрядных системах и user32.dll comctl32.dll в 32-разрядных системах. Начиная с версии XP элементы управления были сгруппированы в comctl32.dll. Общие диалоги — отображают данные для открытия и сохранения файлов, выбора цвета и шрифта. Находятся в файле comdlg.dll на 16-разрядных системах и comdlg32.dll в 32-разрядных системах. Windows Shell — компонент WinAPI, который позволяет приложениям получать доступ к функциям, предоставляемым оболочкой операционной системы. Сетевые службы обеспечивает доступ к различным сетевым возможностям операционной системы. Его подкомпоненты включают NetBIOS, Winsock, RPC. В старых версиях — NetDDE. Win16, Win32 и Win32s являются стандартными наборами компонентов, которые позволяют прикладному программному обеспечению использовать функции различных операционных систем семейства Windows. Win32, преемник Win16, был представлен в 1993 году в 32-разрядных продуктах семейства Windows, таких как Windows NT, 2000, 95. Этот программный интерфейс реализован тремя программными библиотеками: Kernel32.dll, User32.dll и GDI32.dll2. Те же функции Win32 доступны во всех продуктах Windows, и, в зависимости от продукта, использование определенных функций может привести к ошибке обслуживания. Возможности Win32 включают в себя взаимодействие между программами, управление процессами, компьютерными сетями, файлами, принтерами, серверами и коммуникационными портами. C WinAPI — это абстрактная спецификация интерфейса программирования для операционной системы Windows. Состоит из объявлений функций, объединений, структур, типов данных, макросов, констант и других элементов программирования. WinAPI описывается главным и находится в заголовках Windows C. Официальная реализация функций WinAPI находится в динамических библиотеках (DLL): например, kernel32.dll, user32.dll, gdi32.dll или shell32.dll в системном каталоге. Существуют сторонние реализации Windows API: в первую очередь проект Wine и проект ReactOS. Windows API — динамический объект. Количество функций постоянно растет с каждой новой версией ОС и новыми пакетами обновлений. Существуют также важные различия между версиями сервера и настольными версиями операционной системы. Некоторые функции официально не документированы. Pelles C — бесплатная программа и лучший компилятор C и интегрированная среда разработки (IDE) для языка программирования C. Поддерживает 32-разрядную Windows (x86) и 64-разрядную Windows (x64). Реализует как стандарты C99, так и C11. Pelles C имеет встроенный редактор ресурсов, растровое изображение, значок и редактор курсоров и редактор шестнадцатеричных дампов. Он разработан шведским разработчиком Пелле Ориниусом. Название компилятора носит имя своего автора. Поставляется с SDK, поэтому программист сразу может приступить к созданию приложений без дальнейшей установки. Чтобы создавать программы Windows API, необходимо включить расширения Microsoft. По умолчанию они выключены, в связи с чем компилятор выдает следующее сообщение об ошибке, которое служит примером C WinAPI с нарушенной структурой: fatal error #1014: #error: "No target architecture" («Нет целевой архитектуры»). Чтобы включить расширения Microsoft, переходим к параметрам проекта и выбираем вкладку «Компилятор». На этой вкладке активируем флажок «Включить расширения Microsoft». Является центральным порталом для разработки Windows. Это огромная коллекция материалов, связанных с разработкой приложений с использованием инструментов Microsoft. Это самая полная база наряду с документацией по разработке настольных приложений и список API Windows. Библиотека общих элементов управления обеспечивает доступ к расширенным функциям операционной системы, таким как строки состояния, индикаторы выполнения, панели инструментов и вкладки. Эти команды находятся в библиотеке commctrl.dll в 16-разрядных системах и comctl32.dll и сгруппированы с пользовательским интерфейсом. DLL — это формат файла динамической библиотеки ссылок, используемый для хранения нескольких кодов и процедур для программ Windows. Файлы DLL были созданы таким образом, что несколько программ могли использовать их информацию одновременно, помогая сохранить память. Позволяет пользователю редактировать кодирование сразу нескольких приложений без их изменения. Библиотеки DLL можно преобразовать в статические, используя MSIL Disassembler или DLL для Lib 3.00. WinAPI как интерфейс прикладного программирования для Windows предлагает множество мощных функций, которые позволяют создавать свои программы, начиная с простой обработки файлов и заканчивая построением графического интерфейса для программирования низкоуровневых драйверов устройств. Прежде чем начать программирование в WinAPI, необходимо настроить среду для кода в ОС Windows. Поскольку это не дистрибутив Linux, у него нет встроенного компилятора для создания приложений. Рассмотрим следующие варианты для компиляции кода: Для Windows доступен комплект разработчика, который предоставляет документацию и инструменты, позволяющие разработчикам создавать программное обеспечение с использованием API и связанных с ним технологий.
Здесь нам на помощь приходит наследование.
Создайте класс который открыто наследуется от структуры RECT и перегрузите оператор вывода << так, как вам угодно.
Например:
{
public:
friend ostream& operator<<(ostream &strm,newrect &rect)
{
strm<<"Prtint RECT object:\n";
strm<
}
};
Так же вы можете сделать с любыми нужными вам операторами.
Например, если надо сравнивать или присваивать структуры (допустим тот же RECT или POINT) - перегрузите operator==() и operator=() соответственно.
Если хотите реализовать оператор меньше < что бы быстро сравнивать размеры окна и т.д. перегрузите operator<().
Так вы можете делать, я предполагаю, почти с любыми структурами и самое главное, что все функции которые работают с обычным объектом структуры RECT так же хорошо будут работать и с его наследником.
И еще рекомендую всю эту красоту вынести в отдельный подключаемый файл и использовать при необходимости.Свой класс
Не знаю как у остальных, но так как я совсем зелёный, я решил для каждой изученной функции или для каждой главы/под главы книги создавать новый проект, что бы всё было по полочкам и можно было в любой момент вернуться и освежить в памяти необходимые моменты.
Так как в WinAPI даже для создания простейшего окна нужно заполнить структуру класса, зарегистрировать её и написать тривиальную оконную процедуру, я после третьего или четвертого проекта вспомнил что я всё таки на С++ пишу.
В итоге я всё спрятал в простенький класс. Хендл окна, его имя, имя класса, адрес оконной процедуры, класс окна (WNDCLASS) всё спрятано в private секцию класса.
Для их получения достаточно описать простенькие методы-Get"еры, к примеру:
HWND GetHWND()
LPCTSTR GetClsName() и т.д.
Заполнение и регистрация оконного класса, создание самого окна и его показ производиться в конструкторе.
Для удобства можно перегрузить конструктор, а заполнение и регистрацию оконного класса спрятать в отдельную private функцию класса и вызывать в каждом из конструкторов. Удобство перегрузки состоит в том, что мне иногда необходимо создать совсем простенькое окно и я вызываю конструктор с двумя параметрами - имя окна и hinstance приложения.
В другой раз мне нужно создать окно с особыми размерами, не с дефолтной процедурой окна и с каким-то другим определённым стилем - я вызываю конструктор с сопутствующими параметрами.
Этот класс у меня определён в отдельно подключаемом файле, который лежит в include папке IDE.
Шаблон такого класса:
class BaseWindow
{
WNDCLASSEX _wcex;
TCHAR _className;
TCHAR _windowName;
HWND _hwnd;
bool _WindowCreation();
public:
BaseWindow(LPCTSTR windowName,HINSTANCE hInstance,DWORD style,UINT x,UINT y,UINT height,UINT width);
BaseWIndow(LPCTSTR windowName,HINSTANCE hInstance);
const HWND GetHWND()const{return HWND;}
LPCTSTR GetWndName()const{return _windowName;}
}; P.S.
Всё описанное справедливо для:
Платформа - Windows 7 32 bit
IDE - Visual Studio 2010
Может у кого-то эти советы будут вызывать смех и иронию, но всё-таки мы все когда-то в чём-то были новичками/стажерами/junior"ами.
Прошу к посту отнестись с понимаем. Конструктивная критика, конечно же приветствуется.
Зачем нужен Win API для VB-программистов
Как изучать Win API
Win API и Dynamic Link Library (DLL)
Совет 1. Следите за правильным оформлением объявления
DL
L-процедур
Совет 2. Будьте особенно внимательны при работе с DLL-функциями
Совет 3. Десять рекомендаций Дэна Эпплмана по надежному
API-программированию в среде VB
Тип параметра
С ByVal
Без ByVal
Integer
В стек помещается 16-разрядное целое
В стек помещается 32-разрядный адрес 16-разрядного целого
Long
В стек помещается 32-разрядное целое
В стек помещается 32-разрядный адрес 32-разрядного целого
String
Строка преобразуется в формат, используемый в С (данные и
завершающий нулевой байт). 32-разрядный адрес новой строки помещается в
стек
В стек помещается VB-дескриптор строки. (Такие дескрипторы
никогда не используются самим Windows API и распознаются только в DLL, реализованных
специально для VB.)
Result& = ApiName& ([СписокАргументов
]
Пример обращения к API-функции
Совет 5. Используйте Alias для передач
и параметров
As Any
Службы, функции и стандартные программы.
История Win32 API.
Введение
Компоненты
Версии
Спецификация
Pelles C
Ошибка целевой архитектуры
MSDN
Применение DLL в WinAPI C
