2つのこと。まず、期待されるパラメーターを渡していません。
protected void Page_Load(object sender, EventArgs e)
{
Bar.Text = "Updating Information";
InsertData(sender, e);
Bar.Text = "Information Updated";
}
protected void InsertData(object sender, EventArgs e)
{
//loops and statements
}
次に、これは ASP.NET Web フォームに似ています。コントロールの Text プロパティを変更しても、UI は更新されません。その理由を理解するには、実際に記述したコードの範囲外で実際に何が起こっているのかを理解する必要があります。ASP.NET WebForms には、非常に高度な「制御の反転」があります。あなたのコードは、IIS Web サーバーに常駐する ASP エンジンにサービスを提供するために存在し、いつ実行されるか (または存在するかさえも) を完全に制御することはほとんどありません。
これには 2 つの大きな影響があります。第 1 に、サーバーにページを要求する各クライアントに関してサーバーが保持する状態情報の量が非常に少ないことです。理想的には、状態は保存されません (ただし、現実的には、サーバーは通常、何らかの「セッション状態」を追跡する必要があります。特に、ログインが必要な保護された Web アプリの場合)。実際、コード ビハインド クラスは、ページをレンダリングするのに必要な期間だけ存続します。その後、クラス (およびメモリに格納しようとしていた状態データ) は破棄され、ガベージ コレクションが行われます。
2 つ目は、さらに重要なことですが、次の要求されたページをレンダリングするためにコード ビハインドで行われた処理は、クライアントのリアルタイムの更新にはなりません。Page_Load から Page_OnPreRender まで、分離コードでコードが行うことはすべて、結果の HTML の 1 ビットがクライアントに送り返される前に実行されます。つまり、コード ビハインド イベント ハンドラーの実行中にフォーム上のコントロールの値を数回変更しても、クライアントとの追加の通信を特に設定しない限り、クライアントが見る内容にはまったく影響しません。InsertData() を呼び出す前に Bar.Text を更新しても、クライアントに「情報を更新しています」というメッセージが表示されることはありません。クライアントに表示されるのは「更新された情報」だけです。これは、ページが最終的に HTML にレンダリングされた時点でのコントロールのテキストであるためです。すべてのイベント ハンドラが実行された後。
このような問題は通常、AJAX (Asynchronous Javascript And XML) などの非同期アーキテクチャで解決されます。ブラウザー ウィンドウでレンダリングされたページに対する JavaScript の制御レベルは、WinForms アプリケーションの制御レベルに匹敵します (クライアント側の JavaScript のみを使用して、UI として HTML を使用する単純なゲームをプログラミングするのに十分です)。また、JavaScript が送信に使用できるメソッドとオブジェクトがあります。サーバーへのデータのリクエスト。したがって、この挿入操作中にユーザーが表示するページの応答性を維持するには、これらのトリックを使用できます。ページ全体の完全なポストバックをトリガーする代わりに、Web サービス要求をサーバーに送信するクライアントで Javascript メソッドをトリガーし、Bar の値も更新するボタンをページに配置します。ステータス付きの UI コントロール テキスト "
余談ですが、実際には、この Javascript ベースの「サービス指向アーキテクチャ」を使用して、すべてのコンテンツ更新用の Web アプリケーション全体を作成することが可能です。この場合、最初の HTML ページが 1 つだけクライアント ブラウザに提供され、それ以降のすべての変更が行われます。ページのレイアウト、コンテンツ、および動作は、Web サービス呼び出しから受け取ったデータに基づいて 1 つのページの DOM を更新する JavaScript によって制御されます。このような Web サイトのアーキテクチャには欠点もありますが、いくつかの大きな利点もあります。