アクティブなウインドウが切り替わるたびに発生するイベントはありますか

過去の桐井戸端ＢＢＳ　（桐ver.８）

12611	アクティブなウインドウが切り替わるたびに発生するイベントはありますか	pokopon	2001/08/14-14:29
みなさま　こんにちはおわかりになる方、また宜しくお願いいたします。アクティブなウインドウが切り替わるたびに発生するイベントととして、何がありますか？やりたい事は、メニュー.wfm 編集表は何も定義されててはいません。　単なるNULL表フォームです。この他に複数の「会話形式で開いた」表ファイルがいくつか同時に開かれています。これらの表は、メニュー.wfmに取り込まれている表ではありありません。単独の表です。これらの会話形式で開いた表において、アクティブなウィンドウを切り替えた際に（編集対象とする表を切り替えた時）、このメニュー.wfm でイベントを発生させ、メニュー.wfm内に、「現在編集している表は.....tblです」と表示させたいと思っています。そこで、問題となるのが、表ウィンドウがアクティブになっている時、裏で「メニュー.wfm」のイベントが活きていなければなりません。表ファイルウインドウがアクティブになっているときには、メニュー.wfmは非アクティブとなっているからです。タイマ1、2というイベントがありますが（これらは、非アクティブでも動くそうです）、これでは「常時監視型」となります。ウインドウハンドルが変更された時に発生するイベントなんかがあれば良いのですけど。あくまで、クリックによってアクティブウインドウが切り替わった際に発生するイベント機能（メニュー.wfm が非アクティブでも）が必要なのですが....適当なものが見つかりません。何か、良い解決方法はありませんでしょうか？
12652	不可能と思います	佐田　守弘	2001/08/18-01:09
記事番号12611へのコメント pokoponさん御質問の件ですが、多分不可能と思います。といいますのは、イベントはそのフォームの中での出来事だけをウォッチする機能で、別世界で発生している事は関知しませんし、関知する事もできません。御質問の件は、会話処理で開いた表ファイルの中で、どれがアクティブかを判定する事の様ですが、仮にそのメニューフォームから開いた表であっても元のメニューフォームではチェックのしようがありません。もし目的を達するとしたら、表形式で開かずにフォーム編集で開き、そのフォームの中で今自分がアクティブになった事 (フォーカス取得で可能と思います)をチェックし、その結果を変数などに入れて、メニューフォームに戻してやる必要がありそうです。ただしその場合にも、メニューフォームの表示を更新するために、一度メニューフォームをアクティブにする必要があります。つまり、ある表のフォームに切り換えたら、直後にメニューに一度戻って表示を更新し、もう一度そのフォームに戻る必要があります。ここで課題は２つあります。１つは、表のフォームを切り換えると、メニューを無理に表示する必要があるので、画面がブリンクするようになる点です。これは致し方ありません。２つ目は結構面倒な問題です。強制的に表示したメニューから元の開いた表のフォームに戻した時、同じイベントが発生します。このイベントでまたメニューが表示されてしまいますから、無限に切り替わるループに落ちるおそれがあります。従って、メニューを呼んだフォームに戻った時には、２度目にフォーカス取得があってもそれを無視するチェックを入れておく必要があります。この様に考えると、常時監視型の方が賢いかも知れませんね。佐田守弘(KS-00119)
12663	そう	pokopon	2001/08/19-00:04
記事番号12652へのコメント佐田　守弘さん　こんにちは中々レスが付かなかったので、殆ど「あきらめモード」でした。あるいは、この件は通常の手法では使わない内容なので、皆さんから相手にされなかったのか？と、ちょっと心配していました。いつも、見捨てずにアドバイスいただき、ありがとうございます。さて、 >御質問の件ですが、多分不可能と思います。 >といいますのは、イベントはそのフォームの中での出来事だけをウォッチする >機能で、別世界で発生している事は関知しませんし、関知する事もできません。そうですか、やはり難しい（というよりは、そのよな仕様を桐がもっていない）ことなのでしょう（覚悟はしていました）。やはり、フォームでいじるなら「wfmに表を取り込んで」が基本ですね。わかっちゃいるけど.....、「任意に開いた会話処理の表」にこだわっています。 >この様に考えると、常時監視型の方が賢いかも知れませんね。タイマ１、２イベントで実際に試したのですが、チェック間隔を0.1(秒)でやりましたが、さほど、動作そのものが遅くなるとか、レスポンスが悪いという印象はありませんでした。意外と、スピーディーです。イベントであまり複雑なことをさせていないからかもしれません。ただ、１点を除いて、実用に耐えうると感じています。この、「ただ１点の問題点」とは.... このイベント内に、表の状態を調べるために、編集表　&File (&File には、表ファイル名が代入さてれいる) を入れると、表の画面のスクロールに不具合が出ます。ウインドウ右端にあるスクロールバーをつかんで動かしても、正常にスクロールされません。これは、桐の不具合というよりも、0.1秒間隔で、制御が「表⇔フォーム」といったり来たりするからかな？あるいは、桐本体が表を監視する制御と、このフォームによって生じる制御がぶつかり合っているのか？なんて、この不具合の原因を考えています。このため、実用化できないでいます。Ｋ３に問い合わせてはいるのですが、お盆＆社員の夏休み？の関係かどうか、未だ回答を得てはいません。Ｋ３からの回答が得られましたら、再度ご報告させていただきます。ありがとうございました。
12677	インタバルは	佐田　守弘	2001/08/20-01:10
記事番号12663へのコメント pokoponさんタイマイベントで0.1秒間隔で割り込みを掛けている様ですが、この目的からすれば、１秒間隔でも充分なほどで、場合によっては10秒でもよいのではないでしょうか。タイマイベントを多発すると、余り好ましい結果が起きない事もあり得るので、私は、実の所、使った事がありません。佐田守弘(KS-00119)
12680	Re:インタバルは	pokopon	2001/08/20-01:47
記事番号12677へのコメント佐田　守弘さん　こんにちはいつもご教授ありがとうございます。 >タイマイベントで0.1秒間隔で割り込みを掛けている様ですが、この目的からすれば、 >１秒間隔でも充分なほどで、場合によっては10秒でもよいのではないでしょうか。いいえ、ダメです。これでは目的は達成できません。会話形式で開いた表ファイルが複数あります。それを切り替えて操作する時、NULL表のフォーム（メニュー.wfm）に、現在の対象としてる表ファイル名を表示したいと思っています。仮に１０秒とすれば、表にカーソルがあたってから、１０秒経たないと結果がフォームに表示されません。その間に、表ファイルを何度か切り替えた場合には、結果が反映されない事になります。ですので、理想的には「表のウインドウにカーソルがあたった瞬間だけ」イベントが発生してくれれば良いのですが、そのようなイベントはないようなので「常時監視型」となります。 0.1秒でも「常時」ではありませんが、実質上は、0.5秒でも良いかも知れません。（最初、デフォルテの「０」でやりました。これこそ「常時」と思っていましたが、これだとイベントが働きませんね）すいませんが、このような事情です。 >タイマイベントを多発すると、余り好ましい結果が起きない事もあり得るので、 >私は、実の所、使った事がありません。この余り好ましくない結果とは？　どのようなことが予想されますか？こちらの仕様では、このタイマー型イベント内で、編集表　&File に不具合が出ますが、それ以外では、特別な「悪さ」は出てはいません。これは、インターバルを変えても、完全には解消されませんでした（１秒にしても、1秒周期で不具合が出ます。）ちなみに、タイマイベントはマニュアルによると、他のイベントが実行中には「発生しない」のだそうです。 ----　マニュアルから ■イベントの発生 [タイマー1]イベントは、指定した時間が経過するたびに発生するイベントです。このイベントを定義したフォームが、非アクティブであっても発生します。ただし、会話処理用のダイアログボックスが出ているとき、または他のイベントハンドラが実行中のときは、発生しません。ですので、何かコマンドボタンを押したりして別のイベントが実行されれば「お休みモード」になるイベントとして解釈していました。ですので、タイマ１のイベント内に記述するコマンドにどのような制約があるかは分かりませんが、「簡単な表の状態のチェック」程度なら、実害がないのかな？　なんて考えてはいます。もちろん、イベント自体が、インターバル時間内に終了できていなければなりません。（イベント処理が終わらないうちに、次のイベントが発生？）しかし、理想的には余計なイベントが発生するのは好ましくない訳ですので、「カーソルがあたった時だけに発生するイベント」が欲しいですね。
12695	とりあえずの解決編です	pokopon	2001/08/20-22:00
記事番号12663へのコメント >>御質問の件ですが、多分不可能と思います。 >>といいますのは、イベントはそのフォームの中での出来事だけをウォッチする >>機能で、別世界で発生している事は関知しませんし、関知する事もできません。Ｋ３に問い合わせてみました。回答が得られましたので転記します。 >編集表　&File (&File には、表ファイル名が代入さてれいる) >を入れると、表の画面のスクロールに不具合が出ます。ウインドウ右端にあるスクロールバ >ーをつかんで動かしても、正常にスクロールされません。という質問事項に対して、 >タイマイベントを使用するフォームがあると，表のスクロールバーの動きが >キャンセルされる（ように見える）現象ですが、イベント処理はフォームに対し >て行うことを前提としているため、表を対象としている今回の状況への配慮は現 >在しておりません。 >したがって、切り替えるウィンドウは表ではなくフォームとしていただくことで >対応できます。 >また，回避策ではありませんが、スクロールを無効とするタイミングが編集表コ >マンドの実行時のようですので、毎回編集表コマンドを発行するのではなく，前 >回の編集表対象表から変更が発生している場合にのみ編集表コマンドを >発行することで，現象の発生頻度を少なくすることは可能かと思われます。ということで、本件に対する「完全な解決方法は、今は見当たらない、桐が対応していない」というところです。 >やはり、フォームでいじるなら「wfmに表を取り込んで」が基本ですね。 >わかっちゃいるけど.....、「任意に開いた会話処理の表」にこだわっています。仕方ない、このあたりは「妥協」も必要というところですか....。何か、フォームって「便利＆多機能」である反面、「痒いところに手が届かない」ような歯がゆさを覚えてきました。意外と簡単にできそうなことも、結構難しかったり不可能だったり....。まあ、前向きに考え、「便利＆多機能」な部分を最大限に活用し、痒い所に手が届かなかったら「妥協やあきらめ」も必要であるということですか。今のところ、不便さよりも便利さの方がまさっていますので。以上、報告まででした。

戻る