C＃aspx

ASP.ButtonUseSubmitBehaviorプロパティ



Asp Button Usesubmitbehavior Property



ボタンサーバーの頻繁な操作の問題を解決するため。ボタンのUseSubmitBehaviorプロパティに注意してください。それほど大きな問題ではありませんが、よくわかりません。喉が渇いたような気がするので、詳しく調べてみました。

基本的なポイント：
①
UseSubmitBehavior属性は、ボタンの送信フォームを制御するために使用されます。 falseに設定すると、クライアントスクリプトはASP.NETページフレームワークを使用してページに追加されます。 trueに設定し（属性のデフォルトはtrue）、クライアントブラウザーの送信メカニズムを使用します。
②ASP.Buttonボタン、OnClientClickでページJSイベントを登録し、OnClickでサーバー側イベントを登録します。最初にOnClientClickを実行してから、OnClickを実行します。また、OnClientClickでfalseを返すことにより、サーバー側イベントOnClickの実行を防ぐことができます。



例

Client page: Server backend: protected void Button1_Click(object sender, System.EventArgs e) { System.Threading.Thread.Sleep(2000) Response.Write('button1') }

例1：他の処理はありません（UseSubmitBehavior属性のデフォルトはtrueです）



Run the source code:

例2：UseSubmitBehaviorプロパティをfalseに設定する

Run the source code:

ソースコードを実行すると、属性UseSubmitBehaviorがtrueの場合、ボタンタイプはsubmitであることがわかります。これは、falseの場合のクライアントブラウザーの送信モードです。ボタンの種類はbuttonで、サーバーイベントのonclickイベントにjsコード__doPostBack（xx）が追加されます。つまり、ASP.NETページフレームワークがクラ​​イアントスクリプトをページモードに追加します。
実行中のソースコードのonclickは、ASPコードのonclickとは異なることに注意してください。 ASPコードのonclickは、サーバーイベントの登録に使用されます。これは、サーバーイベントButton1_ClickがASPコードのonclickを介して登録されているためです。したがって、例1、例2では、​​UseSubmitBehaviorがどのように変更されても、サーバー側をトリガーできます。イベントとページのボタン1を返します。

例3：頻繁な操作を防ぐ



Client: function BtSubmit(button) { button.value = 'Submitting' button.disabled = true }

上記は、頻繁な操作を防ぐために私が見る最も一般的な形式の1つです。多くの説明で、UseSubmitBehaviorはデフォルトでtrueに設定され、クライアント送信の形式を使用するため、サーバーイベントの送信が防止されると述べられています。その結果、サーバーイベントをトリガーできません。したがって、falseに設定する必要があります。
私の混乱のほとんどはこれによるものでもあります。なぜなら、ボタンを無効にしなくなったときに、他の処理に置き換えるからです。 UseSubmitBehaviorがtrueに設定されている場合でも、サーバーイベントをトリガーできます。したがって、サーバー側のイベントをブロックするのはUseSubmitBehaviorではなくbutton.disabledであると確信しています。
このコードの実際の効果は、ASP.Buttonボタンのonclickにサーバーの送信が含まれることですが、頻繁な操作の問題を防ぐために、ボタンを初めてクリックしたときはページjsの段階にあります。何度もクリックされると（今回も含む）、サーバーイベントをトリガーするこのボタンに含まれるコードは実行されなくなります。このとき、UseSubmitBehavior = false属性を使用して、ASP.NETページフレームワークを使用してクライアントスクリプトをページのフォームに追加し、ボタンをトリガーしてサーバーイベントを初めてクリックします。

例4：よくある間違い

Error① Page: …… Run the source code: Or Page: …… Run the source code: Error② Page: function BtSubmit(button) { button.value = 'Submitting' return false }

エラー①は、useSubmitBehavior = 'false'およびreturnfalseがonclientclickの最後に追加されているためです。いくつかの説明によると、最終的な戻り値がfalseであるため、サーバーが実行されませんでした。しかし実際には、たとえreurntrueであっても実行されません。 UseSubmitBehavior = 'false'を設定すると、onclickの最後に__doPostBack（ ‘Button1’、 ’’）が追加され、サーバーイベントがトリガーされるためです。エラー①最初にリターンを書き込むと、次のコードが実行できません。
エラー②は小さなエラーです。 UseSubmitBehavior =“ true”の場合、サーバーイベントがonclientclikckの戻り値によってトリガーされるかどうかを制御できますが、returnを追加する必要があります。エラー②など、多くの場合、関数でfalseを返すだけでは不十分です。 OnClientClick = 'return BtSubmit（this）'やOnClientClick = '' BtSubmit（this）return true | false 'のように、onclientclickで正しい表現を返す必要があります。
エラー①②は比較的類似しており、エラー②を正しく書き込むとエラー①が発生しやすくなります。混乱しやすいのでまとめました。

例5：サーバー登録

Client page: function BtSubmit(button) { button.value = 'Submitting' return false } Server background file: Button1.Attributes.Add('onclick', 'this.value='committing, please wait...' this.disabled=true' + this.GetPostBackEventReference(Button1)) Or Button1.Attributes.Add('onclick', 'this.value='committing, please wait...' this.disabled=true' + Page.ClientScript.GetPostBackEventReference(Button1, '')) The client runs the source code:

ASP.NETでバックグラウンドからフロントエンドプロパティを登録する方法。フロントエンドに直接書き込むのと同じです。注目に値する2つのポイント。
1.サーバーコードに登録されているonclickメソッドは、実際にはフロントエンドコントロールのOnClientClickのプロパティです。実行中のソースコードから見えるように、コントロールOnClientClickで直接記述されたコードが前面にあり、サーバーのバックグラウンドで登録されたコードが続き、最後にUseSubmitBehavior =“ false”が自動的に追加されます__doPostBack（ 'Button1'、 ''） '。したがって、OnClientClickに戻りがあり、次のコードが実行されない場合。
2. this.GetPostBackEventReferenceメソッドを使用すると、無効であることが示されますが、使用には影響しません。別の方法は、次のPage.ClientScript.GetPostBackEventReferenceです。

UseSubmitBehavior属性について私が理解しているのはこれだけです。多くの場所が憶測ですが、間違いがあれば訂正を手伝ってください、ありがとうございます。
ps：実際、頻繁な操作を防ぐコードは非常に早い段階で作成されました。しかし、なぜ私が非常に不快になるのかわからないのはこの属性であり、その実用性はあまり良くありませんが、私はそれを克服したいだけです。今まで、少なくとも私は自分自身の理論的自己無撞着を達成しました。