C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[13]: Enterキーによるボタン連打制御 [1]


(過去ログ 78 を表示中)

[トピック内 30 記事 (21 - 30 表示)]  << 0 | 1 >>

■46010 / inTopicNo.21)  Re[10]: Enterキーによるボタン連打制御
  
□投稿者/ Jitta on the way (527回)-(2010/01/23(Sat) 07:42:13)
No46009 (なちゃ さん) に返信
> ちょっと気になったので。
>
> >> 質問1:PreviewKeyDownが発生しない原因はなんでしょか?
> >「すでに押されている」ため、キーの状態が変化したわけではないから。
>
> いや、PreviewKeyDownはキーリピート毎に発生しますよ。
> そこでキーを無効にしているので、やり方や挙動の是非はとりあえずおいておいても、押しっぱなし防止自体はできているのでしょう(確認はしてませんが)。
>
> AcceptButtonじゃないとするとちょっと原因は思いつかないんですけどね。
> そうそう、45930でデフォルトボタンとか書いたのは、AcceptButtonの事(つもり)でした。
> ※今更遅いですが。
>



発生しました?してます?
やりかた間違ったか。

Accept じゃないのに…は、既にフォーカスがあるから、です。だから、「情報不足」と書いて、具体的に欲しい情報も書いています。
タブ オーダーが 0 なら、フォーカスを示す枠が無くてもフォーカスが当たった状態になっています。フォームを new - close するのではなく、show - hide するなら、前回消すためにフォーカスを当てていますから、次に表示した時もフォーカスが当たったままになっています。私は、フォーム1、2共に hide させたのですが、枠はありませんでした。ですから、AcceptButton のようになっているのかもしれません。
あ、他に AcceptButton があったらどうなるか、やってないわ。


また、「まだ不十分」というのは、一応「押しっぱなし」による高速切り替えには対応できていますが、フォーム2で押しっぱにした(切り替えはブロックされる)あと、キーを離すと、フォーム2が消えるのです。keyup でフラグをクリアしたあと、click が発生しているのかなぁ?
引用返信 編集キー/
■46020 / inTopicNo.22)  Re[10]: Enterキーによるボタン連打制御
□投稿者/ alvin (38回)-(2010/01/23(Sat) 13:57:21)
2010/01/23(Sat) 13:59:19 編集(投稿者)

情報不足という現状なので、最初から整理させていただきます。

クラス構成:
基底クラスと派生クラス(各業務画面)があります。
業務画面が起動される時に、基底クラスは各コントロールに対して、フォント、サイズ等の設定を行います。


現在の対策:
Enterキーを押し続けると、click→click→click→・・・→KeyUpの順で発生します。
これを防ぐために、基底クラスがボタンのデザインを設定するとこで、各ボタンにPreviewKeyDownとKeyUPのイベントハンドルを追加しました。

// PreviewKeyDownハンドル
Private Sub PreviewKeyDownHandler(VaVal sender As Object, ByVal e As System.Windows.Form.KeyEventArgs) _
Handles button1.PreviewKeyDown
If e.KeyData = Keys.Enter Then
e.IsInputKey = True
End
End Sub

// Keyupハンドル
Private KeyUpHandler(ByVal sender As Object, ByVal e As System.Windows.Forms.KeyEventArgs) _
Handles button1.KeyUp
If e.KeyData = Keys.Enter Then
button1.PerformClick()
End If
End Sub

これの実装により, Enterキーを押し続けると、PreviewKeyDown→KeyDown→KeyPress→ PreviewKeyDown→KeyDown→KeyPress→ ・・・→KeyUp(離した時)
になり、Enterキーによるボタンがクリックされるデフォルト動作はなくなり、KeyUpでクリックイベント発生させています。
--------------------------------------------------------------------------------------------------------
上記で、Enterキー押しっぱなしによる、Clickイベントの連続発生を防いでいます。

問題1:
メニューから画面Aを起動しました。
この時、画面A.ボタンAにフォーカスがあるように見える(GOOGLE.co.jpを開いた時の、検索ボタンの状態、またはボタンの周りに点線がない状態)が、
Enterキーを押したら、PreviewKeyDown、KeyDown、KeyPress、KeyUpが発生しないまま、クリックイベントが発生します。
(画面Aが起動されて、マウスでボタンAにちゃんとフォーカスを当ててからEnterキーを押すと、正しい動きをします。)

問題2:
画面Aから画面Bを起動しました。
画面Bが起動されると、画面B.閉じるボタンにフォーカスがあるように見える(GOOGLE.co.jpを開いた時の、検索ボタンの状態、またはボタンの周りに点線がない状態)。
この時、Enterキーを押すと、画面が閉じられ、Enterキーを離すと画面Bが起動される(画面A.ボタンAにフォーカスがあり、KeyUpが発生したため)。

根本的に、問題1と2も一緒だと思いますね。
なぜボタンがそのような状態になり、Enterキーによりクリックイベントが発生するんでしょうか?


