Сколько можно вложить элементов в класс page
Обновлено: 29.04.2024
Для реализации функциональности приложения в части обработки информации о сотрудниках предприятия необходимо для страницы PageEmployee установить механизм запуска задач ( Отменить, Создать, Редактировать, Сохранить, Найти и Удалить ) при выборе соответствующих пунктов меню и нажатии на кнопки панели инструментов. Технология WPF предлагает модель команд для выполнения такой привязки.
Модель команд обеспечивает делегирование событий определенным командам и управление доступностью элементов управления в зависимости от состояния соответствующей команды. В WPF команда представляет собой задачу приложения и механизм слежения за тем, когда она может быть выполнена. В то же время сама команда не содержит конкретного кода выполнения задачи. Одна и та же команда может быть привязана к одному или нескольким интерфейсным элементам приложения. Инициируют команду источники, которые могут быть различными элементами управления, например пункты меню MenuItem или кнопки – Button. Целевым объектом команды является элемент, для которого предназначена эта команда .
Классы, реализующие команды должны поддерживать интерфейс ICommand. В этом интерфейсе определены два метода Execute, CanExecute и событие CanExecuteChanged.
В WPF имеется библиотека базовых команд. Команды доступны через статические свойства следующих статических классов:
- ApplicationCommands ;
- NavigationCommands ;
- EditingCommands ;
- MediaCommands.
Для создания пользовательских команд целесообразно использовать классы RoutedCommand, который имеет реализацию интерфейса ICommand.
В разрабатываемом приложении для функций Отменить, Создать, Сохранить и Найти будем использовать команды и библиотеки WPF – статический класс ApplicationCommands, а для функций Редактировать и Удалить спроектируем пользовательские команды.
Для разработки пользовательских команд добавим в проект папку Commands и в ней создадим класс DataCommands.
В классе DataCommands объявлены два свойства Delete и Edit типа RoutedCommand. Класс RoutedCommand определяет команду, реализующую ICommand. В конструкторе данного класса определяется объект inputs типа InputGestureCollection. Класс InputGestureCollection представляет упорядоченную коллекцию объектов InputGesture, которые позволяют с помощью класса KeyGesture задать комбинацию клавиш для вызова команды.
Для использования страницей PageEmployee пользовательских команд в XAML -документе необходимо добавить пространство имен , где расположен класс DataCommands. Данному пространству имен присвоим ссылку command.
Теперь для страницы PageEmployee сформируем коллекцию объектов CommandBinding, которая осуществляет привязку команд для данного элемента и объявляет связь между командой, ее событиями и обработчиками.
Для класса CommandBinding свойство Command определяет ссылку на соответствующую команду, а свойства Executed и CanExecute задают обработчики событий при выполнении команды.
На странице приложения используются следующие команды: Отменить, Создать, Редактировать, Поиск, Сохранить и Удалить. Команды могут быть доступны или недоступны пользователю при работе приложения. Это проверяет метод CanExecute при генерации события CanExecuteChanged, которое вызывается при изменении состояния команды. Доступность команд определяется состоянием, в котором находится приложение . В тоже время выполнение какой-либо команды переводит, как правило, приложение в какое-либо другое состояние. Для проектируемого приложения можно определить следующие состояния:
- первоначальная загрузка страницы (1);
- просмотр данных по всем сотрудникам (2);
- редактирование данных по отдельному сотруднику (3);
- создание новой записи по сотруднику в базе данных (4).
На рис. 4.19 приведена диаграмма состояний приложения, на которой кружками обозначены состояния, а дуги соответствуют переходам при выполнении определенной команды.
На основе диаграммы состояний построим таблицу доступности команд в различных состояниях (табл. 4.2).
Из табл. 4.2 видно, что в приложении режим доступности команд в состояниях 1 и 2 противоположно режиму доступности команд в состояниях 3 и 4. Фактически для приложения имеются два режима (один объединяет состояния 1 и 2, а второй – состояния 3 и 4), управлять которыми можно с помощью логической переменной .
В код программы класса PageEmployee введем логическое поле isDirty для управления доступностью команд.
В дальнейшем в обработчики добавим код для обеспечения требуемой функциональности.
В коде класса остается добавить обработчики (реализация метода CanExecute ), которые управляют доступностью команд. Так как при анализе табл. 4.2 было выявлено, что для приложения различимо только два состояния доступности команд, то и обработчиков тоже достаточно иметь в программе два.
Теперь необходимо модифицировать XAML -документ в части задания свойства Command при описании пунктов меню и панели инструментов для привязки команд.
При описании меню ( Menu ) XAML -документ модифицирован следующим образом.
Соответствующие изменения XAML -документа необходимо провести и для панели инструментов ToolBar.
При выполнении приложения различные состояния доступности пунктов меню приведены на рис. 4.20 и рис. 4.21.
Следующим этапом разработки приложения является создание источника данных, который обеспечит взаимодействие приложения с базой данных.
Ключевые термины
Приложение WPF, пространство имен , атрибут , частичный класс , простое свойство, сложное свойство, фрейм , гиперссылка , меню , панель инструментов , команда , привязка команд.
MainWindow, xmlns, partial, InitializeComponent, NavigationWindow, Frame, FrameworkElement, Page, Hyperlink , NavigateUri, Menu , MenuItem, DataGrid , DataGridTextColomn, DataGridCheckBoxColomn, DataGridComboBoxColomn, DataGridHyperlinkColomn, DataGridTemplateColumn, ICommand, Execute , CanExecute, CanExecuteChanged, CommandBinding.
Краткие итоги
В данной теме были рассмотрены вопросы разработки страничного WPF-приложения, организации перехода по страницам, создания системы меню , панели команд, табличного представления информации для просмотра и редактирования данных, системы универсальных команд многократного использования.
Чтобы создать страничное приложение в WPF, нужно перестать применять для пользовательских интерфейсов в качестве контейнера высшего уровня класс Window и вместо него переключиться на класс System.Windows.Controls.Page.
Модель для создания страниц в WPF во многом похожа на модель для создания окон. Хотя создавать объекты страниц можно и с помощью одного лишь кода, обычно для каждой страницы создается файл XAML и файл отделенного кода. При компиляции этого приложения компилятор создает производный класс страницы, который объединяет написанный разработчиком код с генерируемыми автоматически связующими элементами (такими как поля, которые ссылаются на каждый именованный элемент на странице).
объект NavigationWindow, который представляет собой немного видоизмененную версию класса Window;
объект Frame, находящийся внутри другого окна;
объект Frame, находящийся внутри другой страницы;
объект Frame, обслуживаемый непосредственно в Internet Explorer или Firefox.
В качестве примера простейшего страничного приложения давайте создадим следующую страницу:
Теперь изменим содержимое файла App.xaml так, чтобы в качестве начальной страницы использовался файл этой страницы:
При запуске этого приложения среде WPF хватит "интеллектуальных способностей", чтобы понять, что указывается страница, а не окно. Она автоматически создаст новый объект NavigationWindow для выполнения роли контейнера и отобразит страницу внутри него. Она также считает свойство WindowTitle и использует его значение в качестве заголовка окна:
Одно из отличий между страницей и окном заключается в том, что размер страницы обычно не устанавливается, поскольку он определяется обслуживающим ее контейнером (хостом). Если же для свойств Width и Height страницы все-таки указаны какие-то значения, страница делается именно такого размера, но часть ее содержимого может быть усечена, если размер окна хоста оказывается меньше, или размещена по центру доступного пространства, если его размер больше.
Объект NavigationWindow более или менее похож на обычное окно, за исключением кнопок навигации "вперед" и "назад", которые отображаются в строке сверху. Поэтому нетрудно догадаться, что класс NavigationWindow унаследован от класса Window и имеет небольшой дополнительный набор связанных с навигацией свойств. Извлечь ссылку на содержащий объект NavigationWindow можно с помощью следующего кода:
В конструкторе страницы данный код работать не будет, потому что на этом этапе страница пока еще не находится внутри своего контейнера, поэтому нужно дождаться хотя бы, когда возникнет событие Page.Loaded.
По возможности подхода с применением NavigationWindow лучше вообще избегать и использовать вместо него свойства класса Page (и службу навигации). Иначе страница будет тесно связана с контейнером NavigationWindow, и потому ее нельзя будет использовать повторно в других хостах.
При желании создать приложение, состоящее только из кода, для достижения эффекта, показанного на рисунке выше, потребовалось бы создать как страницу, так и навигационное окно. Код, который пришлось бы для этого использовать, показан ниже:
Класс Page
Подобно Window, класс Page допускает наличие только единственного вложенного элемента. Однако класс Page не является элементом управления содержимым: он на самом деле унаследован непосредственно от класса FrameworkElement. Вдобавок класс Page является более простым и отлаженным, чем класс Window. Он имеет небольшой набор дополнительных свойств, которые позволяют настраивать его внешний вид, взаимодействовать с контейнером только определенным, ограниченным образом и применять навигацию. Все эти свойства перечислены ниже:
Background
Принимает кисть, которая позволяет устанавливать заливку для фона
Content
Принимает один элемент, который отображается на странице. Обычно в роли такого элемента выступает контейнер компоновки, такой как Grid или StackPanel
Foreground, FontFamily и FontSize
Определяют внешний вид по умолчанию для текста внутри страницы. Значения этих свойств наследуются элементами внутри страницы. Например, если устанавливается заливка переднего плана и размер шрифта, по умолчанию содержимое внутри страницы получает эти же настройки
WindowWidth, WindowHeight и WindowTitle
Определяют внешний вид окна, в которое упаковывается страница. Эти свойства позволяют управлять хостом путем установки его ширины, высоты и заголовка. Однако они действуют только в том случае, если страница обслуживается в окне (а не во фрейме)
NavigationService
Возвращает ссылку на объект NavigationService, которую можно использовать для отправки пользователя на другую страницу программным путем
KeepAlive
Определяет, должен ли объект страницы оставаться действующим после перехода пользователя на другую страницу.
ShowsNavigationUI
Определяет, должен ли хост для данной страницы отображать навигационные элементы управления (кнопки "назад" и "вперед"). По умолчанию имеет значение true
Title
Устанавливает имя, которое должно применяться для страницы в хронологии навигации. Хост не использует свойство Title для установки заголовка в строке заголовка: для этой цели у него есть свойство WindowTitle
Также важно обратить внимание на отсутствующие компоненты — в классе Page нет эквивалентов для методов Hide() и Show(), доступных в классе Window. Если потребуется показать другую страницу, придется воспользоваться навигацией.
Чтобы вставить страницу внутрь окна, нужно воспользоваться классом Frame. Класс Frame представляет собой элемент управления содержимым, который может удерживать любой элемент, но особенно полезен именно в качестве контейнера для страницы. Он включает свойство под названием Source, которое указывает на отображаемую страницу XAML.
Ниже показан код обычного окна, которое упаковывает кое-какое содержимое в элементе StackPanel и размещает элемент Frame в отдельном столбце:
На рисунке показан результат. Граница вокруг фрейма (элемента Frame) отображает содержимое страницы. Останавливаться на одном фрейме не обязательно. Можно легко создать окно с множеством фреймов и указать им всем на разные страницы:
Как видно на рисунке, в этом примере отсутствуют знакомые кнопки навигации. Дело в том, что для свойства Frame.NavigationUIVisibility по умолчанию устанавливается значение Automatic. Из-за этого навигационные кнопки появляются только тогда, когда в списке посещений уже присутствуют какие-то страницы. Чтобы проверить это, достаточно перейти на новую страницу, и внутри фрейма тут же появятся эти кнопки.
Если свойство NavigationUIVisibility установить в Hidden, навигационные кнопки не будут отображаться никогда, а если в Visible — то будут отображаться с самого начала.
Наличие навигационных кнопок внутри фрейма является хорошим проектным решением, если во фрейме находится содержимое, отделенное от основного потока приложения (например, он служит для отображения контекстно-зависимой справки или содержания последовательного руководства). Но в других случаях может понадобиться, чтобы они отображались в верхней части окна. Для этого потребуется изменить контейнер наивысшего уровня с Window на NavigationWindow. В таком случае окно будет включать навигационные кнопки. Находящийся внутри этого окна фрейм автоматически привяжет себя к этим кнопкам.
В окно можно добавлять столько объектов Frame, сколько нужно. Например, с помощью трех отдельных фреймов несложно построить окно, которое позволит пользователю просматривать задачи приложения, справочную документацию и внешний веб-сайт.
Размещение страниц внутри другой страницы
Объекты Frame дают возможность создавать более сложные композиции окон. Как уже упоминалось в предыдущем разделе, в одном окне можно использовать сразу несколько фреймов (объектов Frame). Однако, помимо этого, фрейм также можно размещать внутри другой страницы и тем самым создавать так называемую вложенную страницу. В действительности этот процесс выглядит точно так же — объект Frame просто добавляется внутрь разметки страницы.
Вложенные страницы представляют более сложную ситуацию в плане навигации. Например, предположим, что вы посещаете страницу и затем щелкаете на ссылке во вложенном фрейме. Что произойдет, если вы после этого щелкнете на кнопке возврата?
По сути, все страницы во фрейме выстраиваются в один список. Так что при первом щелчке на кнопке возврата вы вернетесь на предыдущую страницу во вставленном фрейме, а если щелкнете на этой кнопке еще раз, то вернетесь на посещенную до этого родительскую страницу.
Такая модель навигации является по большей части достаточно понятной, поскольку предполагает наличие в списке предыдущих страниц по одному элементу для каждой посещенной страницы. Однако бывают случаи, когда вложенный фрейм играет менее важную роль, например, показывает различные представления одних и тех же данных или позволяет просматривать многочисленные страницы справочного содержимого.
В таких случаях проход по всем страницам во вложенном фрейме может показаться неудобным или отнимающим много времени процессом. Может быть решено использовать навигационные элементы для управления навигацией только родительского фрейма, т.е. сделать так, чтобы при щелчке на кнопке возврата пользователь сразу же попадал на предыдущую родительскую страницу. Для получения такого эффекта потребуется установить для свойства JournalOwnership вложенного фрейма значение OwnsJournal. Это заставит фрейм применять собственную, отдельную хронологию страниц, в результате чего он также по умолчанию получит собственные навигационные кнопки, позволяющие перемещаться назад и вперед именно по своему содержимому:
Если эти кнопки не нужны, к свойству JournalOwnership можно будет добавить свойство NavigationUIVisibility и с его помощью просто скрыть их. После этого вложенный фрейм будет восприниматься просто как фрагмент динамического содержимого внутри страницы. С точки зрения пользователя никаких навигационных возможностей у него не будет.
Для реализации функциональности приложения в части обработки информации о сотрудниках предприятия необходимо для страницы PageEmployee установить механизм запуска задач ( Отменить, Создать, Редактировать, Сохранить, Найти и Удалить ) при выборе соответствующих пунктов меню и нажатии на кнопки панели инструментов. Технология WPF предлагает модель команд для выполнения такой привязки.
Модель команд обеспечивает делегирование событий определенным командам и управление доступностью элементов управления в зависимости от состояния соответствующей команды. В WPF команда представляет собой задачу приложения и механизм слежения за тем, когда она может быть выполнена. В то же время сама команда не содержит конкретного кода выполнения задачи. Одна и та же команда может быть привязана к одному или нескольким интерфейсным элементам приложения. Инициируют команду источники, которые могут быть различными элементами управления, например пункты меню MenuItem или кнопки – Button. Целевым объектом команды является элемент, для которого предназначена эта команда .
Классы, реализующие команды должны поддерживать интерфейс ICommand. В этом интерфейсе определены два метода Execute, CanExecute и событие CanExecuteChanged.
В WPF имеется библиотека базовых команд. Команды доступны через статические свойства следующих статических классов:
- ApplicationCommands ;
- NavigationCommands ;
- EditingCommands ;
- MediaCommands.
Для создания пользовательских команд целесообразно использовать классы RoutedCommand, который имеет реализацию интерфейса ICommand.
В разрабатываемом приложении для функций Отменить, Создать, Сохранить и Найти будем использовать команды и библиотеки WPF – статический класс ApplicationCommands, а для функций Редактировать и Удалить спроектируем пользовательские команды.
Для разработки пользовательских команд добавим в проект папку Commands и в ней создадим класс DataCommands.
В классе DataCommands объявлены два свойства Delete и Edit типа RoutedCommand. Класс RoutedCommand определяет команду, реализующую ICommand. В конструкторе данного класса определяется объект inputs типа InputGestureCollection. Класс InputGestureCollection представляет упорядоченную коллекцию объектов InputGesture, которые позволяют с помощью класса KeyGesture задать комбинацию клавиш для вызова команды.
Для использования страницей PageEmployee пользовательских команд в XAML -документе необходимо добавить пространство имен , где расположен класс DataCommands. Данному пространству имен присвоим ссылку command.
Теперь для страницы PageEmployee сформируем коллекцию объектов CommandBinding, которая осуществляет привязку команд для данного элемента и объявляет связь между командой, ее событиями и обработчиками.
Для класса CommandBinding свойство Command определяет ссылку на соответствующую команду, а свойства Executed и CanExecute задают обработчики событий при выполнении команды.
На странице приложения используются следующие команды: Отменить, Создать, Редактировать, Поиск, Сохранить и Удалить. Команды могут быть доступны или недоступны пользователю при работе приложения. Это проверяет метод CanExecute при генерации события CanExecuteChanged, которое вызывается при изменении состояния команды. Доступность команд определяется состоянием, в котором находится приложение . В тоже время выполнение какой-либо команды переводит, как правило, приложение в какое-либо другое состояние. Для проектируемого приложения можно определить следующие состояния:
- первоначальная загрузка страницы (1);
- просмотр данных по всем сотрудникам (2);
- редактирование данных по отдельному сотруднику (3);
- создание новой записи по сотруднику в базе данных (4).
На рис. 4.19 приведена диаграмма состояний приложения, на которой кружками обозначены состояния, а дуги соответствуют переходам при выполнении определенной команды.
На основе диаграммы состояний построим таблицу доступности команд в различных состояниях (табл. 4.2).
Из табл. 4.2 видно, что в приложении режим доступности команд в состояниях 1 и 2 противоположно режиму доступности команд в состояниях 3 и 4. Фактически для приложения имеются два режима (один объединяет состояния 1 и 2, а второй – состояния 3 и 4), управлять которыми можно с помощью логической переменной .
В код программы класса PageEmployee введем логическое поле isDirty для управления доступностью команд.
В дальнейшем в обработчики добавим код для обеспечения требуемой функциональности.
В коде класса остается добавить обработчики (реализация метода CanExecute ), которые управляют доступностью команд. Так как при анализе табл. 4.2 было выявлено, что для приложения различимо только два состояния доступности команд, то и обработчиков тоже достаточно иметь в программе два.
Теперь необходимо модифицировать XAML -документ в части задания свойства Command при описании пунктов меню и панели инструментов для привязки команд.
При описании меню ( Menu ) XAML -документ модифицирован следующим образом.
Соответствующие изменения XAML -документа необходимо провести и для панели инструментов ToolBar.
При выполнении приложения различные состояния доступности пунктов меню приведены на рис. 4.20 и рис. 4.21.
Следующим этапом разработки приложения является создание источника данных, который обеспечит взаимодействие приложения с базой данных.
Ключевые термины
Приложение WPF, пространство имен , атрибут , частичный класс , простое свойство, сложное свойство, фрейм , гиперссылка , меню , панель инструментов , команда , привязка команд.
MainWindow, xmlns, partial, InitializeComponent, NavigationWindow, Frame, FrameworkElement, Page, Hyperlink , NavigateUri, Menu , MenuItem, DataGrid , DataGridTextColomn, DataGridCheckBoxColomn, DataGridComboBoxColomn, DataGridHyperlinkColomn, DataGridTemplateColumn, ICommand, Execute , CanExecute, CanExecuteChanged, CommandBinding.
Краткие итоги
В данной теме были рассмотрены вопросы разработки страничного WPF-приложения, организации перехода по страницам, создания системы меню , панели команд, табличного представления информации для просмотра и редактирования данных, системы универсальных команд многократного использования.
Для реализации функциональности приложения в части обработки информации о сотрудниках предприятия необходимо для страницы PageEmployee установить механизм запуска задач ( Отменить, Создать, Редактировать, Сохранить, Найти и Удалить ) при выборе соответствующих пунктов меню и нажатии на кнопки панели инструментов. Технология WPF предлагает модель команд для выполнения такой привязки.
Модель команд обеспечивает делегирование событий определенным командам и управление доступностью элементов управления в зависимости от состояния соответствующей команды. В WPF команда представляет собой задачу приложения и механизм слежения за тем, когда она может быть выполнена. В то же время сама команда не содержит конкретного кода выполнения задачи. Одна и та же команда может быть привязана к одному или нескольким интерфейсным элементам приложения. Инициируют команду источники, которые могут быть различными элементами управления, например пункты меню MenuItem или кнопки – Button. Целевым объектом команды является элемент, для которого предназначена эта команда .
Классы, реализующие команды должны поддерживать интерфейс ICommand. В этом интерфейсе определены два метода Execute, CanExecute и событие CanExecuteChanged.
В WPF имеется библиотека базовых команд. Команды доступны через статические свойства следующих статических классов:
- ApplicationCommands ;
- NavigationCommands ;
- EditingCommands ;
- MediaCommands.
Для создания пользовательских команд целесообразно использовать классы RoutedCommand, который имеет реализацию интерфейса ICommand.
В разрабатываемом приложении для функций Отменить, Создать, Сохранить и Найти будем использовать команды и библиотеки WPF – статический класс ApplicationCommands, а для функций Редактировать и Удалить спроектируем пользовательские команды.
Для разработки пользовательских команд добавим в проект папку Commands и в ней создадим класс DataCommands.
В классе DataCommands объявлены два свойства Delete и Edit типа RoutedCommand. Класс RoutedCommand определяет команду, реализующую ICommand. В конструкторе данного класса определяется объект inputs типа InputGestureCollection. Класс InputGestureCollection представляет упорядоченную коллекцию объектов InputGesture, которые позволяют с помощью класса KeyGesture задать комбинацию клавиш для вызова команды.
Для использования страницей PageEmployee пользовательских команд в XAML -документе необходимо добавить пространство имен , где расположен класс DataCommands. Данному пространству имен присвоим ссылку command.
Теперь для страницы PageEmployee сформируем коллекцию объектов CommandBinding, которая осуществляет привязку команд для данного элемента и объявляет связь между командой, ее событиями и обработчиками.
Для класса CommandBinding свойство Command определяет ссылку на соответствующую команду, а свойства Executed и CanExecute задают обработчики событий при выполнении команды.
На странице приложения используются следующие команды: Отменить, Создать, Редактировать, Поиск, Сохранить и Удалить. Команды могут быть доступны или недоступны пользователю при работе приложения. Это проверяет метод CanExecute при генерации события CanExecuteChanged, которое вызывается при изменении состояния команды. Доступность команд определяется состоянием, в котором находится приложение . В тоже время выполнение какой-либо команды переводит, как правило, приложение в какое-либо другое состояние. Для проектируемого приложения можно определить следующие состояния:
- первоначальная загрузка страницы (1);
- просмотр данных по всем сотрудникам (2);
- редактирование данных по отдельному сотруднику (3);
- создание новой записи по сотруднику в базе данных (4).
На рис. 4.19 приведена диаграмма состояний приложения, на которой кружками обозначены состояния, а дуги соответствуют переходам при выполнении определенной команды.
На основе диаграммы состояний построим таблицу доступности команд в различных состояниях (табл. 4.2).
Из табл. 4.2 видно, что в приложении режим доступности команд в состояниях 1 и 2 противоположно режиму доступности команд в состояниях 3 и 4. Фактически для приложения имеются два режима (один объединяет состояния 1 и 2, а второй – состояния 3 и 4), управлять которыми можно с помощью логической переменной .
В код программы класса PageEmployee введем логическое поле isDirty для управления доступностью команд.
В дальнейшем в обработчики добавим код для обеспечения требуемой функциональности.
В коде класса остается добавить обработчики (реализация метода CanExecute ), которые управляют доступностью команд. Так как при анализе табл. 4.2 было выявлено, что для приложения различимо только два состояния доступности команд, то и обработчиков тоже достаточно иметь в программе два.
Теперь необходимо модифицировать XAML -документ в части задания свойства Command при описании пунктов меню и панели инструментов для привязки команд.
При описании меню ( Menu ) XAML -документ модифицирован следующим образом.
Соответствующие изменения XAML -документа необходимо провести и для панели инструментов ToolBar.
При выполнении приложения различные состояния доступности пунктов меню приведены на рис. 4.20 и рис. 4.21.
Следующим этапом разработки приложения является создание источника данных, который обеспечит взаимодействие приложения с базой данных.
Ключевые термины
Приложение WPF, пространство имен , атрибут , частичный класс , простое свойство, сложное свойство, фрейм , гиперссылка , меню , панель инструментов , команда , привязка команд.
MainWindow, xmlns, partial, InitializeComponent, NavigationWindow, Frame, FrameworkElement, Page, Hyperlink , NavigateUri, Menu , MenuItem, DataGrid , DataGridTextColomn, DataGridCheckBoxColomn, DataGridComboBoxColomn, DataGridHyperlinkColomn, DataGridTemplateColumn, ICommand, Execute , CanExecute, CanExecuteChanged, CommandBinding.
Краткие итоги
В данной теме были рассмотрены вопросы разработки страничного WPF-приложения, организации перехода по страницам, создания системы меню , панели команд, табличного представления информации для просмотра и редактирования данных, системы универсальных команд многократного использования.
Автор статьи
Читайте также: