少しずつゲームを作るスレ (960ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
ﾘﾛｰﾄﾞ規制です｡10分ほどで解除するので､他のﾌﾞﾗｳｻﾞへ避難してください｡
945(1): 456 [sage] 2025/06/12(木) 09:33:06.26 ID:1UEcXoJI(1) AAS
FormのプロパティKeyPreviewをTrueにすれば良いような気がするが背景(ユーザーコントロール)が謎すぎて何とも
946: Text Dungeon(英語化) [sage] 2025/06/12(木) 22:10:43.46 ID:yZyhP/xw(2/2) AAS
>>945
レスありがとうございます。
Text Dungeonはフォームは1つ(Form1)で、From1上に各画面ごとのユーザーコントロール
(例えばタイトル画面だったらUserControl_Title、メイン画面だったらUserControl_Mainなど)があって、
ユーザーコントロールを切り替える(.Visible=true/falseする)ことで画面を切り替える仕様になっています
また、KeyPressイベントは各ユーザーコントロールのイベントハンドラ(タイトル画面ならUserControl_Title_KeyPress)で処理しています
で、ユーザーコントロールにはKeyPreviewプロパティがないので、Form1のKeyPreviewをtrueにして
Form1のkeyPressイベントをUserControl_Title_KeyPressに転送してみたところ、>>944の現象を回避することができました
こっちの方がActiveControl = nullなんてことをするより筋のいいやり方かもしれません
ただ、この手法だとフォーカスは相変わらずコンボボックスに残るため
コンボボックスの操作終了後も四角い点線枠が表示され続ける(↓)
https://imgur.com/7TSHahn.png
のが妙に気になるので、一旦は>>944の処理で対応したいと思います。
ちなみに本現象はコンボボックスに限らずキー入力があるコントロールをユーザーコントロール上に置くと発生するようで
どうもユーザーコントロールはKeyPressイベントはあるのにTabStopプロパティはない、
子コントロールを置けるのにKeyPreviewプロパティはないなど、フォーカス周りの設計思想があいまいというか、
システム側にぶん投げてるような感じで、プログラマー側ではフォーカスを制御できないような気がします
(調べたわけではないので個人の感想です)
つまり、わしが悪いんやない、Microsoftがいい加減なのが悪かったんや……！
(と、いい加減プログラマーが申しております)
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.050s