Dov'è Application.DoEvents () in WPF?

Ho il seguente codice di esempio che ingrandisce ogni volta che viene premuto un pulsante:

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));
    }
}

l'output è:

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

come puoi vedere c'è un problema che pensavo risolvere usando Application.DoEvents();ma ... non esiste a priori in .NET 4.

Cosa fare?

Il vecchio metodo Application.DoEvents () è stato deprecato in WPF a favore dell'utilizzo di un Dispatcher o di un thread di lavoro in background per eseguire l'elaborazione come descritto. Vedere i collegamenti per un paio di articoli su come utilizzare entrambi gli oggetti.

Se è assolutamente necessario utilizzare Application.DoEvents (), è possibile importare semplicemente system.windows.forms.dll nella propria applicazione e chiamare il metodo. Tuttavia, questo in realtà non è consigliato, poiché stai perdendo tutti i vantaggi offerti da WPF.

Prova qualcosa di simile

public static void DoEvents()
{
    Application.Current.Dispatcher.Invoke(DispatcherPriority.Background,
                                          new Action(delegate { }));
}

Bene, ho appena raggiunto un caso in cui inizio a lavorare su un metodo che viene eseguito sul thread Dispatcher e deve essere bloccato senza bloccare il thread dell'interfaccia utente. Si scopre che msdn spiega come implementare un DoEvents () basato sul Dispatcher stesso:

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;
}

(tratto dal metodo Dispatcher.PushFrame )

Alcuni potrebbero preferirlo in un unico metodo che applicherà la stessa logica:

public static void DoEvents()
{
    var frame = new DispatcherFrame();
    Dispatcher.CurrentDispatcher.BeginInvoke(DispatcherPriority.Background,
        new DispatcherOperationCallback(
            delegate (object f)
            {
                ((DispatcherFrame)f).Continue = false;
                return null;
            }),frame);
    Dispatcher.PushFrame(frame);
}

Se hai bisogno di aggiornare solo la grafica della finestra, meglio usarla in questo modo

public static void DoEvents()
{
    Application.Current.Dispatcher.Invoke(DispatcherPriority.Render,
                                          new Action(delegate { }));
}

myCanvas.UpdateLayout();

sembra funzionare pure.

Un problema con entrambi gli approcci proposti è che comportano un utilizzo inattivo della CPU (fino al 12% nella mia esperienza). Ciò non è ottimale in alcuni casi, ad esempio quando il comportamento dell'interfaccia utente modale viene implementato utilizzando questa tecnica.

La seguente variazione introduce un ritardo minimo tra i fotogrammi utilizzando un timer (si noti che è scritto qui con Rx ma può essere ottenuto con qualsiasi timer normale):

 var minFrameDelay = Observable.Interval(TimeSpan.FromMilliseconds(50)).Take(1).Replay();
 minFrameDelay.Connect();
 // synchronously add a low-priority no-op to the Dispatcher's queue
 Application.Current.Dispatcher.Invoke(DispatcherPriority.Background, new Action(() => minFrameDelay.Wait()));

Dall'introduzione di asynced è awaitora possibile abbandonare il thread dell'interfaccia utente in parte attraverso un blocco di codice sincrono (precedentemente) * utilizzando Task.Delay, ad es.

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()));
}

Sarò onesto, non l'ho provato con il codice esatto sopra, ma lo uso in loop stretti quando inserisco molti elementi in un ItemsControlmodello di oggetto costoso, a volte aggiungendo un piccolo ritardo per dare l'altro cose sull'interfaccia utente più tempo.

Per esempio:

        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);
            }
        }

Su Windows Store, quando c'è una bella transizione del tema nella raccolta, l'effetto è abbastanza desiderabile.

Luca

• vedere i commenti. Quando stavo scrivendo rapidamente la mia risposta, stavo pensando all'atto di prendere un blocco di codice sincrono e poi restituire il thread al suo chiamante, il cui effetto rende asincrono il blocco di codice. Non voglio riformulare completamente la mia risposta perché così i lettori non possono vedere su cosa stessimo litigando io e Servy.

Crea il tuo DoEvent () in WPF:

Thread t = new Thread(() => {
            // do some thing in thread
            
            for (var i = 0; i < 500; i++)
            {
                Thread.Sleep(10); // in thread

                // call owner thread
                this.Dispatcher.Invoke(() => {
                    MediaItem uc = new MediaItem();
                    wpnList.Children.Add(uc);
                });
            }
            

        });
        t.TrySetApartmentState(ApartmentState.STA); //for using Clipboard in Threading
        t.Start();

Funziona bene per me!

Rispondendo alla domanda originale: dov'è DoEvents?

Penso che DoEvents sia VBA. E VBA non sembra avere una funzione Sleep. Ma VBA ha un modo per ottenere esattamente lo stesso effetto di sospensione o ritardo. Mi sembra che DoEvents sia equivalente a Sleep (0).

In VB e C #, hai a che fare con .NET. E la domanda originale è una domanda C #. In C #, useresti Thread.Sleep (0), dove 0 è 0 millisecondi.

Hai bisogno

using System.Threading.Task;

all'inizio del file per poter utilizzare

Sleep(100);

nel codice.