Проблема с отображением локального изображения из XAML - PullRequest
Новая
       12

Проблема с отображением локального изображения из XAML

1 голос
/ 27 мая 2010

У меня ниже простой xaml: 

<Window x:Class="WpfApplication1.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
  <Grid>
    <Image Source="happyface.jpg"/>
  </Grid>
</Window>

happyface.jpg включен в проект, и его действие по сборке установлено в «Содержимое», а в «Копировать в Ouptput Directory» установлено «Копировать всегда».

При просмотре приложения через конструктор VS все в порядке, и я вижу изображение. Однако, когда я запускаю приложение, изображение не отображается. Я вижу, что изображение копируется в выходной каталог. Если в качестве источника указать полный путь (C: \ SANDBOX \ WpfApplication1 \ WpfApplication1 \ bin \ Debug "), он будет работать.

Есть идеи, почему изображение не отображается при запуске приложения? Я читал об URI пакетов, но подумал, что просто для ссылки на свободное изображение в текущем каталоге я могу просто использовать имя изображения.

Спасибо.



Edit:

Изображение для добавления находится в папке: C: \ WPF в C # \ SANDBOX \ WpfApplication1 \ WpfApplication1

Путь к файлу изображения в VS: C: \ WPF в C # \ SANDBOX \ WpfApplication1 \ WpfApplication1 \ happyface.jpg

Я создал проект через VS, установив каталог решения в "C: \ WPF в C # \ SANDBOX" и оставил проект по умолчанию и имя решения WpfApplication1. Я также установил флажок «Создать каталог для решения», поэтому теперь у меня есть следующая структура каталогов:

C: \ WPF в C # \ SANDBOX \ WpfApplication1 - содержит файл WpfApplication1.sln

C: \ WPF в C # \ SANDBOX \ WpfApplication1 \ WpfApplication1 - содержит WpfApplication1.csproj

jpeg находится в том же каталоге, что и WpfApplication1.csproj, и был добавлен в проект оттуда. Когда решение построено, выходной каталог C: \ WPF в C # \ SANDBOX \ WpfApplication1 \ WpfApplication1 \ bin \ Debug , и изображение копируется в этот каталог.



Редактировать # 2

Я попытался перенести свое приложение на 32-битную машину, и все работает как положено. Изображение отображается нормально. Когда я скомпилировал его на своем x64, я изменил целевой конфигурацию платформы в проекте на «x86». Я удивлен, что проблема возникает только при работе на 64-разрядной машине (XP 64). Есть идеи, почему это может быть так?



Редактировать # 3 - кажется, я нашел проблему

Я включил трассировку, чтобы поближе взглянуть на происходящее. Просто чтобы убедиться, что я не делал ничего сумасшедшего, я начал с нуля, не меняя ничего из стандартного проекта VS 2008, который был создан для меня, кроме добавления изображения в качестве контента и включения трассировки.

Я запустил приложение на своей машине x64 и запустил его. Ниже то, что я получил w.r.t. управление изображением: 

System.Windows.Markup Start: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.Markup Stop: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.RoutedEvent Start: 1 : Raise RoutedEvent; RoutedEvent='Image.ImageFailed'; RoutedEvent.HashCode='12289376'; RoutedEvent.Type='System.Windows.RoutedEvent'; Element='System.Windows.Controls.Image'; Element.HashCode='18796293'; Element.Type='System.Windows.Controls.Image'; RoutedEventArgs='System.Windows.ExceptionRoutedEventArgs'; RoutedEventArgs.HashCode='43495525'; RoutedEventArgs.Type='System.Windows.ExceptionRoutedEventArgs'; Handled='False'

System.Windows.RoutedEvent Stop: 1 : Raise RoutedEvent; RoutedEvent='Image.ImageFailed'; RoutedEvent.HashCode='12289376'; RoutedEvent.Type='System.Windows.RoutedEvent'; Element='System.Windows.Controls.Image'; Element.HashCode='18796293'; Element.Type='System.Windows.Controls.Image'; RoutedEventArgs='System.Windows.ExceptionRoutedEventArgs'; RoutedEventArgs.HashCode='43495525'; RoutedEventArgs.Type='System.Windows.ExceptionRoutedEventArgs'; Handled='False'

System.Windows.Markup Start: 16 : Type conversion failed, using fallback; TypeConverter='System.Windows.Media.ImageSourceConverter'; TypeConverter.HashCode='55915408'; TypeConverter.Type='System.Windows.Media.ImageSourceConverter'; String='happyface.jpg'; Value='<null>'

Как мы видим, преобразование изображения не удалось, так как значение для jpg было каким-то образом нулевым.

Я скопировал приложение прямо в папку Desktop на моем компьютере с архитектурой x86 и просто запустил его. Здесь это сработало, и мы видим разницу в следе: 

System.Windows.Markup Start: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.Markup Stop: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.Markup Start: 15 : Converted value; TypeConverter='System.Windows.Media.ImageSourceConverter'; TypeConverter.HashCode='12289376'; TypeConverter.Type='System.Windows.Media.ImageSourceConverter'; String='happyface.jpg'; Value='pack://application:,,,/ImageContentTest;component/happyface.jpg'; Value.HashCode='43495525'; Value.Type='System.Windows.Media.Imaging.BitmapFrameDecode'

Каким-то образом на компьютере с архитектурой x86 значение корректно установлено в 'pack: // application: ,,, / ImageContentTest; component / happyface.jpg';

У меня было приложение в папке x64 Desktop, которое я переместил ранее, и просто ради удовольствия запустил его оттуда. К моему удивлению, это сработало! Оказывается, виновником был # в пути к папке. С # там это не будет работать. С удаленным # он работает нормально. Это не имеет ничего общего с x64 против x86.

Я все еще не совсем уверен, почему # вызывает такое поведение. Я бы по крайней мере ожидал, что будет выдан какой-то тип ошибки, указывающий на неправильный путь или что-то в этом роде В любом случае, я думаю, что теперь я буду избегать # в путях:)

Спасибо всем, кто смотрел на это со мной.

Ответы [ 4 ]

0 голосов
/ 07 июня 2010

Я думаю, что нашел проблему

Я включил трассировку, чтобы поближе взглянуть на происходящее. Просто чтобы убедиться, что я не делал ничего сумасшедшего, я начал с нуля, не меняя ничего из стандартного проекта VS 2008, который был создан для меня, кроме добавления изображения в качестве контента и включения трассировки.

Я запустил приложение на своей машине x64 и запустил его. Ниже то, что я получил w.r.t. управление изображением: 

System.Windows.Markup Start: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.Markup Stop: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.RoutedEvent Start: 1 : Raise RoutedEvent; RoutedEvent='Image.ImageFailed'; RoutedEvent.HashCode='12289376'; RoutedEvent.Type='System.Windows.RoutedEvent'; Element='System.Windows.Controls.Image'; Element.HashCode='18796293'; Element.Type='System.Windows.Controls.Image'; RoutedEventArgs='System.Windows.ExceptionRoutedEventArgs'; RoutedEventArgs.HashCode='43495525'; RoutedEventArgs.Type='System.Windows.ExceptionRoutedEventArgs'; Handled='False'

System.Windows.RoutedEvent Stop: 1 : Raise RoutedEvent; RoutedEvent='Image.ImageFailed'; RoutedEvent.HashCode='12289376'; RoutedEvent.Type='System.Windows.RoutedEvent'; Element='System.Windows.Controls.Image'; Element.HashCode='18796293'; Element.Type='System.Windows.Controls.Image'; RoutedEventArgs='System.Windows.ExceptionRoutedEventArgs'; RoutedEventArgs.HashCode='43495525'; RoutedEventArgs.Type='System.Windows.ExceptionRoutedEventArgs'; Handled='False'

System.Windows.Markup Start: 16 : Type conversion failed, using fallback; TypeConverter='System.Windows.Media.ImageSourceConverter'; TypeConverter.HashCode='55915408'; TypeConverter.Type='System.Windows.Media.ImageSourceConverter'; String='happyface.jpg'; Value='<null>'

Как мы видим, преобразование изображения не удалось, так как значение для jpg было каким-то образом нулевым.

Я скопировал приложение прямо в папку Desktop на моем компьютере с архитектурой x86 и просто запустил его. Здесь это сработало, и мы видим разницу в следе: 

System.Windows.Markup Start: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.Markup Stop: 13 : Set property value; Object='System.Windows.Controls.Image'; Object.HashCode='18796293'; Object.Type='System.Windows.Controls.Image'; PropertyName='Name'; Value='_imageControl'

System.Windows.Markup Start: 15 : Converted value; TypeConverter='System.Windows.Media.ImageSourceConverter'; TypeConverter.HashCode='12289376'; TypeConverter.Type='System.Windows.Media.ImageSourceConverter'; String='happyface.jpg'; Value='pack://application:,,,/ImageContentTest;component/happyface.jpg'; Value.HashCode='43495525'; Value.Type='System.Windows.Media.Imaging.BitmapFrameDecode'

Каким-то образом на компьютере с архитектурой x86 значение корректно установлено в 'pack: // application: ,,, / ImageContentTest; component / happyface.jpg';

У меня было приложение в папке x64 Desktop, которое я не перемещал ранее, и просто ради удовольствия запустило его оттуда. К моему удивлению, это сработало! Оказывается, виновником был # в пути к папке. С # там это не будет работать. С удаленным # он работает нормально. Это не имеет ничего общего с x64 против x86.

Я все еще не совсем уверен, почему # вызывает такое поведение. Я бы по крайней мере ожидал, что будет выдан какой-то тип ошибки, указывающий на неправильный путь или что-то в этом роде В любом случае, я думаю, что теперь я буду избегать # в путях:)

Спасибо всем, кто посмотрел на это с

0 голосов
/ 27 мая 2010

не могли бы вы убедиться в паре вещей, пожалуйста?

добавляемое изображение находится в папке "[DIR LOCATION] \ Projects \ WpfApplication1 \ Window1" и путь к файлу изображения в VS "[DIR LOCATION] \ Projects \ WpfApplication1 \ Window1 \ happyface.jpg

замените [DIR LOCATION] на правильное местоположение.

0 голосов
/ 27 мая 2010

Я создал решение, как вы описали, и у меня не было проблем ни с запуском решения внутри VS, ни с запуском * .exe.

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

Я сделал это, внеся следующие изменения в файл * .xaml: 

        <Image x:Name="displayImage" Source="have_the_dumb.jpg" />

Затем в файле * .xaml.cs я добавил новый TraceListener, чтобы увидеть, что говорит автономный * .exe. Мой конструктор выглядит так: 

    public ImageDisplay()
    {
        Trace.Listeners.Add(new TextWriterTraceListener(@"c:\happyface.trace.log"));
        Trace.AutoFlush = true;

        InitializeComponent();

        Trace.WriteLine(String.Format("Image thinks it's in {0}", displayImage.Source.ToString()));
    }

Возможно, вам придется добавить «использование System.Diagnostics», чтобы это работало. Затем запустите ваше решение и посмотрите, что содержит файл трассировки. По крайней мере, вы будете знать, ищет ли элемент управления нужное место для изображения.

0 голосов
/ 27 мая 2010

Не беспокойтесь о копировании, но установите для его действия сборки Resource. Вам необходимо установить URI для изображения, чтобы быть действительным URI пакета. Дизайнер должен помочь вам сделать это, но если это не так, он должен быть в следующем формате:

/ [имя сборки]; компонент [путь в проекте]

Например: /MyAssemblyName;component/Resources/image.png

где сборка "MyAssemblyName.dll", а образ находится в каталоге ресурсов в решении.

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

Нет похожих вопросов

...