引用返信 編集キー/
■46062 / inTopicNo.23)  Re[11]: Enterキーによるボタン連打制御
□投稿者/ Jitta (627回)-(2010/01/24(Sun) 18:56:35)
Jitta さんの Web サイト
No46020 (alvin さん) に返信
 もしかして、すべてのボタンで Preview... と KeyUp をハンドルしている?
引用返信 編集キー/
■46066 / inTopicNo.24)  Re[12]: Enterキーによるボタン連打制御
□投稿者/ alvin (39回)-(2010/01/25(Mon) 10:05:56)
2010/01/25(Mon) 11:38:27 編集(投稿者)
2010/01/25(Mon) 11:18:54 編集(投稿者)
2010/01/25(Mon) 11:13:28 編集(投稿者)
2010/01/25(Mon) 11:01:00 編集(投稿者)

No46062 (Jitta さん) に返信
> ■No46020 (alvin さん) に返信
>  もしかして、すべてのボタンで Preview... と KeyUp をハンドルしている?

そうですが・・、なんかまずいでしょうかね?

追記:
SPY++で監視してみたら、EnkeyキーDOWNでフォームがWM_SYSKEYDOWNを受信し、ボタンはなにも受信してないようです。
「フォーム受信内容」
WM_SYSKEYDOWN nVirtkey:VK_RETURN cRepeat:1 ScanCode:1C fExtended:1 fAltDown:0 fRepeat:0 fUp:0


追記2:
http://msdn.microsoft.com/ja-jp/library/cc411074.aspx
「あるウィンドウがアクティブであってフォーカスを設定されていない場合、何かキーを押すと、WM_SYSCHAR、WM_SYSKEYDOWN、WM_SYSKEYUP いずれかのメッセージが生成されます。」と書いてあります。

現状は、WM_SYSKEYDOWNが生成され、ボタンのクリックイベントは発生しているようです。



引用返信 編集キー/
■46067 / inTopicNo.25)  Re[13]: Enterキーによるボタン連打制御
□投稿者/ Jitta on the way (533回)-(2010/01/25(Mon) 12:03:28)
No46066 (alvin さん) に返信
>> もしかして、すべてのボタンで Preview... と KeyUp をハンドルしている?
>
> そうですが・・、なんかまずいでしょうかね?


(-_-;)(-_-;)(-_-;)

こっちで再現できなければ、調べようがないんですよ。
こっちが作ったものなら、「これとあれとその情報を下さい」と言えるのですが、そうではないので、足りないところは勝手に補っています。
そりゃ、再現しないはずだ。

情報を出さない方が悪いのか。勝手に補う方が悪いのか。
どっちが悪いとは言いませんが、私は「こんなに情報を隠すなら、もう付き合ってらんない」と、匙を投げることにします。少なくとも、私は困らないので。次回からは、現象が再現させられる最低限のコードを提示するように勧めます。
引用返信 編集キー/
■46070 / inTopicNo.26)  Re[14]: Enterキーによるボタン連打制御
□投稿者/ alvin (40回)-(2010/01/25(Mon) 13:08:38)
2010/01/25(Mon) 16:08:58 編集(投稿者)

No46067 (Jitta on the way さん) に返信
> ■No46066 (alvin さん) に返信
> >> もしかして、すべてのボタンで Preview... と KeyUp をハンドルしている?
>>
>>そうですが・・、なんかまずいでしょうかね?
>
>
> (-_-;)(-_-;)(-_-;)
>
> こっちで再現できなければ、調べようがないんですよ。
> こっちが作ったものなら、「これとあれとその情報を下さい」と言えるのですが、そうではないので、足りないところは勝手に補っています。
> そりゃ、再現しないはずだ。
>
> 情報を出さない方が悪いのか。勝手に補う方が悪いのか。
> どっちが悪いとは言いませんが、私は「こんなに情報を隠すなら、もう付き合ってらんない」と、匙を投げることにします。少なくとも、私は困らないので。次回からは、現象が再現させられる最低限のコードを提示するように勧めます。

別に、なんか隠しているわけでもないし、そう感じてしまったら仕方ないですが。
なんとも言えようがないですね。。
引用返信 編集キー/
■46078 / inTopicNo.27)  Re[15]: Enterキーによるボタン連打制御
□投稿者/ alvin (42回)-(2010/01/25(Mon) 17:21:42)
2010/01/25(Mon) 18:50:26 編集(投稿者)

ある程度対策が取れたので、閉じます〜

原因:
ボタンの状態がアクティブでありながら、フォーカスは持っていない。
これにより、Enterキーを押下しても、PreviewKeyDown、KeyDown、KeyPress、KeyUpが発生しない。
なぜこのような初期状態になるかははっきりしないですが、おそらく構成を管理する常駐プロセスと関連があると判断されます。

対策:
フォームのPaintイベントで、アクティブコントロールは必ずフォーカスを持つように制御する。

