ASP.NET WebForms - Anzeigen eines Lade-Balkens während eines Requests

Hi,

Windows Forms:

protected async void Button1_Click(object sender, EventArgs e)
{
	Label1.Text = "Hard at work!";
	await Task.Delay(5000);
	Label1.Text = "Finished";
}

Web-Site:

protected void Button1_Click(object sender, EventArgs e)
{
	Label1.Text = "Hard at work!";
	Thread.Sleep(5000);
	Label1.Text = ("Finished!");
}

In der Meldungsschleife einer Windows Forms-Anwendung liefert mir die Methode Button1_Click das gewünschte Ergebnis, aber innerhalb des Lebenszyklus einer Webseite nicht. Die Schaltfläche löst zwar bei jedem Klick ihr Event aus, jedoch ist erst nach dem PostBack eine Meldung im Browser zu lesen. "Hard at work" wird somit niemals angezeigt. Wie ist es denn möglich, dem Benutzer mitzuteilen, dass eine Serveranfrage läuft? Sehr schön wäre auch, wenn während der Serveranfrage ein "Lade"-Popup (wahrscheinlich mit Skript-Sprache) erscheinen würde, sodass der Benutzer gar nicht mehr die Schaltfläche bedienen kann, da die Seite ja im "Hintergrund" liegt.

Vielen Dank für eure Hilfe.

Dir ist bewusst, dass Webprogrammierung völlig anders ist als die auf einem Desktop? Du vergleichst hier Äpfel mit Birnen.

Webanwendungen funktionieren so, dass man dem Server eine Anfrage stellt und der Server reagiert mit einer Antwort.
Thread.Sleep funktioniert bei Webanwendungen so nicht.

Und zudem solltest Du wissen, dass WebForms (das nutzt Du) tot ist.
Die neue ASP.NET Version kennt nur noch MVC.

Du setzt hier auf eine veraltete und bereits ausrangierte Technologie.

Hier fehlen definitiv Grundlagen, die weit weit vor ASP.NET liegen.
Du solltest erstmal die absoluten Grundzüge verstehen, wozu zB das Protokoll gehört. Wenn Du das verstehst, dann weißt Du, warum das hier nicht funktioniert und erst dann kann man eigentlich mit einer Webtechnologie beginnen.

Vielen Dank für deine Antwort,

mir ist sehr wohl bewusst, dass sich die Web- von der Desktopentwicklung unterscheidet und es ist offensichtlich, dass mir die Grundlagen der Web-Entwicklung in ASP.NET fehlen.

Aber genau genommen werden doch auf dem Server die gleichen Arbeiten verrichtet, wie in einer Desktopanwendung: Datenzugriffe und Geschäftslogik.

Der Unterschied ist doch lediglich, dass nun der Client den Server mit der Ausführung dieser Arbeiten beauftragt und das Ergebnis zurückverlangt. Aber genau da liegt mein Problem. Ich verstehe die Steuerung von Anfrage und Erhalt nicht. Ich weiß nicht, wie ich dem Client sage, dass er keine weiteren Anfragen an den Server senden darf, solange der Server nicht die aktuelle Anfrage beantwortet hat.

Thread.Sleep() sollte auch nur eine zeitintensive Aufgabe simulieren und nicht etwa eine bewusste Pausierung darstellen.

Viele Grüße

Abt's Beitrag erklärt dein Problem schon sehr genau.

Der Unterschied zwischen der Webseite und einer Desktop Applikation ist wenn du es so willst nur das Protokoll, dass zwischen Visualisierung (Browser oder Desktopfenster) und Hintergrundprogramm gesprochen wird.
Bei HTTP gibt es zu einer Anfrage nur eine Antwort. Weitere parallel Anfragen sind jederzeit möglich (was aber auch für ein Desktopprogramm zutrifft, wenn man es dort nicht programmatisch verbietet).

Streng genommen werden eben nicht die gleichen Aufgaben verrichtet. Es funktioniert annähernd nichts so wie auf dem Desktop.

Es ist leichter als Webentwickler auf den Desktop zu schwenken als umgekehrt.
Vor allem aus Windows Forms-Sicht wird man es viel schwerer haben, als wenn man zuvor im WPF-Bereich Zuhause war.
Webanwendungen funktionieren Request-basierend, während Forms auf Event basiert.

Ein Webserver bzw. die Webanwendung die darauf läuft kennt keine Oberfläche. Das einzige, was die Webanwendung macht ist ein HTML-Return zu generieren.
Dieses ist fix. Es ist eben diese eine Antwort.

Der Browser macht nun aus dieser einen Antwort und mit Hilfe des HTML-Returns eine Oberfläche - die Anwendung, die Du siehst.
Da es aber zwischen Server und Client nach dieser einen Antwort absolut keine Verbindung mehr gibt (so funktioniert eben das Protokoll) kann diese HTML-Antwort auch nicht mehr verändert werden.

Was Du brauchst ist nun ein zusätzlicher Kanal, über den der Client über Änderungen informiert wird: sowas wird über sogenannte WebSockets gelöst, zB. SignalR.
Zusätzlich brauchst Du JavaScript, das im Browser diese Information entgegennehmen und die aktuelle Ansicht (DOM) manipulieren kannst.

Aber um ehrlich zu sein; Dein aktueller Wissensstand ist so gering, dass das sehr sehr viel auf einmal ist. Keine Frage, Du wirst das hin kriegen; aber Du musst mit den Grundlagen beginnen, sonst legst Du Dir jetzt schon riesen Steine in den Weg und wirst viele Vorgänge nicht verstehen.
Webanwendungen funktionieren völlig anders als Desktopanwendungen. Du musst nicht nur anders programmieren, sondern auch völlig, viel abstrakter denken und handel.

Der Hauptunterschied ist: die Desktopanwendung weiß immer in welchen Zustand sie sich befindet, Webanwendung auf dem Webserver - aufgrund von Kommunikation über das zustandlose Protokoll HTTP - dagegen nicht, d.h. der Request von Client an einer Webanwendung muss dem Server sagen, in welchem Zustand er sich versetzen soll, um den Request verarbeiten zu können.

Hi,

und wieder vielen Dank für die Antworten.

Streng genommen werden eben nicht die gleichen Aufgaben verrichtet. Es funktioniert annähernd nichts so wie auf dem Desktop.

Ich vergleiche nicht die Desktop-Anwendung mit der Webanwendung auf dem Server, sondern vielmehr das, was von beiden benutzt wird. Ich spreche von meinen Klassen und Bibliotheken für Datenzugriffe und Programmlogik. Die kann ich in beiden Welten unverändert verwenden.

Ich werde von euch dargestellt, als hätte ich generell keine Ahnung von Softwareentwicklung und müsse nun endlich mal lernen, abstrakt zu denken. Das empfinde ich als Beleidigung. Eine Anwendung - egal ob Desktop oder Client/Server - lebt durch ihre Programmlogik. Die Verarbeitung der Programmlogik lässt die Anwendung ihren Zweck erfüllen.

Aber ihr habt recht, mit Web-Entwicklung kenne ich mich nicht aus und muss deren Grundlagen studieren. Aber dennoch glaube ich, dass mein abstraktes Denken gut funktioniert.

Viele Grüße

Aber ihr habt recht, mit Web-Entwicklung kenne ich mich nicht aus und muss deren Grundlagen studieren. Aber dennoch glaube ich, dass mein abstraktes Denken gut funktioniert.

Kein Grund, eingeschnappt zu sein. HTTP ist zustandslos. Mach dir klar, was das für einen Programmablauf bedeutet. HTTP ist auch verbindungslos. Und auch das hat Konsequenzen. Beide Eigenschaften zusammen bedeuten, wie mehrfach gesagt wurde, dass die Abläufe bei einer Webapplikation grundlegend verschieden sind von denen in einem "fat" client.

Das hat mit den Klassen für die Programmlogik selbst wenig zu tun, sondern mit den Programmabläufen. Und das, so scheint es, ist bei dir noch nicht angekommen 😃.

LaTino

Ich spreche von meinen Klassen und Bibliotheken für Datenzugriffe und Programmlogik. Die kann ich in beiden Welten unverändert verwenden.

Datenzugriffe stimmt zum Teil, wobei das auch nur auf den Zugriff eines Eintrags selbst trifft.
Bei Webabwendungen hast Du ab den ersten Moment mit einer Multi-Threading-Anwendung zutun - bei Desktop nicht. Du weißt nie, ob der Benutzer die nächste Seite wirklich aufruft - bei Desktop kannst Du davon ausgehen oder Abbruchevents erkennen; bei Webanwendungen nicht. Du bekommst nicht mit, wenn der Benutzer das Fenster schließt.
Das schlägt sich massiv auf die Umsetzung eines DALs nieder; Du kannst zB. nichts, also absolut gar nichts unbewusst im Speicher lassen - null. Auf die Logik der Anwendung sowieso.

