Folgender Code ist mit dem neuen Async Framework geschrieben.

Kompiliert wunderbar.

Erwartung:

Meine Anwendung besteht aus einer Textbox und einem Button, welcher nach "onclick" die Webseite Googles lädt und das Result in der Textbox darstellt.

Das geschieht auch.

Aber - und da liegt der Hase im Pfeffer:

geschieht der Aufruf wider erwarten nicht asynchron/nonblocking, sondern die GUI hängt und wartet brav, bis Google geantwortet hat.

namespace AsyncTest

{

    /// <summary>

    /// Interaktionslogik für MainWindow.xaml

    /// </summary>

    public partial class MainWindow : Window

    {

        public MainWindow()

        {

            InitializeComponent();

        }


        public async Task GetGoogle()

        {

            WebClient webclient = new WebClient();

            textBox1.Text=await webclient.DownloadStringTaskAsync(new Uri("http://www.google.de"));


        }


        async void WaitForTextAndFillTextbox()

        {

            await GetGoogle();

        }


        private void button1_Click(object sender, RoutedEventArgs e)

        {

            WaitForTextAndFillTextbox();

        }

    }

}

[/php]

Hat jemand eine Idee, warum es nicht so funktioniert, wie erwartet?

Irgendwie stehe ich auf dem Schlauch.

Danke :]

hmm ich hab mich damit noch nicht auseinander gesetzt, sieht auf jeden Fall sehr interessant aus.

Aber vielleicht hat der da irgendwie ein Problem weil du das direkt der TextBox zuweist und klappt dann so:

string text = await webclient.DownloadStringTaskAsync(new Uri("http://www.google.de"));

textBox1.Text=text;

[/PHP]

Ist aber nur ein Schuss ins Blaue und wirklich vorstellen kann ichs mir auch nicht...

wenn text erstmal gesetzt ist, ists nur ne reine Assign Operation, da dürfte die GUI nicht blockieren, da würde ich den Fehler schon woanders vermuten ;-)

Das kommt drauf an wie der Compiler die Zeile

textBox1.Text=await webclient.DownloadStringTaskAsync(new Uri("http://www.google.de"));

[/PHP]

intern genau umbaut damit das plötzlich ansynchron ist.

du meinst lazy loading könnte bremsen?

Keine Ahnung wie du jetzt auf Lazy Loading kommst...

namespace AsyncTest

{

    /// <summary>

    /// Interaktionslogik für MainWindow.xaml

    /// </summary>

    public partial class MainWindow : Window

    {

        WebClient webclient = new WebClient();

        public MainWindow()

        {

            InitializeComponent();

        }


        private async void button1_Click(object sender, RoutedEventArgs e)

        {

            string result = await webclient.DownloadStringTaskAsync(textBox2.Text);

            textBox1.Text = result;

        }

    }

}

[/php]

Ich habe es auf das folgende runtergebrochen.

TextBox2 dient quasi als Addressleiste und Textbox1 als Ausgabe.

Starte ich den Aufruf zum ersten mal, blockiert der Aufruf (noch);

ab da an habe ich das Gefühl, dass das Ganze nonblocking läuft ... sehr komisch.

Das kommt drauf an wie der Compiler die Zeile intern genau umbaut damit das plötzlich ansynchron ist.

Eben. Da liegt nämlich der Clou an der ganzen Geschichte:

Es handelt sich um Syntactic Sugar, der einem das ganze Backgroundworker/Thread starten wasauchimmer erleichtern soll.

Lazy Loading trifft es nicht.

Eduasync part 6: using the infrastructure manually - Jon Skeet: Coding Blog <- liefert einen Hinweis, wie der Compiler vorgehen könnte - quasi "re-engineering" (statt "reverse engineering").

Aber merkwürdig ist das Verhalten meiner Anwendung schon.

ich habs grade nachgebaut, ich habe dasselbe Phänomen ...

Hm.

Dann liegt es zumindest nicht an mir *LOL*