Paintイベントハンドラ
If Me.ActiveControl IsNot Nothing Then
Me.ActiveControl.Focus()
End Sub

ご協力ありがとうございました。

解決済み
引用返信 編集キー/
■46358 / inTopicNo.28)  Re[13]: Enterキーによるボタン連打制御
□投稿者/ 通りすがり (55回)-(2010/01/31(Sun) 15:41:57)
No46066 (alvin さん) に返信
> 2010/01/25(Mon) 11:38:27 編集(投稿者)
> 2010/01/25(Mon) 11:18:54 編集(投稿者)
> 2010/01/25(Mon) 11:13:28 編集(投稿者)
> 2010/01/25(Mon) 11:01:00 編集(投稿者)
>
> ■No46062 (Jitta さん) に返信
>>■No46020 (alvin さん) に返信
>> もしかして、すべてのボタンで Preview... と KeyUp をハンドルしている?
>
> そうですが・・、なんかまずいでしょうかね?

まずいと思いますよ
引用返信 編集キー/
■46360 / inTopicNo.29)  Re[14]: Enterキーによるボタン連打制御
□投稿者/ 通りすがり (56回)-(2010/01/31(Sun) 15:44:57)
No46067 (Jitta on the way さん) に返信
> ■No46066 (alvin さん) に返信
> >> もしかして、すべてのボタンで Preview... と KeyUp をハンドルしている?
>>
>>そうですが・・、なんかまずいでしょうかね?
>
>
> (-_-;)(-_-;)(-_-;)
>
> こっちで再現できなければ、調べようがないんですよ。
> こっちが作ったものなら、「これとあれとその情報を下さい」と言えるのですが、そうではないので、足りないところは勝手に補っています。
> そりゃ、再現しないはずだ。
>
> 情報を出さない方が悪いのか。勝手に補う方が悪いのか。
> どっちが悪いとは言いませんが、私は「こんなに情報を隠すなら、もう付き合ってらんない」と、匙を投げることにします。少なくとも、私は困らないので。次回からは、現象が再現させられる最低限のコードを提示するように勧めます。


補ってしまうかたは、善意をかけた時間が不満感にならないなら悪くないと思います。
親切と思ってやってしまうのですよね。
引用返信 編集キー/
■46361 / inTopicNo.30)  Re[15]: Enterキーによるボタン連打制御
□投稿者/ 通りすがり (57回)-(2010/01/31(Sun) 15:50:16)
2010/01/31(Sun) 15:56:17 編集(投稿者)
2010/01/31(Sun) 15:54:43 編集(投稿者)
No46070 (alvin さん) に返信
> 2010/01/25(Mon) 16:08:58 編集(投稿者)
>
> ■No46067 (Jitta on the way さん) に返信
>>■No46066 (alvin さん) に返信
>>>> もしかして、すべてのボタンで Preview... と KeyUp をハンドルしている?
> >>
> >>そうですが・・、なんかまずいでしょうかね?
>>
>>
>>(-_-;)(-_-;)(-_-;)
>>
>>こっちで再現できなければ、調べようがないんですよ。
>>こっちが作ったものなら、「これとあれとその情報を下さい」と言えるのですが、そうではないので、足りないところは勝手に補っています。
>>そりゃ、再現しないはずだ。
>>
>>情報を出さない方が悪いのか。勝手に補う方が悪いのか。
>>どっちが悪いとは言いませんが、私は「こんなに情報を隠すなら、もう付き合ってらんない」と、匙を投げることにします。少なくとも、私は困らないので。次回からは、現象が再現させられる最低限のコードを提示するように勧めます。
>
> 別に、なんか隠しているわけでもないし、そう感じてしまったら仕方ないですが。
> なんとも言えようがないですね。。

第3者的に見ていると。alvinさんは工夫の余地があるように見えますよ。
途中で、基本的なフォームを作って再現テストされている方がいると思いますけど、
最小限の手順に切り分ける実験をその方がされるのではなくて、
alvinさんが実施すれば、問題のアプリと基本アプリの動作の違いに気づくのでは。

「問題点は最小限の再現できる手順にまとめる。」
と言うこと自体が基本路線だと思います。

「あれ?再現できませんか?」と一言声かけしてあげれば、
すむところでもあるわけですから、コミュニケーション的にも工夫の余地があるように思います。

他の方はだいぶalvinさんに歩み寄っていますよ。これ。

勘や阿吽の呼吸で答えられるようなことなら別にいいと思いますがねえ…。


しかし一方で、
基底クラスを変えているとははじめにおっしゃっていますがね…。
それをこぴぺはしづらいですよね…。(お仕事のソースを貼れないですよね…。)



解決フラグを変えてしまったようで…。
alvinさんの最後の発言で解決済みです…。 ごめんなさい。
解決済み
引用返信 編集キー/

<前の20件
トピック内ページ移動 / << 0 | 1 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -