桐質問掲示板 [One Topic All View / Re[2]: 無効なウインドウハンドルについて / Page: 0]

(現在過去ログ64 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■9923 / inTopicNo.1)

　無効なウインドウハンドルについて

□投稿者/ モモンガ -(2016/06/22(Wed) 20:21:24)

無効なウインドウハンドルについて過去の履歴を調べましたが
解決できませんでしたので質問させてください。

現象としては、
一括処理においてメニューから表形式編集（画面２ボタン）を実行すると、
メニューのウインドウ会話（15行目）で「無効なｳｨﾝﾄﾞｳﾊﾝﾄﾞﾙです」が
表示され、エラーとなってしまう。（添付ファイル参照）

ハンドル名は変更していないので無効になってしまう理由がわからないです。
表形式編集を使用する際に注意しなければいけない事があるのでしょうか？

因みに画面１ボタンは編集画面でこちらは正常に動作します。

単純な見落としかもしれませんが、どなたかご教授願います。

20160622.zip/19KB

引用返信 [メール受信/OFF] 削除キー/

■9925 / inTopicNo.2)

　Re[1]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ Vision Maker -(2016/06/22(Wed) 21:05:33)

よくわからないんですが、メニューをメニュー開始にしたらエラーが出ませんでした。

> 表示され、エラーとなってしまう。（添付ファイル参照）

分岐(&釦[1]>"" .and &釦[1]<>"終了")　　　　　メニュー開始

引用返信 [メール受信/OFF] 削除キー/

■9926 / inTopicNo.3)

　Re[1]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ ONnoji -(2016/06/22(Wed) 22:58:24)

2016/06/23(Thu) 13:23:08 編集(投稿者)
2016/06/22(Wed) 23:19:48 編集(投稿者)
2016/06/22(Wed) 23:17:47 編集(投稿者)
2016/06/22(Wed) 23:08:34 編集(投稿者)

一般手続き：sub2()から復帰した時に、

"メニュー.WFM"のウィンドウが無くなっているのが原因だと思います。

※ステップ実行すると判ります。
※または、［画面２］ボタンを実行する前に、"メニュー.WFM"を少し移動させておくと判ります。
※"メニュー.WFM"を少し移動させておかないとリドロウされずに残像が残ったように見えます。

ウィンドウ作成　"メニュー.WFM",ハンドル=&枠[1]

を追加すればよろしいかと･･･。

※私は一括処理でアプリケーションを作らないので外しているかもしれません。
※外していたらスイマセン。

手続き定義開始　sub2()
＊－－－－－－－－－＋－－－－－－－－－＋－－－－－－－－－＋－－－－－－－－－＋－－

　　　　表　"テーブル2.TBL",モード=専有
　　　　表形式編集　更新=禁止,画面消去=する,許可作業=表示幅+印刷+並び替え+絞り込み+使用フォーム+書き出し
＊ <<帳票とか出力>>
　　　　中止　表　＊
　　　　ウィンドウ作成　"メニュー.WFM",ハンドル=&枠[1]

手続き定義終了

＜追伸＞

老婆心ながら…

イベント処理でアプリケーションを作るのならば、ウィンドウ作成・ウィンドウ会話という処理は不要になり、メインループも不要になります。

Ｗｉｎ桐の一括処理はＤＯＳの桐の拡張なので、ＤＯＳ桐から改造する場合には都合が良いかも知れませんが、
旧来のバッチ処理のようにメインループを書かざるを得ないので、
Ｗｉｎｄｏｗｓ時代のイベントドリブンのプログラミングとは大きく異なります。

おそらく、今回は依頼主から一括処理で作成するように指定されているのかと思いますが、
次に桐でアプリケーションを作成する場合には、フォームの機能とイベント処理だけで作成することをオススメします。

引用返信 [メール受信/OFF] 削除キー/

■9927 / inTopicNo.4)

　Re[1]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ まさやん -(2016/06/23(Thu) 12:02:33)

> 一括処理においてメニューから表形式編集（画面２ボタン）を実行すると、
> メニューのウインドウ会話（15行目）で「無効なｳｨﾝﾄﾞｳﾊﾝﾄﾞﾙです」が
> 表示され、エラーとなってしまう。（添付ファイル参照）
>

