if (++_currImage >=_images.Count)
{
_currImage=0;
}
imageHolder.Source=_images[_currImage];
}
Теперь можете запустить программу и переключаться между всеми изображениями.
Если файлы изображений необходимо встроить прямо в сборку .NET Core как двоичные ресурсы, тогда выберите файлы изображений в окне Solution Explorer (из папки \Images, а не \bin\Debug\Images) и установите свойство Build Action в Resource (Ресурс), а свойство Copy to Output Directory — в Do not copy (He копировать), как показано на рис. 27.2.
В меню Build (Сборка) среды Visual Studio выберите пункт Clean Solution (Очистить решение), чтобы очистить текущее содержимое папки \bin\Debug\Images, и повторно скомпилируйте проект. Обновите окно Solution Explorer и удостоверьтесь в том, что данные в каталоге \bin\Debug\Images отсутствуют. При текущих параметрах сборки графические данные больше не копируются в выходную папку, а встраиваются в саму сборку. Прием обеспечивает наличие ресурсов, но также приводит к увеличению размера скомпилированной сборки.
Вам нужно модифицировать код для загрузки изображений в список, извлекая их из скомпилированной сборки:
// Извлечь из сборки и затем загрузить изображения.
_images.Add(new BitmapImage(new Uri(@"/Images/Deer.jpg", UriKind.Relative)));
_images.Add(new BitmapImage(new Uri(@"/Images/Dogs.jpg", UriKind.Relative)));
_images.Add(new BitmapImage(new Uri(@"/Images/Welcome.jpg", UriKind.Relative)));
В таком случае больше не придется определять путь установки и можно просто задавать ресурсы по именам, которые учитывают название исходного подкаталога. Также обратите внимание, что при создании объектов Uri указывается значение Relative перечисления UriKind. В данный момент исполняемая программа представляет собой автономную сущность, которая может быть запущена из любого местоположения на машине, т.к. все скомпилированные данные находятся внутри сборки.
При построении приложения WPF часто приходится определять большой объем разметки XAML для использования во многих местах окна или возможно во множестве окон либо проектов. Например, пусть создана "безупречная" кисть с линейным градиентом, определение которой в разметке занимает 10 строк. Теперь кисть необходимо применить в качестве фонового цвета для каждого элемента Button в проекте, состоящем из 8 окон, т.е. всего получается 16 элементов Button.
Худшее, что можно было бы предпринять — копировать и вставлять одну и ту же разметку XAML в каждый элемент управления Button. Очевидно, в итоге это могло бы стать настоящим кошмаром при сопровождении, т.к. всякий раз, когда нужно скорректировать внешний вид и поведение кисти, приходилось бы вносить изменения во многие места.
К счастью,
Взаимодействие с объектными ресурсами является крупной частью процесса разработки приложений WPF. Вы увидите, что объектные ресурсы могут быть намного сложнее, чем специальная кисть. Допускается определять анимацию на основе XAML, трехмерную визуализацию, специальный стиль элемента управления, шаблон данных, шаблон элемента управления и многое другое, и упаковывать каждую сущность в многократно используемый ресурс.
Как уже упоминалось, для применения в приложении объектные ресурсы должны быть помещены в подходящий объект словаря. Каждый производный от FrameworkElement класс поддерживает свойство Resources, которое инкапсулирует объект ResourceDictionary, содержащий определенные объектные ресурсы. Объект ResourceDictionary может хранить элементы любого типа,потому что оперирует экземплярами System.Object и допускает манипуляции из разметки XAML или процедурного кода.