Sobald Workflows dazu kommen, kannst Du das i.d.R. nicht.
Eine Webanwendung kann bei der Ausführung zB. nicht auf Informationen warten, wie es oft bei Desktops der Fall ist.
Gerade die Umsetzung der Logik bzw. des Ablaufs der Logik ist ein Punkt bei Webanwendungen, der viel abstrakter umgesetzt sein muss.
Zudem kann der Benutzer jederzeit eine andere URL aufrufen und Dein Workflow so untergraben, was bei einer Desktopanwendung ebenfalls nicht funktioniert.

Ich stelle Dich auch nicht dar, dass Du es nicht könntest; aber Deine Annahmen im Startbeitrag sind eben - sorry - naiv.
So funktioniert das einfach nicht. Ansonsten hat LaTino es im letzten Satz perfekt auf den Punkt gebracht.
Du hast zudem in der Web-Welt mit sehr viel mehr Technologien zutun (HTML, CSS, JavaScript /(TypeScript), HTTP, WebSockets) und dazu mit einer hohen Zahl an Frameworks (jQuery, AngularJS, ASP.NET, SignalR...) die sich auch noch viel viel viel schneller weiterentwickeln als alles, was Du auf dem Desktop kennst und je haben wirst.

Das Web ist eine völlig andere Entwicklungswelt. Das muss Dir einfach bewusst sein.
Ja, wir sind alles Entwickler (=Handwerker). Aber um bei der Assoziation zu bleiben ist ein Metzger und ein Maurer halt auch beides Handwerker; aber agieren trotzdem in zwei völlig verschiedenen Welten.

Hi,

Kein Grund, eingeschnappt zu sein.

Kleine Kinder sind eingeschnappt 😛 Die Notwendigkeit der alternativen Betrachtungsweise der Programmabläufe ist auch angekommen und zwar bereits beim Erstellen des Themas, wie mein Titel ja verrät 😃 Aber ich nahm an, es gäbe einfache Methoden, diese Programmabläufe zu steuern.

LG;-)

Aber ich nahm an, es gäbe einfache Methoden, diese Programmabläufe zu steuern.

Das ist ein Vorwurf, den man Webforms machen muss. Man hatte sich damals dafür entschieden, durch Benennung und Schnittstellenwahl dem Entwickler vorzumachen, dass Webforms und Winforms quasi ein und dasselbe seien und sich auch exakt gleich verhielten. Insofern bist du an der Stelle den Architekten von Webforms auf den Leim gegangen. (Nicht als erster, nicht als einziger. Glaube, wir sind alle froh, dass diese Technologie verworfen wurde.)

Das hat sich als ziemliche Sackgasse erwiesen und die Entwicklung mit Webforms zu einem wahnsinnigen K(r)ampf gemacht.

In deinem Beispiel oben kommt vom Client die Information darüber, dass der Button gedrückt wurde, und mit dieser Information macht der Server etwas und gibt dann eben das Ergebnis der Methode zurück - ob er die Methode im Hintergrund ausführt oder nicht, ist völlig egal. Er hat zu keiner Zeit Zugriff auf Elemente der UI, so wie das der WinForms-Schnipsel darüber hat. Hintergrundoperationen für eine Webapplikation muss der Client implementieren, und bei Client reden wir von HTML, Javascript, und CSS. Also etwas, das der Browser darstellen kann. Und die Kommunikation zwischen diesem Client und dem (Web)Server besteht ausschließlich aus atomaren, unabhängigen, isolierten Anfragen. Schwierig, Logik aus einem WinForms-Codebehind da irgendwie zu verwenden, denn dort kennt der "Server" (besser gesagt, der Code-Behind) jederzeit den Zustand aller Elemente der UI. Bei WebForms weiß der Codebehind nicht einmal, welche Elemente die UI hat.

Kurz gesagt, Dinge wie Fortschrittsanzeigen und Hintergrundoperationen muss man in der Webwelt im Client verwirklichen, und das läuft darauf hinaus, sie in HTML zu implementieren. Gibt reichlich Frameworks, die sich der Vereinfachung dieser Geschichten widmen. Nicht jedoch im Zusammenspiel mit ASP.NET WebForms.

LaTino

Hallo,

wenn Du wirklich bei WebForms bleiben willst (und bedenke dabei unbedingt, was Abt bereits geschrieben hat: das ist veraltete Technologie), dann kannst Du auch vollständig dabei bleiben und statt den von Abt erwähnten Möglichkeiten

sowas wird über sogenannte WebSockets gelöst, zB. SignalR.

es mit einem <asp:UpdatePanel> in Verbindung mit einem <asp:Timer> versuchen. So hätte man es zu WebForm-Glanzzeiten gemacht. (das UpdatePanel spielt im Hintergrund auch nur Ajax).

Gruß, MarsStein

Vielen Dank,

ich werde mich in MVC einarbeiten:-)