イベントのメイン処理内で桐を強制終了させたい

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

24026	イベントのメイン処理内で桐を強制終了させたい	沼田	2003/12/26-12:36
こんにちは。いつもご迷惑をお掛けします。フォームの開始時に一定条件をチェックし、条件に沿わない場合に桐そのものを強制的に終了させたいと思っています。一定条件とは、このフォームの編集対象表を編集する必要があるという意味ですが、この編集対象表は別のフォームから参照されている上に、索引の解除や再構成を行う必要があるなど、このままでは操作することができない状態になっています。従って、フォームが表示される前に、メッセージボックスによって注意を促した上で強制終了させ、所定の処理を実行するようにしたいのです。（所定の処理は別の一般手続きで組まれています。）この時、一定条件に沿っている場合でも、その上で別の処理を行いますので、イベント処理の「メイン」部に記述したいと思っています。一般的な桐の終了は、終了　桐コマンドで可能ですし、イベント内からの処理でも、終了用のコマンドボタンを作っておいた上で、メソッド呼び出し　@終了ボタン.実行() とすれば可能なことまでは分かっていますが、「メソッド呼び出し」はメイン処理内では実行できません。仕方がないので、メイン処理内で判断させて、フォーム開始イベントまで処理を進めてから「メソッド呼び出し」を実行させるしかないのかな、と思っていますが、このやり方で"やむを得ない"とするしかないのでしょうか。
24027	Re:メイン処理内で桐を強制終了させたい	うにん	2003/12/26-12:46
記事番号24026へのコメント >従って、フォームが表示される前に、メッセージボックスによって注意を促した上 >で強制終了させ、所定の処理を実行するようにしたいのです。「実行条件が不適です」とか表示してそのフォームだけ閉じてしまえば、桐は終了させなくていいのでは？例えば何か他のファイルで作業をしている時に、たまたまそのフォームを開いたら桐自体が終了してしまうようなのって、迷惑なフォームだと思うのですが。
24028	Re:メイン処理内で桐を強制終了させたい	沼田	2003/12/26-14:42
記事番号24027へのコメントうにんさん、こんにちは。 >例えば何か他のファイルで作業をしている時に、たまたまそのフォームを開いたら >桐自体が終了してしまうようなのって、迷惑なフォームだと思うのですが。そうですね。確かに迷惑なフォームになるかも、という気がしないでもないです。この問題の、そもそもの目的はデータの復元です。データを「書き出し」コマンドで別フォルダに保存していますが、枠の書き出しまでは行っていませんので復元するには「読み込み」コマンドを実行しなければなりません。この表には、更新禁止や重複禁止属性を与えた項目なども定義していますし、何よりもこの表を編集対象表としたフォームを表示させた状態で、問題の処理をさせたいと思っているのです。別のフォームをメニュー画面として表示させていますが、このフォームの編集対象表こそが問題の表なのです。一つの同じ表を編集対象表とした２種類のフォームがあり、一方のフォームを表示させている状態からもう一方のフォームを呼び出すとき、一定条件によって編集対象表を再構成させたい、というのがそもそもの目的です。再構成の内容が「読み込み」という場合があり、その時には重複禁止属性を解除し、データを読み込んだ後で整形し、その後に重複禁止をONに戻す、などの処理を必要とします。その表を使っているフォームそのものが表示中である限り、このような再構成はできないと考えました。そこで、整形するためだけの一括処理を作り、直接実行させようとしているのです。そのためには、今動いているプログラムを止めないといけないし、始めに開いたフォームで使用されている表も閉じなければいけません。こういう理由から「強制終了」という発想が出てきたのです。一発で終わらせようと....。「強制終了ができればすっきるする」という感じではありません。終了させることなく、現在使用中の表を再構成できればいいんですが、これは無理じゃないかと、そんな気がしています。
24029	Re:メイン処理内で桐を強制終了させたい	悲しげ	2003/12/26-15:18
記事番号24028へのコメントどもっ、沼田さん編集対象表を同じくするふたつのフォームを同時に（多重化）オープンしている時……と云う前提があったのですね。 >再構成の内容が「読み込み」という場合があり、その時には重複禁止属性 >を解除し、データを読み込んだ後で整形し、その後に重複禁止をONに戻す、 >などの処理を必要とします。 >その表を使っているフォームそのものが表示中である限り、このような再 >構成はできないと考えました。う～ん、確かにちょっと危険っぽい匂ひが漂いますね（試してませんが）。私なら、「一定条件」の判断および「その上で別の処理」は、メイン部でできないものを含んでいるのなら、フォーム開始部を使うと思います。で、条件次第では、もうひとつのフォームの方を閉じてします。　メソッド呼び出し　ハンドル=&もうひとつのwfmのそれ,@b閉じる.実行() もうひとつのフォームのハンドル値は、共通または固有変数で別途取得済みとします。その上で、所定の処理を実行させた後で、再度もうひとつのフォームを開き（コマンドボタンの「開く」で）、しかる後に自らのフォームを閉じて、制御を元のフォームに渡す。これらは、概ね「フォーム開始」イベントでやると云う想定です。ちなみにこれらの過程を「ウィンドウ作成～ウィンドウ終了」コマンドでやる方法は、ちょっと複雑になるかもしれず、要するに私には判りません。(^^;) 余談ながら、「フォーム開始」でだと、「別な処理」に進まない場合にもフォームが一時的にチラリと画面に出てしまうのがイヤならば、最小化オープンなんかで逃げる方法もありえます。
24030	Re:メイン処理内で桐を強制終了させたい	佐田　守弘	2003/12/26-21:00
記事番号24026へのコメント沼田さん状況が的確に理解できてないので、外したコメントになるかも知れません。沼田さんはそれなりに一括処理やイベントを使いこなされる力量はありそうなので、こんな方法も考えられるのではないかというアイデア的なものをいくつか提示して見ます。私の方では巧く行くかどうかの確認はしていませんが、ヒントとして参考にしてみて下さい。 ●２つのフォームを開いている件について同じ編集対象表で２つのフォームを開いているとの事ですが、これはフォーム呼び出しコマンドを使って、モーダルフォームを開いているのでしょうか。そうであれば、仰るように１つの表を２つのフォームで開いている状態になります。そこで、フォーム切替えで別のフォームに切替える方法はどうでしょうか。この方法ならば、開かれている表は１つだけなので、制限ない処理が可能かと思います。コマンドボタンの機能に表示の「フォームの選択」を設定し、パラメータに切替えるフォーム名を指定します。 ●メニューの編集対象表の指定を外す #24028で、 >別のフォームをメニュー画面として表示させていますが、このフォームの >編集対象表こそが問題の表なのです。と書かれています。１つには、メニューだけのフォームであれば編集対象表を指定しないのが良いかと思います。仮に、表のレコード数を表示したり、表のあるデータをメニュー上で表示する必要がある場合でも、編集対象表として設定するのではなく、フォーム開始イベントないしはその他のイベントで、その表を開いて必要な情報を取り込んでから、表を閉じてしまえば良いわけです。 ●一連のデータ復元の処理もしある表を対象として一連のメンテナンス的な処理をするのであれば、もう１つのフォームを開く必要はなく、メニューフォームのコマンドボタンで実行する一括処理なり、イベントの中でその表を開いて処理すれば済む様にも思えます。佐田守弘(KS-00119)
24031	Re:メイン処理内で桐を強制終了させたい	沼田	2003/12/26-22:55
記事番号24030へのコメント悲しげさん、佐田さん、いつもご迷惑をお掛けします。 >●２つのフォームを開いている件について >そこで、フォーム切替えで別のフォームに切替える方法はどうでしょうか。こだわりの世界になるのかもしれませんが、一方のフォームを使って絞り込み後の状態を表示し続けたいと思っています。当然、表は使用中になりますので、表定義そのものまで触ってしまうような処理はできないのではないかと思っています。 >●メニューの編集対象表の指定を外す１つの表は２つのフォームから使用されますが、実際の使い方は、一方では簡易編集を、他方では詳細な編集をと思っています。従って、どちらのフォームからでも編集できるようにしたいので、編集対象表の指定を外すことは避けたいと思います。 >●一連のデータ復元の処理前項と同じ理由で、難しそうに思えます。２つのフォームの関係は、一方がメニューの機能を持たせたフォームで、他方がサブシステム用のフォームですが、メインシステムの機能の中に共通で使用する編集対象表の一部分をデータとして常時表示させておきたいという要求を持っています。メインシステム側からでもある程度の処理はさせますが、複雑な処理はサブシステムで行いたいと思っているのです。しかも、メイン側、サブ側、どちらもメニュー選択という連携関係の処理と共に、単独ででも使いたいと思っているのです。単独ででも使えるという点で、これらの関係はいわゆるメイン＆サブフォームの関係ではありません。この要求もあり、これら２つのフォームは別のフォルダに分けています。メイン側に置いたコマンドボタンによって別フォルダのwfmファイルを呼び出し処理を受け渡しますが、呼び出し先のwfmを直接実行しても十分に使えるようなシステムにしたいのです。現在の設定では、メイン側で表示させているだけのデータでは分からないけれども、詳細編集を行うサブ側で処理をするには不都合だ、という事例が出てくる可能性があります。これをチェックし、不都合な事例が出た時に正常な状態に整形する必要があるのです。この時に、表の再定義の必要が出てきます。「表示中の表の再定義」という必要から、表を使用中にしないことが前提条件ではないかと思っています。この表を使わないフォームで"逃げる"のが、得策かもしれないですね。
24032	Re:メイン処理内で桐を強制終了させたい	うにん	2003/12/27-00:03
記事番号24028へのコメント >再構成の内容が「読み込み」という場合があり、その時には重複禁止属性を解除し、データを読 >み込んだ後で整形し、その後に重複禁止をONに戻す、などの処理を必要とします。う～～ん、いまいちよく理解できないのですが。重複禁止な項目に読み込むなら、先にデータを重複しないように整形してから読み込めばいいので、表（というか索引ですね）の定義を変えるのはまっとうでない気がします。
24047	Re:メイン処理内で桐を強制終了させたい	沼田	2003/12/28-00:04
記事番号24032へのコメントうにんさん、こんにちは。 >表（というか索引ですね）の定義を変えるのはまっとうでない気がします。どうも僕は、物事をことさらに難しくしてしまうクセがあるようで....。２種類のシステムがあるんですが、それぞれは"A.wfm"と"B.wfm"で、それぞれは単独で動作しています。これらのwfmはいずれも同じ"元表.tbl"を編集対象表としています。単独ででも使いますので編集対象表を外すことはできません。その上で、"A.wfm"に"B.wfm"を呼び出すためのコマンドボタンを定義し、"A.wfm"から"B.wfm"に処理を移すことを可能にしています。一方で、単独で"B.wfm"を使う時には一定のチェックを入れ、読み込み処理を行う場合があります。会話処理で挿入初期値式に#直前値なども使っていたり、重複禁止の属性を与えたりしていますので、どうしても表の再定義をしなければエラーになってしまいます。この処理を"B.wfm"のkevファイルメイン部で行っています。このような状況の中で、"A.wfm"から"B.wfm"を呼び出した時に、チェックによって読み込み処理をしなければならなくなった場合に今回の問題が発生します。つまり、"A.wfm"によって"元表.tbl"は既に開かれており、"B.wfm"のチェックにより"元表.tbl"の再定義をしなければならない、という問題です。単独で動かしている時には処理ができていますので、今回の問題が出てきた時には"A.wfm"を閉じてしまい、 "B.wfm"を直接起動して必要な処理だけ行ってしまえばいい、というのが今回の発想です。それを尤も手っ取り早く済ます方法は、チェックに該当した時点で全部を「終了」してしまい、 "B.wfm"を実行させればいい、と考えたのです。これはkevファイルのメイン部ですから仕様により利用できません。その他の”工夫”でも無理なようですからフォーム開始イベント辺りで処理するしかないようです。その為の工夫を、もう少し考えてみたいと思っています。
24052	編集中の表の再定義	佐田　守弘	2003/12/28-11:50
記事番号24031へのコメント沼田さん行いたい内容を完全に理解できたわけではありませんが、ポイントは、以下の部分かと思います。　>これをチェックし、不都合な事例が出た時に正常な状態に整形する必要があ　>るのです。この時に、表の再定義の必要が出てきます。　>「表示中の表の再定義」という必要から、表を使用中にしないことが前提条件ではな　>いかと思っています。つまり一言でいえば、編集中の表の再定義をしたいという事と理解します。 ●表の再定義は桐の言葉でいえば「表の枠組み」、つまりデータベースのストラクチャは、最も基本的な部分です。基本的にはデータベースを構築する際には、後から表の定義を変更する必要がない様に設計するのが本来です。とは言え、実際には運用してみて直さなければならない事もあるので、再定義をし直す事もあり得るし、実際、途中で再定義をするケースも少なくないと思います。しかし表の再定義は、表の根幹に関わる部分ですから、表の編集をしながら再定義を行う事は不可能です。再定義を行うには、桐の場合には表の編集モードから再定義モードに移行したり、また「項目属性変更」コマンドを使って開いている表の再定義を行う事ができますが、制限があります。表編集からの再定義への移行は、その表を専有モードで開いている時に限られます。仮にユーザーが１人だけであっても共有で開いた表は再定義に入れません。また項目属性変更コマンドで、既存項目の属性の変更や、項目の削除、新規項目の追加まで可能ではありますが、フォームで開かれている編集対象表のに対しては使えません。その様なわけで、沼田さんが希望しているデータに不都合があった場合、フォーム上から再定義を行うといった処理は、不可能かと思います。状況が完全に解ってないので、それ以上のコメントが難しいのですが、何らかの他の方法を考える必要があるかと思います。佐田守弘(KS-00119)
24055	Re:メイン処理内で桐を強制終了させたい	悲しげ	2003/12/28-15:35
記事番号24047へのコメントどもっ、沼田さんやりたいことがよく判りませんが、定型的な作業としてならば、他の方も仰るように、索引定義（重複禁止設定）をその都度変更するような方法は避けるべきだと思います。「一定のチェック」の具体的中身もよく判りませんが、問題となるのが「重複禁止」の有無だけであるのならば、次のような方法もありうるかとは思います。「一定のチェック」用の作業用別表を用意する。表の構成は元の表と同じとし、ただ重複禁止だけを設定しないでおく。で、この(空の)作業表にデータを読み込んで「一定のチェック」をさせる。※ その結果によっては、データを元表に書き戻す（元表の方を全行削除した上で作業表から全データを読み込む）。これをB.wfm上の「名札　メイン」部または「フォーム開始」部で実行させる。ただ、もしこれだけの処理なら、別にB.wfm上でやらなくても、 A.wfm上で別表作業表で処理させることもできるとは思いますが。(^^;) ※重複許可してある表で、重複行が存在した時に、重複がないデータに再構成するには、　(1)絞り込み単一化　(2)絞り込み補集合　(3)存在すれば（必要なら変数でフラグを立てて）全行削除　　　　　　　　　例：&フラグ=&選択件数　(4)絞り込み解除→必要なら表整理です。
24077	Re:編集中の表の再定義	沼田	2003/12/31-00:12
記事番号24052へのコメントみなさん、こんばんは。沼田です。 ”そもそもやりたいことは何なのか”を飛ばしてしまって小手先の質問だけをしてしまいました。何かしら困ったことが出てきたから質問させて貰った訳ですが、「これが出来れば解決するはずだ」と、勝手に思い込んでしまったことが、皆さんにご迷惑をお掛けした原因です。コマンドの使い方や構文などの疑問ならそれでも良いでしょうが、今回のような”勝手な思い込み ”で質問するべきではありませんでした。「こんなことがしたいのですがどのようにしたら良いですか」のような質問にすべきでした。情けないことですが、今回のことで得られた僕の教訓です。結論的に言えば、「桐の強制終了」は、現在の所はフォーム開始部で行うようにしました。たくさんの方々から指摘いただいていますように、これは理想的な処理の仕方ではありません。とりあえずエラーを回避するための方便と、自分でも思っています。表の再定義についても多くの方からアイデアをいただいていますので、それを一つずつ試してみようと、今は思っています。システムとして、強制終了させなければならないプログラムは、それだけでも欠陥と言っても良いくらいだと思いますし、例え使用中の表であっても再定義をしたことと同程度の整形が可能だと多くの方から教示いただいていますので、それを実現すべく頑張ってみようと思います。その時にはまた新たな疑問が出てくるだろうと思いますが、その際にはまた改めて質問させていただきます。本当にありがとうございました。

戻る