Визуальные средства программирования

Для демонстрации своего замысла Microsoft запустила веб-сайт Passport, зайдя на который, пользователь мог бесплатно завести себе электронный кошелёк (eWallet), упрощавший процесс совершения покупок в интернет-магазинах.

Через полгода Microsoft переименовала платформу в Microsoft.Net, объявив при этом, что “стратегия корпорации целиком и полностью будет определяться платформой .Net”, а все продукты Microsoft со временем будут переписаны для поддержки этой платформы. Помимо этого изменения должны были затронуть и серверные приложения -- Microsoft SQL Server, Exchange, BizTalk, а офисный пакет Microsoft Office должен был быть преобразован в Office.Net.

К этому времени было приурочено и опубликование документа под названием Microsoft .NET: Realizing the Next Generation Internet (англ. Microsoft .NET: Создавая Интернет следующего поколения) на официальном сайте Microsoft. В нём приводился общий обзор новой платформы, а само появление новой платформы описывалось как некая “революция”. В этом документе впервые было приведено описание (хотя и краткое) технической реализации платформы. Так, разработчикам предлагалось вместо ручного набора большой массы кода собирать свои приложения из готовых блоков, что должно было ускорить разработку ПО. К таким “строительным блокам” относились, в частности, следующие модули:

Identity (рус. Личность) -- технология, объединяющая Windows-аутентификацию и Microsoft Passport, созданная для обеспечения различных уровней безопасности, начиная от паролей и электронных кошельков и заканчивая смарт-картами и устройствами биометрической идентификации.

12 ноября 2000 года Microsoft опубликовала на своём сайте .NET Framework SDK Beta 1, содержащий всё необходимое для первых опытов с новой платформой. Однако, из-за “сырости” программы компания рекомендовала ставить её только на компьютеры, предназначенные исключительно для тестов. Данный SDK мог работать лишь в Windows 2000, Windows NT 4.0 (содержащий NTOP для поддержки ASP.NET), Windows 98 и Windows ME, причём стабильная работа с незадолго до этого вышедшим SQL Server 2000 вовсе не гарантировалась. Данная версия содержала огромное количество ошибок, начиная с проблем при установке и заканчивая не полной поддержкой собственных пространств имён в зависимости от версии Windows.

Основной идеей при разработке .NET Framework являлось обеспечение свободы разработчика за счёт предоставления ему возможности создавать приложения различных типов, способные выполняться на различных типах устройств и в различных средах.

Вторым принципом стало ориентирование на системы, работающие под управлением семейства операционных систем Microsoft Windows.

Архитектура .NET

Программа для .NET Framework, написанная на любом поддерживаемом языке программирования, сначала переводится компилятором в единый для .NET промежуточный байт-код Common Intermediate Language (CIL) (ранее назывался Microsoft Intermediate Language, MSIL). В терминах .NET получается сборка, англ. assembly. Затем код либо исполняется виртуальной машиной CLR, либо транслируется утилитой NGen.exe в исполняемый код для конкретного целевого процессора. Использование виртуальной машины предпочтительно, так как избавляет разработчиков от необходимости заботиться об особенностях аппаратной части. В случае использования виртуальной машины CLR, встроенный в неё JIT-компилятор “на лету” (just in time) преобразует промежуточный байт-код в машинные коды нужного процессора. Современная технология динамической компиляции позволяет достигнуть высокого уровня быстродействия. Виртуальная машина CLR также сама заботится о базовой безопасности, управлении памятью и системе исключений, избавляя разработчика от части работы.

Архитектура .NET Framework описана и опубликована в спецификации Common Language Infrastructure (CLI), разработанной Microsoft и утверждённой ISO и ECMA. В CLI описаны типы данных .NET, формат метаданных о структуре программы, система исполнения байт-кода и многое другое.

Объектные классы .NET, доступные для всех поддерживаемых языков программирования, содержатся в библиотеке Framework Class Library (FCL). В FCL входят классы Windows Forms, ADO.NET, ASP.NET, Language Integrated Query, Windows Presentation Foundation, Windows Communication Foundation и другие. Ядро FCL называется Base Class Library (BCL).

Среды разработки, поддерживающие .NET:

