С выходом Windows 8 разработчикам стала доступна новая библиотека классов — Windows Runtime. Компоненты WinRT могут использоваться в приложениях Windows Store и настольных приложениях; в неуправляемом коде C/C++, в JavaScript, а также в C# и Visual Basic.
Метаданные Windows Runtime
На внутреннем уровне компоненты WinRT представляют собой компоненты COM (Component Object Model), для описания API которых теперь используются метаданные. Эти метаданные хранятся в файлах с расширением *.winmd и представляют собой обновленную версию метаданных .NET, которые кодируются в соответствие с правилами раздела №2 (Metadata Definition and Semantics) стандарта ECMA-335. Поскольку обычные сборки .NET Framework кодируются с помощью этого же стандарта, это говорит о том, что вы можете использовать знакомые средства (такие как ildasm.exe, Object Browser) для просмотра содержимого этих файлов.
По большей части, просмотр WinMD файла с помощью утилиты ildasm.exe очень похож на просмотр стандартной управляемой сборки. Есть несколько различий, которые могут быть видны — в первую очередь то, что WinMD файлы, в общем, не содержат никаких Intermediate Language (IL) инструкций. Вместо этого, эти файлы описывают API, предоставляемые Windows Runtime.
Meet WinRT, the Windows Runtime API
Реализация этих интерфейсов может быть полностью отделена от их определения, и по сути, может быть записана в машинном коде. Тем не менее, для разработчиков управляемых приложений, детали реализации WinRT API не имеют значения, потому что управляемый код должен видеть только определения API, которые он вызывает. За кулисами, Common Language Runtime (CLR) и операционная система Windows соединяют для вас определения API и их реализации.
Например, в файле метаданных Windows.Foundation.winmd (находится в каталоге %WinDir%System32WinMetadata) вы можете обнаружить следующий тип Windows.Foundation.Collections.PropertySet, конструктор которого не содержит тела, потому что тип реализуется в native code.
Тем не менее, метаданные, которые описывают этот тип позволяют CLR получить экземпляр реализации при вызове конструктора класса.
При просмотре Windows Runtime метаданных можно также заметить, что определения типов и сборок используют новое ключевое слово WindowsRuntime.
Это ключевое слово является контекстно-зависимым и по разному интерпретируется в зависимости от того, где оно применяется. Например, если ключевым словом помечено определение типа (TypeDef), то этот тип подчиняется правилам системы типов Windows Runtime и вызов этого типа следует рассматривать как вызов WinRT API.
Взаимодействие CLR с компонентами WinRT
CRL поддерживает взаимодействие с COM-компонентами через обертки Runtime Callable Wrapper (RCW) и COM Callable Wrapper (CCW). Таким образом в CLR ссылка на WinRT объект представляет собой ссылку на RCW, которая в свою очередь содержит ссылку на WinRT объект. Соответственно управляемый код взаимодействует с RCW, который по сути является интерфейсом между вашим кодом и WinRT объектом.
Introducing C++/WinRT
Аналогичным образом в Windows Runtime ссылка на объект CLR представляет собой ссылку на CCW, которая в свою очередь содержит ссылку на CLR объект. Windows Runtime при этом взаимодействует с CCW для доступа к функциональности управляемого объекта.
WinRT типы и управляемый код
- Основные типы данных, которые кодируются в метаданных с применением того же перечисления ELEMENT_TYPE что и в управляемых сборках. Исключением является тип SByte, который не поддерживается в WinRT.
- Проецируемые типы (mapped types), которые кодируются в WinMD файлах как одни типы, но появляются в управляемом коде как их .NET эквиваленты. Например, когда CLR считывает в метаданных тип Windows.Foundation.Uri, вместо него она использует тип System.Uri. То есть CLR скрывает тип WinRT и предоставляет доступ к нему через другой тип. Кроме того CLR маршалирует тип между управляемым и неуправляемым кодом, что позволяет передавать объект System.Uri в Windows Runtime как Windows.Foundation.Uri. Полный список WinRT типов, которые CLR проецирует на типы FCL можно найти здесь.
- Все остальные типы. Подавляющее большинство типов WinRT API предоставляются .NET разработчикам как есть. Например, если вы используете класс Windows.UI.Xaml.Controls.Button, CLR не предоставляет специальное представление или маршалинг это типа. В эту категорию также включаются типы, для которых среда CLR предоставляет методы расширения. Например, чтобы использовать объект, реализующий WinRT интерфейс Windows.Storage.IInputStream, с классом .NET Framework, которому необходим тип, производный от System.IO.Stream, следует задействовать методы расширения, которые определены в классе System.IO.WindowsRuntimeStreamExtensions сборки System.Runtime.WindowsRuntime.dll.
Проецирование типов
- CLR определяет Windows Runtime тип как частный (private), а не общедоступный (public). Это препятствует тому, чтобы исходный тип был виден управляемому коду. Т.е. с точки зрения управляемого кода единственный тип, который существует — это .NET Framework тип, который является целью отображения.
- Все ссылки на исходный тип преобразуются в ссылки на целевой .NET Framework тип.
Базовый тип
Компоненты WinRT не имеют общего базового класса, однако все классы среды выполнения Windows должны реализовывать интерфейс IInspectable, который в свою очередь наследует от интерфейса IUnknown (что не удивительно). Однако, для .NET разработчиков все WinRT типы выглядят как типы производные от System.Object и соответственно наследуют такие методы как Equals, GetHashCode и т.д. Это становится возможным благодаря тому, что CLR осуществляет маршалинг объектов во время выполнения для преобразования типов между WinRT и .NET представлениями.
Структуры
Структуры WinRT, в отличие от значимых типов CLR, могут содержать только открытые поля одного из базовых типов или же являться другой структурой WinRT. Таким образом, следующий код выдаст ошибку на этапе компиляции:
public struct MyStruct < // ‘MyStruct’ contains non-public field ‘MyStruct.i’. // Windows Runtime structures can contain only public fields. private Int32 i; //Windows Runtime structures can contain only fields. public MyStruct(Int32 i) < this.i = i; >//Windows Runtime structures can contain only fields. public void MyFunc() < >>
К тому же, структуры WinRT не могут определять конструкторы или содержать вспомогательные методы. Однако, некоторые структуры CLR, для удобства, проецирует на свои собственные, тем самым предоставляя разработчикам вспомогательные методы и конструкторы. К таким относятся, например, структура Windows.Foundation.Point, Windows.Foundation.Size и Windows.Foundation.Rect.
Строки
Тип System.String в WinRT представляется как HSTRING. Когда вы вызываете метод среды выполнения Windows, CLR преобразовывает любую .NET Framework строку в HSTRING перед вызовом метода. Аналогично, CLR преобразовывает любые строки, возвращенные из метода среды выполнения в тип System.String. Есть еще одна особенность — система типов WinRT не разрешает строкам принимать значение null.
Вместо null для передачи пустой строки следует использовать String.Empty. При попытке передать null в качестве строки в WinRT функцию, CLR выдаст исключение ArgumentNullException. Точно так же вы никогда не увидите, что WinRT функция может вернуть null-строку, это может быть только пустая строка.
Null-совместимые типы
IReference Method(IReference i);
то в управляемом коде этот метод будет выглядеть следующим образом:
Nullable Method(Nullable i);
Делегаты
В качестве типа параметра или возвращаемого значения делегата WinRT могут использовать только WinRT-совместимые типы. Так же делегаты с глобальной (public) областью видимости не могут быть объявлены как вложенные (на самом деле это общие правила для среды выполнения Windows в целом).
Когда вы передаете объект делегата компоненту Windows Runtime, этот объект упаковывается в обертку CCW, которая не уничтожается сборщиком мусора до тех пор, пока она не будет освобождена компонентом, который ее использует. Интересен так же тот факт, что делегаты WinRT не имеют методов BeginInvoke и EndInvoke.
События
public event EventHandler MyEvent;
то при компиляции этой строки кода, компилятор превращает ее в следующие инструкции:
private EventRegistrationTokenTable> MyEvent; public EventRegistrationToken add_MyEvent(EventHandler handler) < return EventRegistrationTokenTable> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .AddEventHandler(handler); > public void remove_MyEvent(EventRegistrationToken token) < EventRegistrationTokenTable> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .RemoveEventHandler(token); >
public void RaiseEvent() < var list = EventRegistrationTokenTable> .GetOrCreateEventRegistrationTokenTable(ref MyEvent) .InvocationList; if (list != null) list(this, new RoutedEventArgs()); > public void Main() < var myClass = new MyClass(); var token = myClass.add_MyEvent(Handler); myClass.RaiseEvent(); myClass.remove_MyEvent(token); myClass.RaiseEvent(); >private void Handler(object sender, RoutedEventArgs args)
Для того, чтобы вызывать событие, следует воспользоваться свойством InvocationList, возвращающее делегат, список вызовов которого включает в себя все делегаты, добавленные в качестве обработчиков события.
Время и дата
В WinRT время и дата представляются в формате UTC структурой Windows.Foundation.DateTime. CLR проецирует данный тип на структуру System.DateTimeOffset, а не на System.DateTime. Стоит заметить, что DateTime не содержит информацию о часовом поясе. Поэтому дата и время, возвращаемые функциями WinRT в формате UTC, CLR преобразует в локальное время. И наоборот, при передаче структуры DateTimeOffset в WinRT функцию, дата и время преобразуются в UTC формат.
Массивы
WinRT API поддерживает только одномерные массивы. Соответственно следующий код вызовет ошибку времени компиляции:
// Arrays in Windows Runtime method signatures must be one dimensional. public int[,] MyFunc()
В управляемом коде массивы передаются по ссылке, при этом изменения элементов массива будут видны любому коду, который имеет ссылку на экземпляр этого массива.
Однако, для WinRT это не всегда так, потому что содержимое массива маршалируется только в направлении, которое API определяет в своей сигнатуре, используя System.Runtime.InteropServices.InAttribute и System.Runtime.InteropServices.OutAttribute. Оба атрибута применяются к параметрам метода или возвращаемым значениям и определяют направление маршалинга между управляемой и неуправляемой памятью во время выполнения.
В Windows Runtime параметры могут быть либо только для чтения [InAttribute], либо только для записи [OutAttribute] и не могут быть отмечены для чтения и записи одновременно [InAttribute], [OutAttribute]. Это означает, что содержимое массива, передаваемого методу, а также сам массив должны быть предназначены для чтения или для записи. Так, содержимое массива, который помечен атрибутом [InAttribute], копируется в вызываемый метод, поэтому все изменения, которые метод применяет к массиву, не видны вызывающему объекту. Аналогично, содержимое массива, который помечен атрибутом [OutAttribute], устанавливается вызываемым методом и копируется в вызывающий объект, поэтому вызываемый метод не должен делать каких-либо предположений о содержимом исходного массива.
Коллекции
При передачи коллекции CLR упаковывает объект коллекции в обертку CCW и передает ссылку на нее в WinRT API. При этом вызовы через обертку пересекают границу взаимодействия, что отрицательно сказывается на производительности. Однако, в отличие от массивов, возможно выполнение операций без копирования элементов.
Подводя итоги, отмечу, что благодаря изменениям в CLR, разработчики управляемого кода могут легко адаптироваться к новому Windows Runtime API, используя знакомые им технологии. В данной статье я описал далеко не все подробности взаимодействия WinRT и CLR. Однако, это может послужить основой для дальнейшего изучения и более глубоко понимания Windows Runtime.
Источник: habr.com
Компоненты среды выполнения Windows
Компонент среды выполнения Windows — это автономный программный модуль, который можно создать и использовать в качестве источника информации на любом языке среды Windows, включая C#, C++/WinRT, Visual Basic, JavaScript и C++/CX. Вы можете использовать Visual Studio для создания компонента среды выполнения Windows, который может использоваться либо приложением, использующим пакет SDK для приложений для Windows, либо приложением универсальной платформы Windows (UWP).
Для разработчиков C++ мы рекомендуем использовать C++/WinRT. C++/WinRT — это полностью стандартная проекция языка C++17 для API среды выполнения Windows (WinRT), реализованная как библиотека на основе файлов заголовков и предназначенная для предоставления вам первоклассного доступа к современным интерфейсам API Windows. Сведения о создании компонента среды выполнения Windows с помощью C++/WinRT см. в статье Создание компонентов среды выполнения Windows с помощью C++/WinRT.
Для создания компонента среды выполнения Windows разработчики C#, создающие классические приложения в .NET 6 или более поздней версии, могут использовать C#/WinRT. См. статью Создание компонентов среды выполнения Windows с помощью C#/WinRT.
| Создание компонентов среды выполнения Windows с помощью C++/WinRT | В этом разделе показано, как с помощью C++/WinRT можно создать и использовать компонент среды выполнения Windows, который можно вызвать из универсального приложения для Windows, созданного с помощью любого языка среды выполнения Windows. |
| Создание компонентов среды выполнения Windows с помощью C++/CX | В этом разделе показано, как с помощью C++/CX можно создать компонент среды выполнения Windows, который можно вызвать из универсального приложения для Windows, созданного с помощью любого языка для среды выполнения Windows. |
| Пошаговое руководство по созданию компонента среды выполнения Windows на C++/CX и его вызову с помощью JavaScript или C# | В этом пошаговом руководстве описано, как создать простой компонент среды выполнения Windows, являющийся библиотекой DLL, которую можно вызвать с помощью JavaScript, C# или Visual Basic. Прежде чем приступить к изучению этого пошагового руководства, убедитесь, что вы знакомы с такими понятиями, как абстрактный двоичный интерфейс (ABI), ссылочные классы и расширения компонентов Visual C++, которые упрощают работу со ссылочными классами. Дополнительные сведения см. в разделах Создание компонентов среды выполнения Windows в C++ и Справочник по языку Visual C++ (C++/CX). |
| Создание компонентов среды выполнения Windows с помощью C# и Visual Basic | Вы можете создавать собственные типы среды выполнения Windows, упакованные в компонент среды выполнения Windows, с помощью управляемого кода. Этот компонент можно использовать в приложениях универсальной платформы Windows (UWP), написанных на C++, JavaScript, Visual Basic или C#. В данном разделе описываются правила создания компонентов и рассматриваются некоторые аспекты поддержки среды выполнения Windows в .NET. Как правило, такая поддержка разрабатывается таким образом, чтобы быть прозрачной для разработчиков для .NET. Однако при создании компонента, использующего JavaScript или C++, следует учитывать различия в том, как эти языки поддерживают среду выполнения Windows. |
| Пошаговое руководство по созданию компонента среды выполнения Windows на C# или Visual Basic и его вызову с помощью JavaScript или C# | В этом пошаговом руководстве описывается, как использовать .NET с Visual Basic или C# для создания собственных типов среды выполнения Windows, упакованных в компонент среды выполнения Windows. В нем также рассказывается, как вызвать этот компонент из универсального приложения для Windows, созданного для Windows с помощью JavaScript. |
| Создание событий в компонентах среды выполнения Windows | Если ваш компонент среды выполнения Windows вызывает событие типа делегата, определенного пользователем, в фоновом (рабочем) потоке и вы хотите, чтобы среда JavaScript могла получить его, можно реализовать и вызвать событие одним из следующих способов. |
| Компоненты среды выполнения Windows для неопубликованных приложений UWP, выполняемые через посредник | В этой теме описывается компонент, поддерживаемый обновлением до Windows 10 и последующих версий, который ориентирован на корпоративный уровень. Благодаря этому компоненту приложения .NET с поддержкой сенсорного ввода могут использовать существующий код, отвечающий за ключевые бизнес-операции. |
Источник: learn.microsoft.com
Простое приложение WinRT
Многие разработчики познакомились с парадигмой проектирования Windows 8 в системе Windows Phone 7; интересно проследить за тем, как изменялось отношение Microsoft к большим и малым компьютерам. За прошедшие годы компания пыталась приспособить архитектуру традиционных настольных приложений Windows к малым устройствам — мобильным компьютерам и телефонам. Теперь дизайн пользовательского интерфейса телефона проникает на планшеты и настольные системы.
Одной из важных характеристик новой рабочей среды является ее ориентированность на многопальцевый сенсорный ввод, кардинально изменивший отношения между человеком и компьютером. Собственно, определение «многопальцевый» стало лишним, поскольку практически все новые сенсорные устройства реагируют на одновременные касания нескольких пальцев. В одной из частей нового интерфейса программирования приложений Windows 8 ввод с сенсорного экрана, мыши и пера рассматривается универсально, так что приложения автоматически готовы к использованию со всеми тремя источниками ввода.
Windows Phone 8 является конкурентом для популярных мобильных операционных систем, таких как Android и iOS. Для разработки бесплатных программ на айпад и айфон используются совершенно другие языки программирования и платформы (Java для Android и Objective-C для iOS). В настоящее время для приложений Windows 8 существуют три основных варианта программирования, каждый из которых основан на определенном языке программирования и языке разметки:
- C++ и XAML;
- C# или Visual Basic и XAML;
- JavaScript и HTML5.
В этой и последующих статьях мы будем использовать второй вариант. Давайте создадим простой пример, чтобы продемонстрировать возможности WinRT. Предполагается, что на вашем компьютере установлена система Windows 8 или Windows 8.1, а также новейшая версия Microsoft Visual Studio, поддерживающая создание приложений Windows 8. Запустите Visual Studio со стартового экрана Windows 8. Пора браться за программирование!
Первый проект
На исходном экране Visual Studio выберите команду New Project в меню File. Когда на экране появится диалоговое окно New Project, выберите слева категорию Templates, затем подкатегорию Visual C# и строку проекта Windows Store. В списке доступных шаблонов в центральной области выберите тип пустого приложения (Blank App). В нижней части диалогового окна введите в поле Name имя проекта — например, WinRTTestApp.
Оставьте в поле Solution Name то же имя решения. При помощи кнопки Browse выберите каталог для программы и щелкните на кнопке ОК. (Говоря об операциях с Visual Studio, я будут использовать «мышиную» терминологию — «щелкнуть» и т.д, но когда речь пойдет о приложениях, которые вы будете создавать, я перейду на терминологию сенсорных экранов — «коснуться» и т.д. Вероятно, версия Visual Studio, оптимизированная для сенсорного ввода, появится в ближайшие годы.)
Visual Studio создаст решение с именем WinRTTestApp, проект WinRTTestApp в этом решении, а также набор файлов в проекте. Эти файлы перечислены в окне Solution Explorer в правой части экрана Visual Studio. Каждое решение Visual Studio содержит хотя бы один проект, но решение может содержать дополнительные проекты приложений и библиотек.
В список файлов этого проекта входит файл с именем MainPage.xaml. Щелкнув маленькой стрелке рядом с этим файлов вы увидите файл с именем MainPage.xaml.cs смещенный вправо от MainPage.xaml:
Любой из этих двух файлов можно просмотреть — сделайте двойной щелчок на имени файла или же щелкните правой кнопкой мыши на имени и выберите команду Open.
Файлы MainPage.xaml и MainPage.xaml.cs включены в окно Solution Explorer, потому что каждый из них вносит свой вклад в определение класса MainPage. В простых программах, таких как наша, класс MainPage определяет все визуальные аспекты и пользовательский интерфейс приложения.
Несмотря на странное имя, файл MainPage.xaml.cs определенно имеет расширение .cs, то есть содержит код C#. Если убрать из файла все комментарии, базовый код C# в MainPage.xaml.cs выглядит так:
using System; using System.Collections.Generic; using System.IO; using System.Linq; using System.Runtime.InteropServices.WindowsRuntime; using Windows.Foundation; using Windows.Foundation.Collections; using Windows.UI.Xaml; using Windows.UI.Xaml.Controls; using Windows.UI.Xaml.Controls.Primitives; using Windows.UI.Xaml.Data; using Windows.UI.Xaml.Input; using Windows.UI.Xaml.Media; using Windows.UI.Xaml.Navigation; namespace WinRTTestApp < public sealed partial class MainPage : Page < public MainPage() < this.InitializeComponent(); >> >
Большое место в этом файле занимают директивы using для всех пространств имен, которые, как предполагается, понадобятся для работы программы. Впрочем, в большинстве файлов MainPage.xaml.cs нужны не все перечисленные пространства имен, а во многих файлах требуются дополнительные пространства.
Пространства имен делятся на две общие категории по префиксу имени:
- System.*** — пространства имен из базовых сборок платформы .NET Framework для новых приложений Windows 8;
- Windows.*** — пространства имен из сборки Windows Runtime (или WinRT).
Как можно предположить по виду списка директив using, пространства имен, начинающиеся с Windows.UI.Xaml, играют важную роль в работе Windows Runtime.
После директив using в файле MainPage.xaml.cs определяется пространство имен с именем WinRTTestApp (тем же, что и в имени проекта) и класс MainPage, производный от Page — класса, который является частью Windows Runtime.
Документация Windows 8 API упорядочена по пространствам имен. Если вы хотите найти документацию класса Page, информация о пространстве имен, в котором этот класс определен, упростит поиск. Наведите указатель мыши на имя Page в исходном коде MainPage.xaml.cs; вы увидите, что класс Page находится в пространстве имен Windows.UI.Xaml.Controls (вы можете нажать клавишу F1 в Visual Studio для загрузки описания класса на MSDN).
Конструктор класса MainPage вызывает метод InitializeComponent() (о котором мы вскоре поговорим подробнее).
Обратите внимание на ключевое слово partial в определении класса MainPage. Это ключевое слово обычно означает, что определение класса продолжается в другом файле с исходным кодом C#. Как вы вскоре убедитесь, в нашем случае дело обстоит именно так, однако недостающей частью класса MainPage является не другой файл с кодом C#, а файл MainPage.xaml:
Файл состоит из разметки в стандарте, известном как — произносится «зэмл». И как подсказывает название, XAML происходит от языка XML.
Обычно файл в формате XAML используется для определения визуальных элементов страницы, а файл C# делает то, что нельзя сделать в разметке — например, обрабатывает данные и реагирует на ввод данных пользователем. Файл C# часто называют файлом отделенного кода (code-behind file) для соответствующего файла XAML. Подобная модель компоновки приложений принята во многих архитектурных платформах .NET (WPF, Silverlight, ASP.NET Web Forms) и должна быть вам знакома, если вы с ними работали.
Корневой элемент файла XML — Page — уже известен вам как класс Windows Runtime. Но обратите внимание на атрибут:
x_Class=»WinRTTestApp.MainPage»
Атрибут x:Class может присутствовать только в корневом элементе файла XAML. Этот конкретный атрибут означает «класс с именем MainPage в пространстве имен WinRTTestApp определяется как производный от Page». Он означает то же, что и определение класса в файле C#!
Далее следуют объявления пространств имен XML. Как обычно, эти URI не подразумевают фактического обращения к веб-страницам, а служат уникальными идентификаторами, поддерживаемыми некоторыми компаниями или организациями. Первые два пространства особенно важны:
xmlns_x=»http://schemas.microsoft.com/winfx/2006/xaml»
В 2006 году компания Microsoft представила Windows Presentation Foundation; тогда же состоялся дебют XAML. Технология WPF была частью платформы .NET Framework 3.0, которая до выпуска обозначалась сокращением WinFX, отсюда и «winfx» в URI. Файлы XAML в определенной степени совместимы с WPF, Silverlight, Windows Phone и Windows Runtime, но только в том случае, если они используют классы, свойства и функции, общие для всех сред.
Первое объявление пространства имен без префикса относится к открытым классам, структурам и перечислениям, определенным в Windows Runtime; в эту категорию входят все элементы управления и вообще все, что может включаться в файл XAML, включая классы Page и Grid конкретного файла. Слово представление (presentation) в URI относится к визуальному пользовательскому интерфейсу, и это отличает его от других типов приложений, использующих XAML. Например, при использовании XAML для Windows Workflow Foundation (WF) в конце URI пространства имен по умолчанию стояло бы слово «workflow».
Второе объявление пространства имен связывает префикс «x» с элементами и атрибутами, принадлежащими XAML. Только девять из них могут использоваться в приложениях Windows Runtime; и конечно, самым важным является атрибут x:Class.
Третье объявление пространства имен выглядит интереснее:
xmlns_local=»using:WinRTTestApp»
Оно связывает префикс XML local с пространством имен WinRTTestApp данного конкретного приложения. Если вы создадите в своем приложении пользовательские классы, для обращения к ним в XAML будет использоваться префикс local. Если вам потребуется обращаться к классам из библиотек программного кода, вы определите дополнительные объявления пространств имен XML с указанием имен сборок и пространств имен этих библиотек. Позднее вы увидите, как это делается.
Оставшиеся объявления пространств имен предназначены для Microsoft Expression Blend. Expression Blend может вставлять собственную разметку, которая должна игнорироваться компилятором Visual Studio; отсюда атрибут ignorable, требующий еще одного объявления пространства имен. В любой программе из последующих примеров три последних строки корневого элемента Page можно удалить.
У элемента Page имеется дочерний элемент с именем Grid — еще один класс, определенный в пространстве имен Windows.Ul.Xaml.Controls. Иногда его называют «контейнером», так как Grid может содержать другие визуальные объекты, но формально правильнее называть его «панелью», так как он является производным от класса Panel. Классы, производные от Panel, играют очень важную роль в структуре макета приложений Windows 8 и определяют их компоновку. В файле MainPage.xaml, который Visual Studio создает за вас, элементу Grid назначается цвет фона (на самом деле объект Brush) с использованием заранее определенного идентификатора и синтаксиса, используя ресурсы.
В общем случае Grid делится на строки и столбцы для определения отдельных ячеек — что-то вроде значительно усовершенствованной таблицы HTML или просто сетки. Впрочем, элемент Grid без строк и столбцов тоже способен принести немалую пользу.
Для вывода абзаца текста в Windows Runtime обычно используется элемент управления TextBlock (еще один класс, определенный в пространстве имен Windows.UI.Xaml.Controls). Давайте разместим элемент TextBlock в Grid с одной ячейкой и назначим ему набор атрибутов. В действительности эти атрибуты являются свойствами, определяемыми классом TextBlock:
Порядок следования атрибутов роли не играет, как, разумеется, и отступы. Если вы очень торопитесь, все атрибуты, кроме Text, можно опустить. В процессе ввода текста функция Visual Studio IntelliSense предлагает имена атрибутов и возможные значения. Часто достаточно выбрать нужный вариант из списка. А когда вы завершаете ввод TextBlock, в представлении конструирования (конструктор представления, design view) Visual Studio отображается внешний вид страницы.
Также можно обойтись вообще без ввода, просто перетащить TextBlock из палитры инструментов Toolbox в Visual Studio, а затем задать свойства в таблице, но я так поступать не стану. Процесс создания программ будет описываться так, словно мы с вами вводим код и разметку с клавиатуры, как настоящие программисты.
Программу можно запустить в эмуляторе с возможностью управления разрешением, ориентацией и другими характеристиками. На панели инструментов Visual Studio находится раскрывающийся список, в котором выбрана строка Local Machine; замените ее строкой Simulator. Нажмите F5 , чтобы откомпилировать и запустить программу, или выберите команду Start Debugging в меню Debug. Даже такие простые программы желательно запускать в отладчике Visual Studio:
Атрибуты HorizontalAlignment и VerticalAlignment элемента TextBlock обеспечили выравнивание текста по центру, а вам как программисту не пришлось явно определять размер отображаемой области и размер выводимого текста. Также атрибуту HorizontalAlignment можно задать значение Left или Right, а атрибуту VerticalAlignment — значение Тор или Bottom, чтобы разместить TextBlock в одном из девяти мест Grid. Windows Runtime поддерживает возможность точного размещения визуальных объектов в пикселах, но обычно лучше использовать встроенные средства формирования макета.
У элемента TextBlock есть свойства Width и Height, но обычно задавать их не обязательно. Более того, задание свойств Width и Height в этом конкретном случае может привести к отсечению части текста или нарушению выравнивания текста по центру страницы. Элемент TextBlock умеет определять свои размеры лучше вас.
Программа может быть запущена на устройстве, реагирующем на изменение ориентации — например, на планшете. В этом случае вы заметите, что содержимое страницы динамически изменяется при изменении ориентации и пропорций, не требуя каких-либо действий со стороны программы. Всю основную работу выполняют Grid, TextBlock и система формирования макета Windows 8.
Чтобы завершить выполнение программы, нажмите клавиши Shift+F5 в Visual Studio или выберите команду Stop Debugging в меню Debug. Вы увидите, что программа не только была выполнена, но и стала доступной на начальном экране. Если вы сами создали проект, плитка выглядит не слишком впечатляюще, однако плитки программы хранятся в каталоге Assets проекта, так что при желании вы можете украсить их. Программу можно повторно запустить вне отладчика Visual Studio прямо с начального экрана Windows 8.
Графическое приветствие
Традиционные программы «Hello world» выводят приветствие в текстовом виде, но это не единственный вариант. Давайте используем растровое изображение с моего веб-сайта при помощи крошечного фрагмента разметки XAML:
Элемент Image определен в пространстве имен Windows.UI.Xaml.Controls; это стандартный механизм вывода растровых изображений в программах Windows Runtime. По умолчанию изображение масштабируется так, чтобы заполнить все выделенное место с сохранением исходных пропорций. При уменьшении страницы (например, из-за изменения ориентации устройства или активизации режима Snap View) размеры изображения изменяются в соответствии с новыми размерами страницы. Стандартный режим вывода изображения можно изменить при помощи свойства Stretch элемента Image. По умолчанию используется значение перечисляемого типа Stretch.Uniform. Попробуйте заменить его на Fill — изображение будет заполнять контейнер без сохранения пропорций:
Если свойство Stretch равно None, изображение выводится с исходными размерами (800 х 450). Местонахождением изображения на странице можно управлять при помощи тех же свойств HorizontalAlignment и VerticalAlignment, которые используются с TextBlock. При четвертом значении свойства Stretch — UniformToFill — контейнер заполняется с сохранением пропорций изображения. Это может быть сделано только одним способом: обрезкой изображения. Выбор отсекаемой части зависит от свойств HorizontalAlignment и VerticalAlignment.
Загрузка растрового изображения по сети зависит от наличия сетевого подключения, и даже при его наличии может потребовать некоторого времени. Чтобы гарантировать доступность изображения, лучше включить его в само приложение. Windows Runtime поддерживает популярные графические форматы BMP, JPEG, PNG и GIF, а также некоторые менее распространенные форматы. Для таких изображений, как наше, чаще всего используется формат PNG; сохраните его под именем win8logo.png.
Обычно для хранения растровых изображений, используемых проектом, используется каталог с именем Images. В окне Solution Explorer щелкните правой кнопкой мыши на имени проекта, выберите команды Add и New Folder. (Или если проект выделен в Solution Explorer, выберите команду New Folder в меню Project.) Введите имя папки, например, Images.
Теперь щелкните правой кнопкой мыши на папке Images, выберите команды Add и Existing Item. Перейдите к сохраненному ранее файлу win8logo.png и щелкните на кнопке Add. Когда файл будет добавлен в проект, щелкните правой кнопкой мыши на имени файла и выберите команду Properties. Убедитесь в том, что на панели свойств в поле Build Action выбран пункт Content — изображение должно стать частью содержимого приложения.
Файл XAML со ссылкой на изображение очень похож на аналогичный файл для обращения к изображению в Интернете:
Обратите внимание: в свойстве Source указывается папка и имя файла. Некоторые программисты предпочитают хранить графику, используемую в приложении, в папке с именем Assets. В стандартный проект включается папка Assets с изображениями логотипа приложения; вы можете использовать ее для своих изображений, вместо того чтобы создавать отдельную папку.
Источник: professorweb.ru