WPF, използване на ресурси

Опаковани URI

WPF ви позволява достъп до компилирани ресурси (като BAML файл за страница), като използвате синтаксисаопаковани URI (pack URI). В предишната статия елементът Image и маркерът за ресурс използваха относителен URI:

По-тромавият абсолютен URI еквивалент е показан по-долу:

Такъв абсолютен URI може да се използва при задаване на източника на изображение, въпреки че не предоставя никаква допълнителна полза.

Синтаксисът на пакетирания URI е заимстван от стандарта XPS (XML Paper Specification). Причината за странния му вид е, че включва вмъкване на един URI в друг. Трите запетаи всъщност са три екранирани наклонени черти. С други думи, показаният по-горе URI в кутия съдържа URI на приложение, започващ с конструкцията application://.

Ресурси в други сборки

Опакованите URI също ви позволяват да извличате ресурси, които са в друга библиотека (с други думи, DLL сборката, която вашето приложение използва). В такъв случай трябва да се използва следният синтаксис:

Например, ако изображението е в рефериран сборник, наречен ImageLibrary, ще трябва да използвате следния URI:

Ако използвате сборка със сложно име, можете да замените името на сборка с квалифицирана препратка към сборка, която включва версията, маркера на публичния ключ или и двете. Разделете всяка част от информацията с точка и запетая и добавете v преди номера на версията. По-долу е показан пример:

Файлове със съдържание

Когато добавяте файл като ресурс, трябва да го поставите в компилиран сбор и да се уверите, че винаги е наличен. Този подход е идеален заразгръщане и отстраняване на възможни проблеми. В някои ситуации обаче е непрактично, а именно:

по избор да модифицирате ресурсния файл без повторно компилиране на приложението;

когато файлът с ресурси е много голям;

когато ресурсният файл не е задължителен и може да не бъде внедрен с компилацията;

когато ресурсът е аудио файл.

Звуковите класове на WPF не поддържат ресурси за асемблиране. Поради тази причина няма начин да извлечете аудио файл от поток от ресурси и да го възпроизведете - поне не и без първо да го запазите. Това е ограничение на основните технологични компоненти, на които се основават тези класове (а именно Win32 API и Media Player).

Очевидно можете да заобиколите този проблем, като разположите файловете с приложението и добавите подходящия код към приложението, за да прочете тези файлове от твърдия диск. WPF обаче има удобна опция, която може да направи този процес по-лесен и това е специално да маркира такива некомпилирани файлове като файлове със съдържание.

Файловете със съдържание не са вградени в сборката. WPF обаче добавя атрибутAssemblyAssociatedContentFile към сборката, който декларира съществуването на всеки файл със съдържание. Този атрибут също така записва информация за местоположението на всеки файл със съдържание спрямо изпълнимия файл (показва дали файлът със съдържание е в същата папка като изпълнимия файл или в отделна подпапка). Най-доброто от всичко е, че можете да използвате една и съща URI система, за да използвате файлове със съдържание с елементи, съобразени с ресурсите.

За да тествате това, добавете някакъв звуков файл към вашия проект, изберете го в прозореца Solution Explorer ипроменете стойността на свойството Build Action в прозореца Properties на Content. Уверете се, че Copy to Output Directory е зададено на Copy Always, така че звуковият файл да се копира в изходната директория, когато проектът бъде изграден.

Вече можете да използвате относителен URI, за да насочите MediaElement към вашия файл със съдържание:

---