· Microsoft Visual Studio (C#, Visual Basic .NET, Managed C++, F#)

· SharpDevelop

· MonoDevelop

· Embarcadero RAD Studio (Delphi for .NET); ранее Borland Developer Studio (Delphi for .NET, C#)

· Zonnon

· PascalABC.NET

Приложения .NET также можно разрабатывать в текстовом редакторе, просто вызывая компилятор из командной строки.

Microsoft начала разрабатывать .NET Framework в 1999 под именем “Next Generation Windows Services” (NGWS). В 2000 году была выпущена первая бета-версия .NET 1.0.

Таблица 1. История версий .NET Framework

Версия	Номер версии	Дата выхода	Visual Studio	По умолчанию в Windows
1.0	1.0.3705.0	1 мая 2002 года	Visual Studio .NET
1.1	1.1.4322.573	1 апреля 2003 года	Visual Studio .NET 2003	Windows Server 2003
2.0	2.0.50727.42	11 июля 2005 года	Visual Studio 2005
3.0	3.0.4506.30	6 ноября 2006 года	Visual Studio 2005 + расширения	Windows Vista, Windows Server 2008
3.5	3.5.21022.8	9 ноября 2007 года	Visual Studio 2008	Windows 7, Windows Server 2008 R2
4.0	4.0.30319.1	12 апреля 2010 года	Visual Studio 2010

Генеалогическое развитие технологий .NET Framework

.NET Framework 1.0

Первый выпуск .NET Framework вышел 5 января 2002 года для Windows 98, NT 4.0, 2000 и XP. Общая поддержка, осуществляемая компанией Майкрософт, закончилась 10 июля 2007 года, расширенная поддержка закончилась 14 июля 2009 года.

.NET Framework 1.1

Следующий релиз .NET Framework вышел 1 апреля 2003 года. Это была первая версия, автоматически устанавливаемая вместе с операционной системой (Windows Server 2003). Для более старых операционных систем .NET Framework 1.1 была доступна в виде отдельного установочного пакета. Общая поддержка, осуществляемая компанией Майкрософт, закончилась 14 октября 2008 года, а расширенная поддержка окончится 8 октября 2013 года.

.NET Framework 2.0

Версия 2.0 была выпущена одновременно с Visual Studio 2005, SQL Server 2005 и BizTalk 2006. С выходом версии 2.0 была добавлена поддержка настраиваемых (обобщенных, исходных, generic) классов, анонимных методов, полная поддержка 64-битных платформ x64 и IA-64.

.NET Framework 3.0

Версия .NET Framework 3.0, вышедшая в 2006 году, первоначально носила имя WinFX, что отражало её суть: расширение .NET Framework 2.0 с сохранением всех библиотек и добавлением четырёх новых компонентов:

· Windows Presentation Foundation (WPF) -- презентационная графическая подсистема, использующая XAML

· Windows Communication Foundation (WCF)

· Windows Workflow Foundation (WF)

· Windows CardSpace

.NET Framework 3.5

Выпущенная в ноябре 2007 года .NET 3.5, как и версия 3.0, использует CLR версии 2.0. Новшества по сравнению с .NET Framework 3.0 включают в себя:C# 3.0 и VB.NET 9.0, Добавлен язык LINQ и провайдеры LINQ to Objects, LINQ to XML и LINQ to SQL, ASP.NET AJAX включён в поставку. Расширена функциональность WF и WCF. Добавлено пространство имён System.CodeDom.

.NET Framework 4.0

Microsoft анонсировала .NET 4.0 29 сентября 2008 года. Первая бета-версия появилась 20 мая 2009 года, вместе с бета-версией Visual Studio 2010. Нововведения включают в себя:

· Parallel Extensions -- PLINQ (Parallel LINQ) и библиотеку параллельных задач (Task Parallel Library), предназначенные для упрощения программирования для многопроцессорных и распределённых систем;

· Нововведения в Visual Basic и C#;

· Технология Managed Extensibility Framework (MEF);

· Полная поддержка IronPython, IronRuby и F#;

· Поддержка подмножеств .NET Framework и ASP.NET в варианте “Server Core”;

· Поддержка Code Contracts;

· Средства моделирования Oslo и язык программирования M, предназначенный для создания предметно-ориентированных языков и моделей

Окончательная версия .NET Framework 4.0 была выпущена 12 апреля 2010 года вместе с окончательной версией Visual Studio 2010.

Языки программирования в .NET

Одной из основных идей Microsoft .NET является совместимость программных частей, написанных на разных языках. Например, служба, написанная на C++ для Microsoft .NET, может обратиться к методу класса из библиотеки, написанной на Delphi; на C# можно написать класс, наследованный от класса, написанного на Visual Basic .NET, а исключение, созданное методом, написанным на C#, может быть перехвачено и обработано в Delphi. Каждая библиотека (сборка) в .NET имеет сведения о своей версии, что позволяет устранить возможные конфликты между разными версиями сборок.

Языки, поставляемые вместе Microsoft Visual Studio

· C#

· J# -- последний раз был включён в Visual Studio 2005

· VB7 (.NET)

· JScript .NET

· C++/CLI -- новая версия Managed C++

· F# -- член семейства языков программирования ML, включён в Visual Studio 2010

Не встроенные, но активно поддерживаемые языки

· Ada -- см. A#

· APL

· Boo, основан на Python

· COBOL

· Component Pascal (ближе к Oberon чем к Pascal)

· Delphi: Delphi 8, Delphi 2005--2010, Delphi XE

· Eiffel

· Forth

· FORTRAN

· Haskell

· IronRuby -- реализация языка Ruby

· IronPython -- реализация языка Python

· Lexico

· Lisp

· Mercury

· Mondrian

· Nemerle -- гибридный функционально/императивный язык

· Oberon for .NET (ETH) -- незначительные расширения для .NET. Проект приостановлен.

· Oxygene

· Perl

· PHP

· PascalABC.NET

· Prolog

· RPG

· Smalltalk

· Zonnon -- полностью интегрируется в Visual Studio

Критика реализации технологии Microsoft .NET Framework

Реализация платформы .NET Framework вызывала и вызывает множество нареканий. Одним из главных объектов критики является менее рациональное использование ресурсов системы по сравнению с другими технологиями. Так, например, несколько приложений, выполняющихся в управляемой среде, стремятся захватить больше ресурсов, чем приложения того же типа, но обладающие более прямым доступом к ресурсам компьютера.

Недовольство разработчиков вызывает и тот факт, что управляемый CIL-байткод, не подвергшийся обфускации, легко может быть декомпилирован в сравнении с естественным кодом. Подобная уязвимость может привести к потере коммерческой тайны или дать возможность обхода механизмов контроля соблюдения лицензионных соглашений.

Новые версии платформы (3.5 и далее) вызвали новую волну недовольства тем, что они не предустанавливаются в версии Windows, предшествовавшие выходу Windows 7, что вынуждает пользователей тратить значительное время на их установку.

С технической точки зрения платформа также подвергается критике из-за отсутствия поддержки вызовов Streaming SIMD Extensions (SSE) в управляемом коде. Правда, в Mono решили эту проблему, добавив поддержку SIMD Extensions версии 2.2 в пространство имён Mono.Simd. Ещё одним поводом для критики является поддержка стандартов, фактически ограничивающих кроссплатформенную реализацию .NET Framework, в результате чего полноценная реализация платформы присутствует лишь для Windows. Частично, отсутствие мобильности компенсируется разработкой нескольких версий платформы для мобильных устройств, а также урезанными версиями .NET Framework для других операционных систем. Однако, несмотря на близость стандартов, принятых при разработке этих версий, конечные реализации полной совместимостью не обладают.

Проект Mono. Mono -- проект по созданию полноценного воплощения системы .NET Framework на базе свободного программного обеспечения. Основной разработчик проекта Mono -- компания Xamarin, ранее Novell. После заключения Microsoft договорённости с Novell, платформа Mono была официально признана реализацией .NET на Unix-подобных операционных системах: Linux, Mac OS X и других. (Хотя Mono успешно работает и под Microsoft Windows). Однако договорённость касается только Novell и клиентов Novell; также технологии ASP.NET, ADO.NET и Windows Forms не были стандартизированы ECMA/ISO, и использование их в Mono находится под угрозой юридических претензий со стороны Microsoft (претензии возможны только в странах, где существуют патенты на программное обеспечение). Mono предоставляет реализацию ASP.NET, ADO.NET и Windows.Forms, но в то же время рекомендует не использовать эти API.

Проект возглавляет Мигель де Икаса, известный разработчик, основатель проекта GNOME. Реализации Mono существуют для следующих операционных систем:

· Microsoft Windows,

· Linux, BSD (FreeBSD, OpenBSD, NetBSD),

· Solaris,

· Mac OS X,

· Apple iOS,

Поддерживаются платформы: s390, SPARC, PowerPC, x86/x86-64, IA64, ARM, Alpha, MIPS, HPPA

9. Тенденции развития инструментальных средств программирования. Обзор курса

Сейчас на рынке программных продуктов предлагается довольно много разнообразных средств визуальной разработки приложений. Их можно условно разделить на два класса:

- специализированные средства - ориентированные исключительно на работу с вполне определенной СУБД и не предназначенные для разработки обычных приложений, не использующих базы данных. Примером средств такого рода может служить система PowerBuilder фирмы Sybase;

- универсальные средства, которые могут использоваться как для разработки информационных приложений, взаимодействующих с базами данных, так и для разработки любых других приложений, не использующих базы данных. Из таких средств наибольшей известностью пользуются системы BorlandDelphi фирмы Borland и VisualBasic фирмы Microsoft.

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

Инструментарий программирования -- это совокупность программных продуктов, обеспечивающих технологию разработки, отладки и внедрения создаваемых новых программных продуктов. Они делятся на средства для создания приложений и средства для создания информационных систем (Case-технологии).

К средствам для создания приложений можно отнести:

1. Языки, системы программирования(например, C, Pascal, Basic) иинструментальные среды для разработки приложений (например, C++, Delphi, Visual Basic, Java), которые включают средства визуального программирования.

2. Интегрированные среды разработки программ -- средства для комплексного применения на всех технологических этапах создания программ. Они позволяют повысить производительность труда как программистов, так и профессиональных пользователей, автоматизировать создание кодов программ, разрабатывать приложения для архитектуры клиент-сервер, запросов и отчетов.

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

Средства для создания информационных систем -- CASE-технологии -- это программные комплексы, автоматизирующий весь технологический процесс анализа, проектирования, разработки и сопровождения сложных программных систем. Средства CASE-технологии делятся на встроенные в систему и независимые от системы реализации. Они нацелены на коллективную работу над проектом за счет возможности работы в локальной сети разработчиков.

10.Лабораторные работы

Понятие и особенности структуры и архитектуы ЭВМ при программировании. Организация вычислительного процесса.

Начало работы с Visual Studio.Net

1. Концепция решений и проектов

2. Создание нового проекта

3. Классы приложения

4. Контейнер точек

5. Рисование в контексте устройства

6. Реакция на ошибки

Задания. Ознакомиться с терминологией и разобрать на примерах готового проекта.

Типы драйверов и характеристики

В NT существует два типа драйверов: драйверы пользовательского режима и драйверы режима ядра. В дальнейшем, говоря «драйвер», мы будем подразумевать драйвер режима ядра. Такие драйверы являются частью исполнительной системы, а более точно - элементами диспетчера ввода/вывода (архитектура NT и ее компоненты будут обсуждаться ниже). Как следует из названия, при работе драйвера режима ядра процессор находится в режиме ядра (RING 0 - см. любой справочник по защищенному режиму работы процессора).Драйвер NT располагается в файле с расширением .sys и имеет стандартный РЕ-формат (РЕ - Portable Executable).

Драйверы реализованы как самостоятельные модули с четко определенным интерфейсом взаимодействия с ОС. Все драйверы имеют определенный системой набор стандартных функций драйвера (standard driver routines) и некоторое число внутренних функций, определенных разработчиком.Драйверы режима ядра можно разбить на три типа:

· драйверывысшегоуровня (highest level drivers);

· драйверы промежуточного уровня (intermediate drivers);

· драйверынизшегоуровня (lowest level drivers).

Как будет показано ниже, такое разбиение обусловлено многоуровневой моделью драйверов (layered driver model). Для сохранения общности изложения, монолитный драйвер можно включить в эту схему, хотя он не использует многоуровневую архитектуру. В этом случае он будет «гибридом» - драйвером, принадлежащим одновременно к нескольким типам. Например, монолитный драйвер, имеющий интерфейс с приложением и осуществляющий доступ к оборудованию, будет одновременно драйвером высшего и низшего уровня.Кроме того, в зависимости от назначения драйвера, он может являться каким-либо специализированным драйвером, то есть удовлетворять дополнительному набору требований к своей структуре.

Сеанс работы в Studio.Net начинается с открытия существующего или создания нового решения (solution). В дальнейшем вместо термина решение я иногда буду использовать термин рабочее пространство, так как буквальный перевод -- решение -- не всегда точен. Файлы с расширением sin используются IDE (Integrated Development Environment) для хранения настроек и начальных установок конкретных решений. Концепция решений помогает объединить проекты и другие элементы в одном рабочем пространстве. Множество файлов разного типа, в рамках одного решения составляют приложение (application) Visual Studio.Net 7.0. Рабочее пространство может содержать несколько проектов, быть пустым или содержать файлы, которые имеют смысл и вне контекста решений. В любом случае, вы должны начинать работу в студии с открытия существующего или создания нового рабочего пространства.

Проект как часть решения состоит из отдельных компонентов, например файлов, описывающих форму окна или шаблон диалога (re-файл), файлов с исходными кодами программных модулей (.срр, .cs) и/или файлов, представляющих собой описание запроса к базе данных (database script), HTML-документов и, т. д. Настройки проектов хранятся в специальных файлах проектов. Они могут иметь разные расширения, так как в одном пространстве можно объединять проекты совершенно разных типов. Например, проект MFC-приложения хранит свои установки в файле с расширением vcproj, а файл проекта, реализованного на языке

С#, имеет расширение csproj. Такой файл является читаемым, его можно открыть вне рамок Studio.Net (например, с помощью Notepad) и увидеть описание установок проекта на еще одном из «секретных» языков. Например, проект типа MFC Application с именем MyProj содержит файл MyProj.vcproj, начальный фрагмент которого мы приведем здесь:

<?xml version="1.0"?>

<VisualStudioProject ProjectType="Visual C++" Version="7.00" Name="MyProj" Keyword="mfc">

<Build>

<Settings>

<Platform Name="Win32"/>

<Configuration

Name="Debug|Win32"

InterraediateDirectory="Debug"

OutputDirectory="Debug"

ConfigurationType="l"

UseOfMFC="2"

CharacterSet="2">

<Tool Name="VCBscMakeTool"/>

<Tool

Name="VCCLCorapilerTool"

Optimization="0"

При создании нового проекта Studio.Net автоматически создает рабочее пространство и помещает в него этот проект. Вот перечень шагов для создания нового проекта и нового рабочего пространства (solution), его содержащего.

1. В меню File >New выберите команду Project.

2. В появившемся окне диалога New Project, в окне Project Type раскройте узел дерева под именем Visual C++ Projects и выберите узел Win32 Projects.

3. В окне Templates выберите тип проекта MFC Application.

4. В окне Name задайте имя проекта My.

5. В окне Location задайте или оставьте без изменения местоположение новой папки с файлами рабочего пространства.



Рис. 1.2. Окно диалога New Project

Рис. 1.3. Окно мастера MFC Application Wizard

6. Нажмите ОК и проанализируйте предлагаемые по умолчанию настройки проекта, которые определены в появившемся окне диалога, обслуживаемом инструментом Studio.Net под именем MFC Application Wizard.

7. Нажмите кнопку Finish.

. Итак, Application Wizard потрудился и создал стартовую заготовку нового Windows-приложения, которое поддерживает многодокументный интерфейс (MDI). Вы можете немедленно его запустить, дав команду Debug >Start Without Debugging и согласившись с сообщением о том, что конфигурация проекта устарела (подразумевается, ехе-файл либо отсутствует, либо старше, чем какой-либо из исходных файлов проекта). После этого вы имеете возможность наблюдать за процессом компиляции и компоновки в окне Output, которое, скорее всего, появится внизу главного окна Studio.Net. Далее вы увидите окно нового приложения My, поддерживающего стандарт MDI. Опробуйте команды File >New и все команды меню Window этого приложения, следя за заголовками новых дочерних окоп. Закройте стартовое приложение и сосредоточьте внимание на окне Studio.Net с заголовком Solution Explorer, которое, скорее всего, расположено справа от окна VS Home Page.

Примечание

Неуверенность относительно местоположения окон объясняется тем, что окна Studio.Net проявляют удивительную подвижность. При желании вы можете разместить их в разных группах tabbed-окон или сделать их свободными (floating), причаливаемыми (docable) или скрыть (hide). Поэкспериментируйте с командами (Docable, Hide, Floating, Auto Hide контекстного меню, которое появляется при щелчке правой клавишей мыши над заголовками окон.

Опробуйте также команды меню Window. Например, выберите произвольное окно и дайте команду Window > Docable. Отыщите выбранное окно, затем повторите ту же команду и вновь отыщите окно. При работе с кодами в окне редактора наиболее удобным режимом для вспомогательных окон представляется Auto Hide. Studio.Net позволяет очень гибко управлять местоположением своих окон. Отметьте, что вышеупомянутое контекстное меню динамически изменяется в зависимости от текущего состава группы tabbed-окон. В нем появляются другие команды, которые расширяют ваши возможности по управлению интерфейсом Studio.Net. Окно Solution Explorer дает возможность управлять проектами и файлами проектов. Оно является аналогом окна File View в Visual Studio 6 и теперь по умолчанию входит в группу окон, составляющих блок очень полезных страниц (pages), которыми вы будете часто пользоваться. Сейчас активизируйте страницу Class View из этого блока, для того чтобы увидеть состав классов библиотеки MFC, использованный в новом приложении. При поиске вкладки Class View в блоке используйте всплывающие подсказки. Раскройте дерево классов. Отметьте, что теперь кроме шести классов(CAboutDlg, CChildFrame, CMainFrame, CMyApp, CMyDoc, CMyView) в дерево входят и другие элементы, также являющиеся логическими компонентами MFC-приложения. Это глобальные функции и переменные (Global Functions and Variables), макроподстановки И константы (Macros and Constants).

Рис. 1.4. Представление классов в окне Class View

Режимы отображения координат. Масштабирование изображения

Зададимся целью внести изменения в приложение My, которое мы создали в предыдущей главе, таким образом, чтобы изображение геометрической фигуры всегда было в центре окна и следило за изменением размеров окна приложения, меняясь пропорционально. Напомним, что фигурой является многоугольник с произвольным количеством вершин, и он выводится в контекст устройства Windows с помощью объекта класса CDC. Для того чтобы упростить процесс слежения за размерами окна представления, введем в число членов класса CMyView новую переменную, которая будет хранить текущие размеры окна.

1. Вызовите контекстное меню над именем класса CMyView в окне Class View и выберите команду Add > Add Variable.

2. Заполните поля окна мастера так, чтобы он создал private-переменную m_s zView типа csize.

3. Убедитесь в том, что мастер Add Variable выполнил свою работу. В окне Class View вы должны увидеть ее в числе данных класса.

4. Повторите эти же действия и введите в состав CMyView private-переменную UINT m_nLogZoom, в которой мы будем хранить коэффициент увеличения, используемый при переходе из пространства World в пространство Page.

5. В пространстве Page мы увеличим изображение в 100 раз. Измените уже созданный В конструкторе CMyView инициализатор m_nLogZoom (0) на m_nLogZoom (100).

Примечание

Если вы помните (об этом я уже говорил в связи с конструктором документа), наш многоугольник «в миру» задан вещественными координатами и имеет размах в 2 единицы, так как мы вписали его в окружность единичного радиуса, то есть диаметром в 2 единицы. Там же мы преобразовали все координаты в логическую систему, увеличив размеры многоугольника в 100 раз и перевернув его (так как ось Y экрана направлена вниз). Кроме того, мы сдвинули изображение вправо и вниз, чтобы попасть в центр «листа ватмана». Логические координаты (уже целого типа) мы занесли в массив m_Points, который использован в функции OnDraw класса представления при изображении многоугольника. Теперь надо изменить ситуацию. Обычно документ хранит истинные («мировые») координаты объектов, а класс представления преобразовывает их в логические и изображает в физическом устройстве с помощью рассмотренных преобразований. Так делают, потому что пользователя не интересуют логические (Page) координаты. Он должен видеть и иметь возможность редактировать реальные (World) координаты объекта.

Чтобы реализовать указанный подход, надо заменить в классе документа массив целых координат на массив вещественных, а в классе CMyView создать еще один массив, но уже целых координат. Используя уже знакомую технику, введите в состав класса CMyView private-переменную

vector<CPoint> m_Points;

Ее имя совпадает с именем массива координат в документе, но это не помеха, если используешь ООП. Классы ограничивают область действия имен, скрывая их. В интерфейсе класса документа (файл MyDoc.h) замените объявление

vector<CPoint> m_Points;

на

VECPTS m_Points;

Этой заменой мы оставили для контейнера то же имя, но изменили тип его элементов. Тип данных VECPTS -- вектор точек с вещественными (World) координатами -- пока не определен, но мы собираемся его декларировать и определить для того, чтобы было удобно хранить реальные координаты объекта. Для начала создадим свой собственный класс CDPoint, инкапсулирующий функциональность точки с вещественными координатами. Вставьте в начало файла MyDoc.h после директивы препроцессора #pragma once, но до объявления класса CMyDoc декларацию нового класса ¹ :

//====== Новый класс "Вещественная точка"

class CDPoint

{

public:

double x;

double у; // Вещественные координаты

//====== Конструктор по умолчанию

CDPoint()

{

х=0.;

у=0.;

}

//====== Конструктор копирования

CDPoint(const CDPointS pt)

{

x = pt.x;

y = pt.y;

}

//====== Конструктор с параметрами

CDPoint(double xx, double yy)

{

x = x x;

у = yy;

}

//====== Операция умножения (увеличение в п раз)

CDPoint operator* (UINT n)

{

return CDPoint (x*n, y*n);

}

//====== Операцияприсваивания

CDPointS operator=(const CDPointS pt)

{

x = pt.x;

у = pt.y;

return *this; // Возвращаем свой объект

}

//====== Операция сложения двух точек

CDPoint operator*(CDPointS pt)

{

return CDPoint(x + pt.x, у + pt.y);

}

//====== Операциявычитаниядвухточек

CDPoint operator- (CDPointS pt)

{

return CDPoint(x - pt.x, у - pt.y);

}

// Метод приведения к типу CPoint (целая точка)

CPoint Tolnt()

{

return CPoint(int(x),int(у)); }

//====== Операция сложения с записью результата

voidoperator+=(CDPointSpt) { x += pt.x; у += pt.y; }

//====== Операция вычитания с записью результата

voidoperator-=(CDPoint&pt) { x -- pt.x; у -= pt.y; }

// Операция вычисления нормы вектора, заданного точкой

double operator!() { return fabs(x) + fabs(y); } };

При использовании контейнера объектов класса полезно декларировать новый тип данных:

typedef vector<CDPoint, allocator<CDPoint>> VECPTS;

Вставьте эту строку сразу после объявления класса CDPoint. Данное объявление позволяет просто создавать множество контейнеров для хранения точек с вещественными координатами. Представим, что документ должен хранить контуры нескольких деталей сложной конструкции. Тогда каждая деталь конструкции может быть объявлена объектом типа VECPTS, то есть она является контейнером, содержащим координаты точек своего контура.

Кроме трех конструкторов для удобства пользования в классе CDPoint заданы правила сложения и вычитания точек. Метод Tolnt позволяет создать стандартную точку Windows (CPoint) из нашей вещественной точки. Операция умножения точки на целое число без знака (CDPoint operator* (UINT n);) позволяет увеличивать координаты объекта, что мы используем при переходе из World- в Page-пространство. Операция вычисления нормы вектора, начало которого находится в точке (0,0), а конец в данной точке, полезна при оценке степени близости двух точек. В одном из следующих уроков она нам пригодится. Тело конструктора документа можно упростить, так как теперь он помнит реальные координаты объекта и необходимость преобразовывать координаты в пространство Page исчезла. Это преобразование мы сделаем в классе CMyView:

CMyDoc::CMyDoc()

{

// ====== Вспомогательные переменные

double pi = 4. * atan(l.), //====== Углы

al = pi / 10., a2 = 3. * a1,

//===== 2 характерныеточки

xl = cos(al), yl = sin(al), x2 = cos(a2), y2 = sin(a2);

//==== Вещественные (World) координатыугловзвезды

m_Points.push_back(CDPoint( 0., 1.) ) ;

m_Points.push_back(CDPoint(-x2, -y2));

m_Points.push_back(CDPoint( xl, yl)) ;

m_Points.push_back(CDPoint(-xl, yl));

m_Points.push_back(CDPoint( x2, -y2));

}

Масштабирование изображения можно упростить, если следить за текущими размерами клиентской области окна. При изменении пользователем размеров окна-рамки в момент отпускания кнопки мыши система посылает приложению сообщение WM_SIZE, на которое должен среагировать класс CMyView и запомнить в переменной m_szView новые размеры.

Сейчас мы введем в состав CMyView новую функцию отклика, которая будет вызываться в ответ на приход сообщения WM_SIZE. Она должна иметь имя OnSize (так устроена MFC) и иметь особый спецификатор afx_msg, который невидим компилятором (препроцессор заменит его пустым местом), но нужен инструментам Studio.Net. Спецификатор несет информацию о том, что функция OnSize особая -- она является эффективно реализованным обработчиком сообщения (message handler). В Studio.Net процесс создания функций-обработчиков и виртуальных функций сильно изменен. Теперь это делается не с помощью ее инструмента ClassWizard, следы которого однако присутствуют в студии, а в окне Properties.

1. Выделите имя класса CMyView в окне Class View и перейдите на страницу Properties, выбрав соответствующую вкладку.

2. Обратите внимание на панель инструментов окна Properties. Она динамически изменяется в зависимости от выбора (selection) в других окнах. Сейчас на ней должна быть кнопка с подсказкой Messages. Нажмите эту кнопку.

3. В появившемся списке сообщений найдите сообщение WM_S IZE. В правой ячейке (типа Combo box) таблицы выберите <Add> OnSize.

4. Вновь перейдите в окно Class View, найдите новую функцию-обработчик OnSize в составе класса CMyView и сделайте на ней двойной щелчок.

5. Фокус ввода переходит в окно редактора текста для файла MyView.cpp. Введите изменения так, чтобы функция приобрела вид:

void CMyView::OnSize(UINT nType, int ex, int cy)

{

//========== Вызов родительской версии

CView::OnSize(nType, ex, cy) ;

if (cx==0 || cy==0)

return;

//========= Запоминаем размеры окна представления

m_szView = CSize (ex, су); } ;

Проверка if (cx==0...) необходима потому, что каркас приложения вызывает OnSize несколько раз и иногда с нулевыми размерами. Обратите внимание на то, что мастер вставок добавил также и прототип (объявление) функции обработки в интерфейс класса CMyView (см. файл MyView.h):

public:

afx_msg void OnSize(UINT nType, int ex, int cy) ;

Теперь покажем, как с помощью Studio.Net следует определять в классе собственные версии виртуальных функций. Мы собираемся однократно (при открытии окна) преобразовать «мировые» координаты в логические и запомнить их. Это удобно сделать внутри виртуальной функции OnlnitialUpdate, которая унаследована от класса cview. Она вызывается каркасом приложения в тот момент, когда окно еще не появилось на экране, но уже существует его Windows-описатель (HWND) и объект класса CMyView прикреплен (attached) к окну. Напомним также, что документ имеет и поддерживает динамический список всех своих представлений.

1. В окне Class View поставьте курсор на имя класса CMyView и щелкните правой клавишей мыши.

2. Перейдите в окно Properties, щелкнув вкладку, с помощью подсказок отыщите на панели инструментов именно этого окна кнопку Overrides и нажмите ее.

3. Появится длинный список виртуальных функций родительских классов, которые можно переопределить в классе ему view. Найдите в нем функцию OnlnitialUpdate и выберите в правой половине таблицы действие <Add>.

Результат ищите в конце файла MyView.cpp. Внесите изменения в тело функции:

voidCMyView::OnlnitialUpdate()

{

CView::OnlnitialUpdate();

// Создаем ссылку на контейнер World-координат точек

VECPTSS pts = GetDocument()->m_Points;

UINT size = pts.size ();

//====== Задаем размер контейнера логических точек

m_Points. resize (size);

for (UINT i=0; i < size;

m_Points[i] = (pts[i] * m_nLogZoom) .Tolnt () ;

}

Здесь мы добываем из документа World-координаты объекта, умножаем их на коэффициент m_nLogZoom и преобразуем к целому типу. Обратите внимание на использование операций и методов вновь созданного класса CDPoint и на то, что переменная pts создана и инициализирована как ссылка на контейнер точек документа. Теперь осталось изменить коды для перерисовки представления так, чтобы воспользоваться техникой масштабирования, которую мы обсудили в начале главы:

void CMyView: :OnDraw(CDC* pDC)

{

CMyDoc* pDoc = GetDocument () ;

ASSERT_VALID(pDoc) ;

//====== Узнаем размер контейнера точек

UINTnPoints = m_Points.size () ;

if (! nPoints) // Уходим, если он пуст return;

// Сохраняем текущее состояние контекста pDC->SaveDC() ;

// Создаем перо Windows для прорисовки контура

CPen pen (PS_SOLID,2,RGB(0, 96,0) ) ;

//====== Выбираем его в контекст устройства

pDC->SelectObject (spen);

// Создаем кисть Windows для заливки внутренности

CBrush brush (RGB (240, 255, 250) );

pDC->SelectObject (Sbrush);

//====== Задаем режим преобразования координат

pDC->SetMapMode(MM_ISOTROPIC) ;

//====== Сдвиг в логической системе

pDC->SetWindowOrg(0,0) ;

//====== Сдвиг в физической системе

pDC->SetViewportOrg (m_szView.cx/2, m_szView. су/2) ;

//====== Знаменатель коэффициента растяжения

pDC->SetWindowExt (3*m_nLogZoom, 3*m_nLogZoora) ;

//====== Числитель коэффициента растяжения

pDC->SetViewportExt (m_szView.cx, -m_szView.cy) ;

//====== Изображаем полигон

pDC->Polygon (Sra_Points [0] , nPoints) ;

// Восстанавливаем контекст (предыдущие инструменты GDI)

pDC->RestoreDC (-1) ;

}

Запустите приложение (Ctrl+F5) и попробуйте изменять размеры окна, по отдельности сжимая его до предела вдоль обеих координат. Наблюдайте за тем, как размеры звезды следят за размерами окна. Отметьте, что фигура остается в центре окна, а ее пропорции остаются без изменений. Затем задайте режим отображения MM_ANISITROPIC и вновь запустите приложение. Проведите те же манипуляции с окном и отметьте, что пропорции объекта теперь искажаются. Тем не менее оба режима используются на практике. Например, нет смысла изменять пропорции какой-либо конструкции или ее детали, но вполне допустимо изменять пропорции графика функции.

Анализируя трансформации звезды, имейте в виду, что ее размах 2 абстрактные, не определенные нами единицы в world-пространстве и 200 логических единиц в Page-пространстве. Само Page-пространство мы задали с помощью выражения 3*m_nLogZoom, то есть 300 на 300 единиц. При переходе к Device-координатам система растягивает или сжимает его так, чтобы оно занимало все окно. При этом она сдвигает изображение и центр звезды (0,0) попадает в центр окна (m_szview. сх/2, m_szView. су/2). Полезно поэкспериментировать и с другими режимами преобразования координат. При этом следует помнить, что все они, кроме режима ММ_ТЕХТ, предполагают ось Y направленной вверх.

Используемая литература

Леффингуал, Дин, Ундри, Дон Принципы работы с требованиями к ПО. Унифицированный подход. М., 2002г.

Шниер, Толковый словарь компьютерных технологий. М:, 2002 г.

Орлов С. А., Технологии разработки программного обеспечения. Питер, 2002г.

Луиза Тампе, Введение в тестирование программного обеспечения. М.: Вильямс, 2003 г

Традиционное Windows-приложение

Программы, управляемые событиями

Прохождение сообщений в системе

Структура Windows-приложения

Стартовая заготовка приложения Win32

Анализ стартовой заготовки

Оконная процедура

Меню и диалог

Развитие начальной заготовки

Управление пером Windows

Косметическое перо

Геометрическое перо

Перья на основе растровых изображений

Мы с помощью Studio.Net научимся разрабатывать традиционные приложения Win32, основанные на использовании функций API (Application Programming Interface). Вы, конечно, знаете, что приложения для Windows можно разрабатывать как с использованием библиотеки классов MFC, так и на основе набора инструментов, объединенных в разделе SDK (Software Development Kit) студии разработчика. Обширную документацию по SDK вы можете найти в MSDN (Microsoft Developer's Network), которая поставляется вместе со студией. Отдельные выпуски MSDN, зачастую содержат еще более свежую информацию по SDK. Без MSDN успешная деятельность в рамках студии разработчика просто немыслима.

Использование всей мощи MFC облегчает процесс разработки приложений, однако далеко не все возможности Win32 API реализованы в библиотеке MFC, многие из них доступны только средствами API. Поэтому каждому разработчику необходимо иметь представление о структуре и принципах функционирования традиционного Windows-приложения, созданного на основе API-функций. Другими доводами в пользу того, что существует необходимость знать и постоянно углублять свои познания в технологии разработки приложений с помощью SDK, могут быть следующие:

каркас MFC-приложения, так или иначе, содержит внутри себя структуру традиционного Windows-приложения;

многие методы классов MFC содержат, инкапсулируют вызовы API-функций;

накоплен огромный банк готовых решений на основе SDK, которые достаточно просто внедряются в приложения на основе MFC, и не пользоваться которыми означает обеднять себя.

Тема: Анализатор кодов ошибок

Приложение на основе диалога

Дизайн диалога

Управление окном Toolbox

Создаем диалог

Реакция окна на уведомляющие сообщения

Создание и связывание переменных

Вставка значка

Диалог About

Внесение логики разработчика.

Собственные методы класса

Поиск в реестре

Синтаксический анализ файл

При работе с окном диалога вам приходится пользоваться инструментальным окном Toolbox, которое имеет вкладки (tab) несколько необычного вида. Все доступные вкладки инструментов вы сможете увидеть, если воспользуетесь контекстным меню окна Toolbox и выберете команду Show >All >Tabs. Нажимая на заголовки вкладок, вы увидите, что пространство между ними заполняется списками тех элементов управления, которые соответствуют выбранной вкладке. Большинство из этих элементов пока недоступны, но они станут доступны в определенных ситуациях. Сейчас мы рассмотрим, как можно управлять вкладками и их содержимым. Вы можете:

добавить или удалить свою собственную вкладку;

добавить элементы в пространство любой вкладки или удалить их из него;

переименовать как саму вкладку, так и ее элементы;

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

управлять обликом элементов на вкладке (значки или список);

перемещать элементы в пределах вкладки;

сортировать элементы вкладки по алфавиту.

Среди всех вкладок инструментов (tools) есть две особые, которые носят названия General и Clipboard Ring. Они всегда демонстрируются по умолчанию. Другие же вкладки появляются и исчезают в зависимости от контекста, то есть от типа редактора, с которым вы в данный момент работаете. Если выбрать какой-либо элемент на какой-либо вкладке и нажать клавишную комбинацию Shift+Ctrl+C, то этот элемент попадает на вкладку кольцевого буфера инструментов (Clipboard Ring). Нажатие Shift+Ctrl+V восстанавливает в окне текущей вкладки последний элемент из буфера. Повторное нажатие восстанавливает следующий элемент из кольцевого буфера. При многократном повторении Shift+Ctrl+V элементы кольцевого буфера циклически повторяются. Так написано в документации, но в бета-версии такого поведения не наблюдается.

Для того чтобы добавить новую вкладку в окно Toolbox, надо щелкнуть правой клавишей мыши в окне и выбрать команду Add >Tab. Затем ввести имя вкладки во временном текстовом окне и нажать ENTER. Такие вкладки рекомендуют использовать для создания своего любимого набора инструментов. Один инструмент -- стрелка выбора (Pointer) по умолчанию присутствует на всех вкладках. Для удаления вкладки надо выбрать команду Delete » Tab в контекстном меню, вызванном на заголовке вкладки. В документации эта команда называется Remove >Tab, а в действительности (в бета-версии) -- Delete >Tab.

Для того чтобы поместить на вкладку какой-либо элемент, надо выбрать в контекстном меню команду Customize > Toolbox и выбрать в окне диалога из двух списков (рис. 4.1) нужный элемент, включив флажок выбора слева от элемента, и нажать кнопку ОК. С помощью подобных же действий, но выключая флажок, можно убрать элемент из окна инструментов. Кнопка Browse диалога Customize >Toolbox позволяет найти элемент, который не обозначен в списке. Но помните, что многие СОМ-объекты не будут работать в проектах Studio.Net, если они не зарегистрированы, то есть не отражены в окнах диалога.

Рис. 4.1. Окно диалога для поиска элементов управления

Команда Rename > Tab из контекстного меню заголовка вставки позволяет переименовать всю вставку, а команда Rename >Item из контекстного меню самой вставки позволяет переименовать элемент. Команда Show >All >Tabs работает по принципу переключателя. Команда List >View, работающая по этому же принципу, позволяет переключать режим просмотра инструментов (значки/список). Команда Sort > Items >Alphabetically из контекстного меню заголовка вставки позволяет отсортировать инструменты, а команды Move > Up или Move >Down из меню окна -- переместить их.

6. Информация в электронной форме на сервере лаборатории «Системы безопасности», (ауд.207) - Far, MS Visual Studio, С++ Builder, Delphi и др.

Орлов С. А., Технологии разработки программного обеспечения. Питер, 2002г.

2. Р. Денис Гиббс, Управление проектами с помощью IBM Rational Unified Process, М.: КУДИЦ-ПРЕСС, 2007 г.

Используемая литература

Леффингуал, Дин, Ундри, Дон Принципы работы с требованиями к ПО. Унифицированный подход. М., 2002г.

. Шниер, Толковый словарь компьютерных технологий. М:, 2002 г.

Орлов С. А., Технологии разработки программного обеспечения. Питер, 2002г.

Управление файловым деревом

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

· документ -- обозначает класс, производный от MFC-класса CDocument и вобравший в себя (инкапсулирующий) функциональность данных документа;

· представление -- обозначает класс, производный от MFC-класса cview и инкапсулирующий функциональность окна, дочернего по отношению к окну-рамке. В нем в том или ином виде представлены данные документа.

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

Особенностью разрабатываемого приложения является то, что в одном из представлений, управляемых классом cscrollview, пользователь сможет просматривать в качестве «картинок» -- чертежей или схем, выбирать и открывать документы своего приложения, которые расположены в файлах с различными адресами. Навигацию по файловому дереву будем осуществлять с помощью второго представления, которым управляет класс CTreeView. Классы CScrollView и CTreeView являются специализированными потомками класса cview. Класс CTreeView тесно связан с классом CTreeCtrl, который разработан как элемент управления произвольным деревом. Мы должны научиться им управлять.

Документ, выбранный пользователем с помощью двух предыдущих представлений, отображается в третьем, производном от cview, которое служит посредником между пользователем и данными документа. В его окне пользователь сможет редактировать данные документа. В качестве данных мы используем динамический массив (контейнер) точек с вещественными координатами, который удачно моделирует произвольный чертеж -- двухмерную проекцию какого-либо элемента конструкции. Идеи, заложенные в этом учебном приложении, использованы в реальном проекте по расчету физических полей, описываемых дифференциальными уравнениями в частных производных. В частности, производились расчеты поля магнитов, отсюда проистекает выбранное нами расширение (mgn) для документов приложения. В задачах такого рода исходными являются данные о геометрии расчетной области. Именно она наиболее точно определяет документ (вариант расчета). Если число таких геометрий велико, то поиск варианта по картинке расчетной области существенно упрощает жизнь исследователя физических полей. В связи с этим был получен заказ -- ввести в проект возможность поиска и выбора документа по миниатюрному графическому представлению (схеме) геометрии расчетной области. Упрощенная реализация этой части проекта рассмотрена ниже. Начнем с создания стартовой заготовки MDI-приложения.

1. На странице VS Home Page выберите команду (гиперссылку) Create New Project.

2. В окне диалога New Project выберите уже знакомый вам тип проекта: MFC Application, задайте имя проекта Tree и нажмите ОК.

3. В окне мастера MFC Application Wizard выберите вкладку Application Type и сделайте следующие установки: Multiple documents. Windows Explorer, Document/View procedure support, use MFC in a shared DLL

4. Перейдлте на другую страницу мастера (Document Template Strings) и в поле File extension: задайте расширение mgn для файлов документов будущего приложения.

5. На странице User Interface Features поставьте флажок Child maximized, для того чтобы окна документов занимали всю клиентскую область главного окна приложения. Там же установите флажок Maximized, для того чтобы само главное окно занимало весь экран.

6. Так как мы собираемся вводить в проект новые классы для управления окнами, различным образом представляющими документ, целесообразно изменить предлагаемые мастером имена классов. На странице Generated Classes измените имена: CTreeView на CRightView, CChildFrame на CTreeFrame. Будет удобнее ориентироваться в файлах проекта, если изменить также и имена файлов ChildFrm на CScrollView.

7. Нажмите кнопку Finish.

Графика OpenGL

OpenGL - это графический стандарт в области компьютерной графики. На данный момент он является одним из самых популярных графических стандартов во всём мире. Ещё в 1982 г. в Стенфордском университете была разработана концепция графической машины, на основе которой фирма Silicon Graphics в своей рабочей станции Silicon IRIS реализовала конвейер рендеринга. Таким образом была разработана графическая библиотека IRIS GL. На основе библиотеки IRIS GL, в 1992 году был разработан и утверждён графический стандарт OpenGL. Разработчики OpenGL - это крупнейшие фирмы разработчики как оборудования так и программного обеспечения: Silicon Graphics, Inc., Microsoft, IBM Corporation, Sun Microsystems, Inc., Digital Equipment Corporation (DEC), Evans & Sutherland, Hewlett-Packard Corporation, Intel Corporation и Intergraph Corporation.

OpenGL переводится как Открытая Графическая Библиотека (Open Graphics Library), это означает, что OpenGL - это открытый и мобильный стандарт. Программы, написанные с помощью OpenGL можно переносить практически на любые платформы, получая при этом одинаковый результат, будь это графическая станция или суперкомпьютер. OpenGL освобождает программиста от написания программ для конкретного оборудования. Если устройство поддерживает какую-то функцию, то эта функция выполняется аппаратно, если нет, то библиотека выполняет её программно.

Что же представляет из себя OpenGL? С точки зрения программиста OpenGL - это программный интерфейс для графических устройств, таких как графические ускорители. Он включает в себя около 150 различных команд, с помощью которых программист может определять различные объекты и производить рендеринг. Говоря более простым языком, Вы определяете объекты, задаёте их местоположение в трёхмерном пространстве, определяете другие параметры (поворот, растяжение, ...), задаёте свойства объектов(цвет, текстура, материал, ...), положение наблюдателя, а библиотека OpenGL позаботится о том чтобы отобразить всё это на экране. Поэтому можно сказать, что библиотека OpenGL является только воспроизводящей (Rendering) библиотекой, потому что она не поддерживает какие либо периферийные устройства, таких как клавиатура и мышь, она также не поддерживает никаких менеджеров окон. Программист должен сам заботится о том как обеспечить взаимодействие периферийных устройств с библиотекой OpenGL.