過去の桐井戸端BBS (桐ver.9) |
24102 | フォームのコマンドボタンで一括処理を開こうとするとエラーになる | 沼田 | 2004/01/02-12:57 |
今年もご迷惑をお掛けしそうですが、よろしくお願いします。 フォームのコマンドボタンから一括処理を呼び出そうとすると、 「このシステムは何らかの原因で起動出来ません。処理を中止します。」 と表示されます。 一括処理で組まれているシステムがあります。 このシステムをフォームから実行しようとしてフォームにコマンドボタンを 置きました。 機能名:開く 機能パラメータリスト1:D:\別のフォルダ\システムの名前.cmd このコマンドボタンを押下すると上記のエラーが表示されます。 考えられる原因にはどのようなものがありますでしょうか。 | |||
24104 | コマンドボタン「開く」でcmdファイルは指定不能 | 悲しげ | 2004/01/02-14:34 |
記事番号24102へのコメント どもっ、沼田さん タイトルの件は、v8では「秘密の抜け道」的に使えていましたが、 v9になって塞がれてしまった(本来の仕様どおりに戻った)ようで。 cf.【多遊】さんの掲示板、過去ログ#83,No.477〜 | |||
24105 | 「シェル実行」を使いましょう | 悲しげ | 2004/01/02-14:44 |
記事番号24104へのコメント 代替策を書くのを忘れました。(^^;) 私が使っている方法を挙げておきます。 機能名 シェル実行 同パラメタリスト """"+#桐パス名+&桐EXE+"""","-AO -R "+""""+#データパス名+"某.cmd"+"""" ※変数「&桐EXE」には事前に"kiri9.exe"または"kiri8.exe"を代入済。 | |||
24106 | Re:フォームから一括処理を呼び出す際のエラー表示 | 佐田 守弘 | 2004/01/02-15:00 |
記事番号24102へのコメント 沼田さん 確認しますが、このフォームは直接開いたフォームですか? それとも一括処理から開いたフォームですか? 直接開いたフォームならば、一括処理ファイルを開くコマンドボタンは正常に動作するはずです。 書かれているエラーが起きたとすると、何か別の原因があるかと思います。 一括処理から開いたフォームでは、別の一括処理ファイルを開く機能が設定されているコマンドボタンは、使えません。 桐ver.9 2004版で簡単なテストをしてみた結果ですが、エラーが表示されるのではなく、 コマンドボタンそのものが使用不能状態になります。 佐田守弘(KS-00119) | |||
24109 | Re:フォームから一括処理を呼び出す際のエラー表示 | 沼田 | 2004/01/02-21:33 |
記事番号24106へのコメント 佐田さん、いつもありがとうございます。 >確認しますが、このフォームは直接開いたフォームですか? >それとも一括処理から開いたフォームですか? このフォームは直接開いています。 ヘルプファイルにも「フォームのコマンドボタンで一括処理ファイルを開いた場合でも同様です」とありますから、 使える機能に一定の制限がかかるとしても、コマンドボタンに一括処理ファイルを開く機能を持たせることは できるはずだと思っています。 しかし、どうしてもエラーが表示されてしまいます。 確かに、何か別の原因があるはずですが、チェックすべき狙い所が分かりません。 ちなみに、悲しげさんからアイデアをいただいていますように、 機能名に「シェル実行」を指定した場合は正常に実行されます。 「シェル実行」を行うということは、もう一つ桐を起動するという意味になるかと思います。 「桐」というプログラムを新たに起動して実行する訳ですから、これは動いて当然とも言えると思います。 しかし、桐は自動実行の方法として履歴を用意したりkevファイルを用意したりしていますし、 一括処理もその一つではないかと思えます。 それが相互に利用出来ないということが理解出来ずにいます。 >一括処理から開いたフォームでは、別の一括処理ファイルを開く機能が設定 >されているコマンドボタンは、使えません。 Ver5世代の桐ではいくつもの一括処理を作っておき、それぞれをサブルーチンとして処理を行き来させる、 ということは良く使った方法でした。 一括処理からメニュー用のフォームを呼び出して、そこから別の一括処理に処理を移す、 のようなことは良く使われるのではないかと思いますが、 これらの処理は一括処理では使えないことになりますね。 このような仕様になっているのでしょうか。 | |||
24110 | 番号訂正 | 悲しげ | 2004/01/02-22:04 |
記事番号24109へのコメント どもっ、沼田さん 先に私が書いたのは、次のエラー KU1028:イベントハンドラまたは手続きの実行中のため一括処理を開始することは できません のことです。 で、【多遊】さんとこの過去ログ83の中の発言番号を間違っていました。(^^;) 正しくはNo.477ではなくNo.4117〜でして、4140〜4145で終わっています。 ついでに云えば、その中で >Ver5世代の桐ではいくつもの一括処理を作っておき、それぞれをサブルーチン >として処理を行き来させる、ということは良く使った方法でした。 >一括処理からメニュー用のフォームを呼び出して、そこから別の一括処理に処 >理を移す、のようなことは良く使われるのではないかと思いますが、これらの >処理は一括処理では使えないことになりますね。 についての言及も存在しています。 「一括処理実行」タイプはそもそも行きっぱなしで戻って来れないものですから、 別桐を立ち上げることに近いものがあるように思えます その辺りをキチッとしたければ、やはり「手続き実行」か「フォーム呼び出し」コマンド (またはモーダルフォーム)を使えばいいんじゃないでしょうか? | |||
24111 | Re:フォームから一括処理を呼び出す際のエラー表示 | KH | 2004/01/02-23:00 |
記事番号24109へのコメント >>一括処理から開いたフォームでは、別の一括処理ファイルを開く機能が設定 >>されているコマンドボタンは、使えません。 > >Ver5世代の桐ではいくつもの一括処理を作っておき、それぞれをサブルーチン >として処理を行き来させる、ということは良く使った方法でした。 >一括処理からメニュー用のフォームを呼び出して、そこから別の一括処理に処 >理を移す、のようなことは良く使われるのではないかと思いますが、これらの >処理は一括処理では使えないことになりますね。 >このような仕様になっているのでしょうか。 > 多分、私が意味を取り違えてなければ可能だと思います。 メインになる一括処理から、メニューとなるフォームから一括処理を実行させることは可能だと思います。 ただし、フォームのコマンドボタンでは「一括処理に戻る」を設定して、メインになる一括処理に戻します。 メインになる一括処理では 繰り返しコマンドとウィンドウ会話コマンドを使用して待ち受けている状態です。 該当の処理のボタンをクリックされたらその処理に分岐し、 そこから別の一括処理に飛んでいき、処理後メインの一括に戻って、 またメニューのフォームで待ち受けている状態になります。 これは、過去ログを「ウィンドウ会話」で検索すれば見つかると思います。 DOSからの移行だと資産を最小限の手間で移行しようとすると どうしてもこういう方法になると思います。 最近のイベント傾向には逆うことになりますが… 勿論イベントも使えますので心配はありません。 お二人のコメントとは違いますが、もし取り違えていたらごめんなさい。 | |||
24114 | Re:フォームから一括処理を呼び出す際のエラー表示 | 沼田 | 2004/01/03-00:56 |
記事番号24111へのコメント KHさん、みなさん、こんばんは。 フォームから何らかの形で一括処理に制御を移したいという要求は、 たぶん、そう突飛な発想でもないように思います。 >....。DOSからの移行だと資産を最小限の手間で移行しようとするとどうしてもこう いう方 >法になると思います。 DOS時代に作ったcmdは、特に表示関係で大幅に異なっていますから、 そのまま使うことはほとんど無理です。 (DOS窓で使うにはちょっと....ですから) しかし、バックグランドでの処理ではそのままコピーして持ってくることも多くありますし、 表示関係の命令が記述されていないcmdもありますので、 これはこのままkevファイルからでも呼び出せそうな予感がしていました。 これは実際には難しいでしょうし、いくつかの工夫が必要だと思っています。 今回の問題は、直接開いたフォームから一括処理を実行する方法、ということになります。 この問題では、実際にエラーが返ってきていますので、この原因が知りたいのです。 悲しげさんからアドバイスをいただいた過去ログなどを見ていますと、 「シェル実行」を使うしかない、というのが結論のように思えます。 事実、「シェル実行」を使えば思ったように動作してくれています。 これは桐V9 sp1の仕様、ということになるのでしょうか。 一方で、佐田さんからは「できるはず」とアドバイスを受けています。 佐田さんの使用環境は、v9 2004版とのことですので、この辺りが違うのかもしれませんね。 エラーを返してくるのは、WinXP 桐V9 sp1 ですから。 もしそうなら、「これが原因なんだ」と納得出来ますから、スッキリするのですが。 | |||
24115 | フォームから一括処理の呼び出し(前半) | 佐田 守弘 | 2004/01/03-04:15 |
記事番号24102へのコメント 沼田さん 悲しげさんとKHさんからもコメントが出ており、いずれも言っている事はほぼ同じだと思います。 ただし、異なるケースの場合についての話も混じっているので、 私なりに整理させて頂き、併せて補足させて頂きます。 まず前提の確認ですが、桐ver.9sp.1との事で、この点が私の確認テストとは違う可能性が有ります。 またフォームは直接開いたものとの事でした。 ●コマンドボタンで一括処理を起動したい 前回も書きましたが、私のテストではフォームを直接開いた場合には、 「開く」<一括処理ファイル名>で可能でした。 試した内容は、他の表を開く一括処理を実行するといった簡単な内容ですが、 一括処理が実行されて、表コマンドによって表が開かれました。 なお、この方法で一括処理ファイルを開いた時には、別プロセスにはならず、 フォームと同じプロセスの桐で実行された様です。 ただしこの方法は、プログラム構造的にいえば、あまり行儀の良い方法ではないのではないかと思います。 一括処理を起動すれば、制御がそちらの方に行ったままになります。 もちろん元のフォームが開かれて残ってますから、戻る事は可能だとは思います。 しかし好ましくは、実行したいコマンドが終ったら、元のフォームに制御を戻すべきでしょう。 それを行うなら、イベントを使って、手続として実行させるのが本来かと思います。 イベントで手続を実行した場合には、その手続が終れば、 元のフォーム編集の状態に戻ります。 特に別のフォームを開くとか、表を表示するといった処理を行わずに、 単にデータ処理を行うだけの手続きであれば、処理を実行 している間も、フォームは表示されたままです。 ●一括処理からフォームを開いた場合 桐ver.7の時代には、イベントが使えなかったので、一括処理からフォームを開く方法が一般的でした。 この場合には、コマンドボタンで何か処理を実行したい場合には、 一度フォームを閉じてもとの一括処理に制御を戻します。 そして戻る際に押されたコマンドボタンに応じた処理を行います。 処理が終った後は、再びフォームウィンドウを開き直す方法でした。 この方法で何も表示しない処理を行わせると、処理中はフォームが閉じている状態になります。 ●別の桐で一括処理を実行するのは 悲しげさん御推奨の方法は、ある意味ではそれしか致し方ない場合と、 敢て現在の桐環境から切り離して、別環境で実行させるために、 もう1つの桐を別プロセスで実行させる時の方法です。 沼田さんも書かれている通り、この方法は互いの環境間でデータの受け渡しが基本的には行われません。 これについては、 「変数の有効範囲についての追加補足-佐田 守弘(1/2-02:10)No.24097」 でも言及しております。 佐田守弘(KS-00119) 長文のため、次に続きます。 | |||
24116 | フォームから一括処理の呼び出し(後半) | 佐田 守弘 | 2004/01/03-04:16 |
記事番号24102へのコメント <続き> ●一括処理実行コマンドで一括処理を実行する場合 沼田さんが、#24109にて、 >Ver5世代の桐ではいくつもの一括処理を作っておき、それぞれをサブルーチン >として処理を行き来させる、ということは良く使った方法でした。 と書かれている部分について補足します。 この機能は、現在の桐でも変わっておりません。全く同じ事が行えます。 しかし現在はその様な事をする必要がなくなった、というのが正しいでしょう。 一括処理実行コマンドで別の一括処理を実行する場合には、現在の一括処理が一度閉じ、 代りに呼び出した一括処理が実行されます。 この場合、実行されている一括処理が入れ替わるので、同じ桐(プロセス)で実行されるはずです。 一括処理で開いていた表も(基本的には)閉じられますから、固有変数は失われます。 変数の値を引継ぎたい場合には、共通変数を使う必要があります。 なお、イベントから一括処理実行コマンドは実行できません。 一括処理実行コマンドが使えるのは、一括処理からだけです。 ●ライブラリを使うのがスマート 上記で、「現在はその様な事をする必要がなくなった」と書きました。 実は独立した一括処理の中にある手続きを実行させたいのであれば、 ライブラリを使うのがスマートでしょう。 ライブラリコマンドは、イベントファイルのメイン部分で実行します。 このコマンドを実行すると、そのイベントに指定した一括処理ファイルがライブラリとして登録されます。 そして、その一括処理の中にある手続き、つまり手続き定義開始から手続き定義終了までの イベントハンドラの形になっている部分が、自身のイベントファイルの中にあるかの様に使えます。 もし、一連の処理を順次行わせるだけの「電車道の一括処理」なら、 全体を手続き定義開始と手続き定義終了コマンドで括ってしまえば良い話です。 全体を手続きとしてしまうと、その一括処理は単独では動かせなくなります。 単独でも動かしたいなら、先頭に手続き実行コマンドを付ければ良いでしょう。 佐田守弘(KS-00119) | |||
24119 | Re:フォームから一括処理の呼び出し(後半) | 沼田 | 2004/01/03-10:32 |
記事番号24116へのコメント 佐田さん、いつも丁寧な解説をありがとうございます。 フォームに置いたコマンドボタンから一括処理を実行させる方法については、 桐のバージョンに影響されるのかもしれません。 現在の環境はVer9 2004版ではありませんので、バージョンアップ後に試してみようと思います。 ありがとうございました。 | |||
24121 | Re:フォームから一括処理を呼び出す際のエラー表示 | うにん | 2004/01/03-16:11 |
記事番号24109へのコメント >Ver5世代の桐ではいくつもの一括処理を作っておき、それぞれをサブルーチン >として処理を行き来させる、ということは良く使った方法でした。 >一括処理からメニュー用のフォームを呼び出して、そこから別の一括処理に処 >理を移す、のようなことは良く使われるのではないかと思いますが、これらの >処理は一括処理では使えないことになりますね。 >このような仕様になっているのでしょうか。 そうでしょう。今のバージョンでは「一括処理実行」ではなく 「ライブラリ」と「手続き実行」を使います。 | |||
24144 | Re:フォームから一括処理を呼び出す際のエラー表示 | 悲しげ | 2004/01/04-13:18 |
記事番号24121へのコメント >そうでしょう。今のバージョンでは「一括処理実行」ではなく >「ライブラリ」と「手続き実行」を使います。 最新のこの発言にぶら下げて、個人的(独善的)な感想を書きます。(^^;) 例えば、親一括処理としての"メニュー的.cmd"から、子一括処理として "a.cmd"や"b.cmd"や・・・を「一括処理実行」させ、各子一括処理からは"メニュー的.cmd"を 「一括処理実行」(必要なら「名札」指定)させて親一括処理に戻るやり方は、 私もDOS時にはしばしば利用したものです。 ところで、サブルーチンの呼び出し方としては「分岐」タイプと「手続き実行」タイプがある訳ですが、 一般的には後者の方を使うべきだ、と私は習って来ました。 いわく、「分岐」は行きっぱなしなので、戻るためには再び呼び出し元の記述(の前後)の 「名札」に「分岐」させる必要がある。 片や「手続き実行」の方は、呼び出し元の記述の次の行に自動的に戻ってくれる。 と云う訳で、最初はほとんど「分岐」オンリーで桐の一括処理をスタートした私も、 ある時期以降はなるべく「分岐」は使わずに「手続き実行」の方でやるようにスタイルを変更して来ました。 しかし「一括処理実行」だけは、これは明らかに「分岐」タイプです。 ではなぜDOS桐でしばしば「一括処理実行」を使っていたかと、 改めて考えるに、それは何と云っても「長大一括処理の分割」のためだったと思います。 長大になると「名札数制限」の恐れがあることや、 何よりもひとつの一括処理で何でもかんでも記述することによる「見通しの悪さ」などへの対策としてですね。 だから「好んで」と云うよりは「仕方なく」使っていたのだと(今になっては)思います。 ついでに云えば、だから「ライブラリ」コマンドは、当時の私としては「希望の星」のひとつでもありました。 これがWin桐(特にイベント系)になると、話は全く異なってきまして、 「名札数制限」の心配は殆ど無いに等しくなったこと、のみならず「長大一括処理の分割」をするまでもなく、 個々の処理がwfm-kev毎に有無を云わさず分割される(せざるを得ない?)。 ゆえに「一括処理実行」の出る幕が無くなった、と私は得心しました。 もひとつついでに云えば、諸々の試行の仮定で「フォーム呼び出し」は 一種の(ファイル単位の)「手続き実行」と考えればよいと云う「悟りの境地」(^^;)にも到達できたりしました。 これでファイル内外を貫いて「手続き実行」タイプで通すことができるようになりました。 (非モーダルフォームでの組み方はまた別問題となるので今回は触れず) ちなみに「ライブラリ」コマンドは、実際に使ってみるとさほど「期待の星」でもありませんでした。 私にとっては、少なくともDOS時の「一括処理実行」の代わりにはなりませんでした。 なぜなら前述の「名札数制限」の関係から。 それともしその一括処理が1回しか使わないものであれば、 特に「ライブラリ」として読み込むまでもなく、自cmd(またはkev)内に直接記述してしまった方が 経験的にメンテがしやすいこと。 かくして、「ライブラリ」コマンドは、複数のフォームなどで共用する場合だけに限定使用することにしました。 それでも、場合によっては自kevに記述してしまった方がメンテが楽かなとの思いは有ったりしますし、 本格的には「ライブラリ」コマンドではなく、別wfm-kevを共用的に「フォーム呼び出し」して処理させる方が多いです。 ps. 「シェル実行」での別桐起動によるcmdの実行は、佐田さんが#24115で仰るとおり、 私も「それしか致し方ない場合」などで使っています。 例えば印刷プレビューが、イベントハンドラやフォーム呼び出し=モーダルフォームでは使えないことへの対策とか、 データを表示するだけなので諸々手抜きをしたい時とか、ですね。(^^;) |