表形式編集　更新=禁止,画面消去=しない,許可作業=表示幅+印刷+並び替え+絞り込み+使用フォーム+書き出し

画面消去＝しない　　では　どうでしょか？

引用返信 [メール受信/OFF] 削除キー/

■9928 / inTopicNo.5)

　Re[2]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ まさやん -(2016/06/23(Thu) 12:22:45)

> 次に桐でアプリケーションを作成する場合には、イベント処理だけで作成することをオススメします。

この場を借りて失礼します。

私もイベントを組んだことがないのですが、

売上　仕入　会計(仕訳)　などの業務を連携して組む場合
(データの処理においてリアルタイムにデータが変動するなど)
イベントのほうがいいでしょうか？

引用返信 [メール受信/OFF] 削除キー/

■9943 / inTopicNo.6)

　Re[3]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ モモンガ -(2016/06/24(Fri) 09:56:07)

ONnojiさん

回答ありがとうございます。

>一般手続き：sub2()から復帰した時に、
>"メニュー.WFM"のウィンドウが無くなっているのが原因だと思います。

ご指摘の通りメニューが消えてしまっていました。

>表形式編集　更新=禁止,画面消去=しない,許可作業=表示幅+印刷+並び替え+絞り込み+使用フォーム+書き出し
>画面消去＝しない　　では　どうでしょか？

まさやんさんにご指摘頂いた「画面消去＝しない」とすることで解決いたしました。

>Ｗｉｎ桐の一括処理はＤＯＳの桐の拡張なので、ＤＯＳ桐から改造する場合には都合が良いかも知れませんが、
>旧来のバッチ処理のようにメインループを書かざるを得ないので、
>Ｗｉｎｄｏｗｓ時代のイベントドリブンのプログラミングとは大きく異なります。

やはり一括処理は現行の桐では一般的ではないのですね。
なんとなくCOBOLを想起させられる作りだったので・・・・

>おそらく、今回は依頼主から一括処理で作成するように指定されているのかと思いますが、
>次に桐でアプリケーションを作成する場合には、フォームの機能とイベント処理だけで作成することをオススメします。

現行システムの引継ぎと改善が今回の作業となるので今回は難しいですね＾＾；
時間があればＤＢ周りから設計をやり直したいです。
因みにテーブル定義の参照条件に変数を定義したりする行為はあまりしないでしょうか？
一括処理の実行し桐を閉じない状態でテーブルを表示しないと、
変数が消えてしまうのでテーブルを直接開くことができない作りになっています。

あと、イベントを中心に開発する場合は、一括処理は一切使わないような作りになるのでしょうか？
今回のサンプルの場合ですとメニューのイベントに共通宣言を入れておき、
起動も「メニュー.wfm」を実行というイメージであっているでしょうか？

引用返信 [メール受信/OFF] 削除キー/

■9944 / inTopicNo.7)

　Re[2]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ モモンガ -(2016/06/24(Fri) 09:58:57)

まさやんさん

ご指摘の通り修正したら正常に動作しました。
表形式編集の画面だけが消去されるものだと思い込んでいたようです。

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

解決済み!

引用返信 [メール受信/OFF] 削除キー/

■9945 / inTopicNo.8)

　Re[4]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ たゆー -(2016/06/24(Fri) 10:54:31)

>あと、イベントを中心に開発する場合は、一括処理は一切使わないような作りになるのでしょうか？
作り方や構造にもよりますが、フォームが複数に成り、イベントも増えてきたら、
同じような処理を、複数のイベントに書かず、一括処理に記載しライブラリとして
利用する場合もあります。

引用返信 [メール受信/OFF] 削除キー/

■9946 / inTopicNo.9)

　Re[2]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ モモンガ -(2016/06/24(Fri) 10:55:54)

Vision Makerさん

表形式編集を実行した際に、メニューの画面がクローズされてしまう事が
原因だったようです。

ご指摘の通り、メニュー開始へジャンプさせることで、
メニューが再表示されるので正常に動作しました。

