Где Application.DoEvents() в WPF?
У меня есть следующий пример кода, который масштабируется при каждом нажатии кнопки:
XAML:
<Window x:Class="WpfApplication12.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="MainWindow" Height="350" Width="525">
<Canvas x:Name="myCanvas">
<Canvas.LayoutTransform>
<ScaleTransform x:Name="myScaleTransform" />
</Canvas.LayoutTransform>
<Button Content="Button"
Name="myButton"
Canvas.Left="50"
Canvas.Top="50"
Click="myButton_Click" />
</Canvas>
</Window>
*. CS
public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
}
private void myButton_Click(object sender, RoutedEventArgs e)
{
Console.WriteLine("scale {0}, location: {1}",
myScaleTransform.ScaleX,
myCanvas.PointToScreen(GetMyByttonLocation()));
myScaleTransform.ScaleX =
myScaleTransform.ScaleY =
myScaleTransform.ScaleX + 1;
Console.WriteLine("scale {0}, location: {1}",
myScaleTransform.ScaleX,
myCanvas.PointToScreen(GetMyByttonLocation()));
}
private Point GetMyByttonLocation()
{
return new Point(
Canvas.GetLeft(myButton),
Canvas.GetTop(myButton));
}
}
вывод:
scale 1, location: 296;315
scale 2, location: 296;315
scale 2, location: 346;365
scale 3, location: 346;365
scale 3, location: 396;415
scale 4, location: 396;415
как вы можете видеть, есть проблема, которую я решил решить с помощью Application.DoEvents();
, но... она не существует априори в .NET 4.
Что делать?
Ответы
Ответ 1
Старый метод Application.DoEvents() устарел в WPF в пользу использования Dispatcher или Background Worker Thread, чтобы выполнить обработку, как вы описали. См. Ссылки для нескольких статей о том, как использовать оба объекта.
Если вы абсолютно должны использовать Application.DoEvents(), вы можете просто импортировать system.windows.forms.dll в свое приложение и вызвать метод. Однако это действительно не рекомендуется, поскольку вы теряете все преимущества, предоставляемые WPF.
Ответ 2
Попробуйте что-то вроде этого
public static void DoEvents()
{
Application.Current.Dispatcher.Invoke(DispatcherPriority.Background,
new Action(delegate { }));
}
Ответ 3
Ну, я просто ударил случай, когда начал работу над методом, который работает в потоке Dispatcher, и ему нужно блокировать, не блокируя поток пользовательского интерфейса. Оказывается, что msdn объясняет, как реализовать DoEvents() на основе самого Диспетчера:
public void DoEvents()
{
DispatcherFrame frame = new DispatcherFrame();
Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background,
new DispatcherOperationCallback(ExitFrame), frame);
Dispatcher.PushFrame(frame);
}
public object ExitFrame(object f)
{
((DispatcherFrame)f).Continue = false;
return null;
}
(взято из Dispatcher.PushFrame Method)
Ответ 4
myCanvas.UpdateLayout();
похоже, тоже работает.
Ответ 5
Одной из проблем с обоими предлагаемыми подходами является то, что они влекут за собой использование холостого процессора (до 12% в моем опыте). В некоторых случаях это неоптимально, например, когда модальное поведение пользовательского интерфейса реализовано с использованием этой методики.
Следующая вариация вводит минимальную задержку между кадрами с использованием таймера (обратите внимание, что она написана здесь с Rx, но может быть достигнута с помощью любого обычного таймера):
var minFrameDelay = Observable.Interval(TimeSpan.FromMilliseconds(50)).Take(1).Replay();
minFrameDelay.Connect();
// synchronously add a low-priority no-op to the Dispatcher queue
Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, new Action(() => minFrameDelay.Wait()));
Ответ 6
С введением async
и await
теперь можно отказаться от части потока пользовательского интерфейса через (ранее) * синхронный блок кода, используя Task.Delay
, например
private async void myButton_Click(object sender, RoutedEventArgs e)
{
Console.WriteLine("scale {0}, location: {1}",
myScaleTransform.ScaleX,
myCanvas.PointToScreen(GetMyByttonLocation()));
myScaleTransform.ScaleX =
myScaleTransform.ScaleY =
myScaleTransform.ScaleX + 1;
await Task.Delay(1); // In my experiments, 0 doesn't work. Also, I have noticed
// that I need to add as much as 100ms to allow the visual tree
// to complete its arrange cycle and for properties to get their
// final values (as opposed to NaN for widths etc.)
Console.WriteLine("scale {0}, location: {1}",
myScaleTransform.ScaleX,
myCanvas.PointToScreen(GetMyByttonLocation()));
}
Я буду честен, я не пробовал это с точным кодом выше, но я использую его в узких петлях, когда я помещаю много элементов в ItemsControl
, у которого есть дорогой шаблон, иногда добавляя небольшая задержка, чтобы дать другому материалу в пользовательском интерфейсе больше времени.
Например:
var levelOptions = new ObservableCollection<GameLevelChoiceItem>();
this.ViewModel[LevelOptionsViewModelKey] = levelOptions;
var syllabus = await this.LevelRepository.GetSyllabusAsync();
foreach (var level in syllabus.Levels)
{
foreach (var subLevel in level.SubLevels)
{
var abilities = new List<GamePlayingAbility>(100);
foreach (var g in subLevel.Games)
{
var gwa = await this.MetricsRepository.GetGamePlayingAbilityAsync(g.Value);
abilities.Add(gwa);
}
double PlayingScore = AssessmentMetricsProcessor.ComputePlayingLevelAbility(abilities);
levelOptions.Add(new GameLevelChoiceItem()
{
LevelAbilityMetric = PlayingScore,
AbilityCaption = PlayingScore.ToString(),
LevelCaption = subLevel.Name,
LevelDescriptor = level.Ordinal + "." + subLevel.Ordinal,
LevelLevels = subLevel.Games.Select(g => g.Value),
});
await Task.Delay(100);
}
}
В Windows Store, когда есть хороший переход темы в коллекцию, эффект весьма желателен.
Лука
- см. комментарии. Когда я быстро писал свой ответ, я думал о том, что вы делаете синхронный блок кода, а затем отбрасываете поток обратно своему вызывающему, эффект которого делает блок кода асинхронным. Я не хочу полностью перефразировать мой ответ, потому что тогда читатели не видят, что с Серви и я спорили.