ありがとうございます。

解決済み!

引用返信 [メール受信/OFF] 削除キー/

■9947 / inTopicNo.10)

　Re[5]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ モモンガ -(2016/06/24(Fri) 11:30:38)

たゆーさん

なるほど～
確かにライブラリの場合は必要ですね＾＾；

本来というか現行の桐（９や１０）での一般的な作り方というのは、
ＶＢなどに近い考え方で進めればよさそうですね。

ただ、フォームなどで使用できるイベントの種類がＶＢと比べ
少ない気がする（だけかも）ので、不明な時はまた教えて下さい。

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

解決済み!

引用返信 [メール受信/OFF] 削除キー/

■9948 / inTopicNo.11)

　Re[6]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ ONnoji -(2016/06/24(Fri) 11:42:45)

2016/06/24(Fri) 12:28:03 編集(投稿者)
2016/06/24(Fri) 12:25:04 編集(投稿者)
2016/06/24(Fri) 12:23:40 編集(投稿者)

> >一般手続き：sub2()から復帰した時に、
> >"メニュー.WFM"のウィンドウが無くなっているのが原因だと思います。
>
> ご指摘の通りメニューが消えてしまっていました。
>
> >表形式編集　更新=禁止,画面消去=しない,許可作業=表示幅+印刷+並び替え+絞り込み+使用フォーム+書き出し
> >画面消去＝しない　　では　どうでしょか？
>
> まさやんさんにご指摘頂いた「画面消去＝しない」とすることで解決いたしました。

なるほど、この場合には画面消去=しないが正解ですね。

しかし、画面消去の画面っていった何のことなのか考えてみてください。

これって、ＤＯＳ桐の画面の延長線上であることは間違えないでしょう。

今ではＤＯＳ桐の一括処理が実行されているところを見たことが無い人も多いでしょう。

桐ver.7 の当時に、良かれと思って用意した互換性コマンドが、かえって仇になるんですね。(ーー;)

ＤＯＳ桐の一括処理の画面を見たことがない人にとっては、画面消去の意味が分かるハズがありませんね。

> >Ｗｉｎ桐の一括処理はＤＯＳの桐の拡張なので、ＤＯＳ桐から改造する場合には都合が良いかも知れませんが、
> >旧来のバッチ処理のようにメインループを書かざるを得ないので、
> >Ｗｉｎｄｏｗｓ時代のイベントドリブンのプログラミングとは大きく異なります。
>
> やはり一括処理は現行の桐では一般的ではないのですね。
> なんとなくCOBOLを想起させられる作りだったので・・・・

サンプルを拝見してタイムスリップしたような錯覚に陥りました。

だって名札と分岐でメインループを作っているのですから非常に驚きました。(>_<)

桐のプログラミング言語は、構造化言語なので、なるべくＧＯＴＯを使用しないで記述することをお勧めします。

> 因みにテーブル定義の参照条件に変数を定義したりする行為はあまりしないでしょうか？
> 一括処理の実行し桐を閉じない状態でテーブルを表示しないと、
> 変数が消えてしまうのでテーブルを直接開くことができない作りになっています。

もちろん、いろいろな場面で変数を参照しますが、私はフォームの機能＋イベントファイルなので、

ほぼ１００％フォームの局所変数だけを使っています。

フォームとフォームの間の変数の受け渡しも局所変数を使っています。

ただし、ハンドル番号などごく一部の値は、一時的に組み込み変数に代入して、用が済んだら直ちに元の値に戻しています。

なお、私のように、ほぼ１００％フォームの局所変数だけを運用する人は、極めて少数派です。

※局所変数の受け渡しや、ハンドル番号の参照に関しては、拙作ＨＰで内容を公開しています。

ちなみに、多くの人は固有変数・共通変数・組み込み変数を利用していて、逆に局所変数を使わないことが多いと思います。

> 今回のサンプルの場合ですとメニューのイベントに共通宣言を入れておき、
> 起動も「メニュー.wfm」を実行というイメージであっているでしょうか？

メニュー.wfm を起点にするのでＯＫだと思いますよ。

グローバル変数として、共通変数を使用してもＯＫだと思います。

グローバル変数は上書きの危険性があるので、接頭辞を付けておいた方が安全ですよ。

> あと、イベントを中心に開発する場合は、一括処理は一切使わないような作りになるのでしょうか？

イベントを中心に開発する場合は、一括処理は一切使いません。

桐のアプリケーションには２つのスタイルがあります。

・一括処理( .cmd )のアプリケーション

・フォームの機能＋イベントファイル( .kev )　※ライブラリとして( .cmd )を併用すること有り

フォームの機能＋イベントファイル( .kev )の場合には、通常の一括処理( .cmd )は一切利用しません。

なお、拡張子が .cmd なので非常に紛らわしいですが、

ライブラリとして( .cmd )を併用することが有ります。

これはイベントファイル( .kev )の一般手続き（場合によってはイベントハンドラも含む）を、

ライブラリとして( .cmd )に保存したものです。

従って、ライブラリは実行するものではなく、

フォームのイベント処理( .kev )の［名札　メイン］フェーズで［ライブラリ］コマンドで読み込むものです。

＜蛇足＞

今の時点でＷｉｎ桐の一括処理のアプリケーションを稼動させているということは、

ＤＯＳ桐から営々と業務アプリケーションを構築してきたと想像します。

ソフトはハードより堅い。

ハードウェアは簡単にリプレースできるが、ソフトウェアは簡単にリプレースできない。

だから、一括処理のアプリケーションを、フォームの機能＋イベントのアプリケーションに変更するのは至難です。

具体的には、現行の一括処理のアプリケーションと平行して、

フォームの機能＋イベントのアプリケーションを構築・テストすることになるが、

果たしてこの労力に見合うだけの結果が得られるのだろうか？

ここが見極めなければならない重要ポイントです。

労力がかかるがアプリケーションをリプレースする価値があるか？

まさにこの点に尽きるでしょう。

リプレースするべきか？リプレースせざるべきか？？、それが問題だっ！

＜私( ONnoji )がフォームの機能＋イベントのアプリケーションを使う理由＞

一長一短とか、メリットとデメリットとかいう議論はあまり意味がないと思います。

だって、一括処理のアプリケーションでは、一括処理を実行することが出発点であり、

フォームの機能＋イベントのアプリケーションでは、フォームを開くことが出発点である。

このようにそれぞれのスタイルが違うのだから、比べることが無意味で単純に別々のものだと理解すればいいと思います。

ただし、一括処理のアプリケーションが旧来からのバッチ処理と同じなので、

順調に動いている時はいいのですが、ひとたびエラーが発生すると、エラーを起こした一括処理に記述されている機能が実行できなくなります。

一方、フォームの機能＋イベントのアプリケーションでは、それぞれのフォームに機能が分散しているので、

エラーが発生した場合、エラーを起こしたフォーム以外は通常通りに使えることになります。

従って、エラー時の対応やメンテナンスのことを考えるとフォームの機能＋イベントのアプリケーションの方が有利です。

もちろん、Microsoft Visual Basic に似た開発スタイルなのは、フォームの機能＋イベントのアプリケーションなのです。

だから、今さら制限の多いＤＯＳ桐の延長の互換モード満載の一括処理のアプリケーションを作りたいとは決して思わないのでした。

引用返信 [メール受信/OFF] 削除キー/

■9949 / inTopicNo.12)

　Re[7]: 無効なウインドウハンドルについて

▲▼■

□投稿者/ モモンガ -(2016/06/24(Fri) 12:53:35)

ONnojiさん

いつも丁寧に回答してくださりありがとうございます。
やはりフォームの機能＋イベントファイル( .kev )ですかね。

新規で作る画面などについては、フォームの機能＋イベントファイル( .kev )で
作ってみようと思います。

局所変数の受け渡しや、ハンドル番号の参照に関しては、
公開して頂いているＨＰを参考にします。

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

解決済み!

引用返信 [メール受信/OFF] 削除キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

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

HOME HELP 新規作成新着記事トピック表示ファイル一覧検索過去ログ

- Child Tree -
- Antispam Version -