(現在 過去ログ16 を表示中)
HOME
HELP
新規作成
新着記事
トピック表示
ファイル一覧
検索
過去ログ
[
最新記事及び返信フォームをトピックトップへ
]
[ トピック内全17記事(1-17 表示) ] <<
0
>>
■2339
/ inTopicNo.1)
手続き定義の引数について
▼
■
□投稿者/ 沼田
-(2007/03/31(Sat) 17:42:17)
いつもお世話になっています。V9sp1を使っています。緊急の質問ではありませんが、今後のために教えて頂きたいと思っています。
手続き定義開始コマンドを書く時、引数を定義することが出来ます。
カーソルの座標などに基づいて何かの処理をさせるなどの場合でしたら引数で座標を受け取る必要があるでしょうが、イベントのメイン部で宣言した変数などにフォームから値を与え、その値を使って手続きをさせるような場合でしたら、引数で変数値を渡す必要はないように思えます。
この理解で正しければ良いんですが、例えばできるだけ引数で渡して手続き内の処理をさせる方が良いということであれば、具体的な事例などを教えていただければ嬉しいと思います。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2340
/ inTopicNo.2)
独立性の高い手続きを作る
▲
▼
■
□投稿者/ ONnoji
-(2007/03/31(Sat) 18:18:30)
2007/03/31(Sat) 22:20:25 編集(投稿者)
2007/03/31(Sat) 21:05:27 編集(投稿者)
2007/03/31(Sat) 20:44:51 編集(投稿者)
2007/03/31(Sat) 20:30:47 編集(投稿者)
> 手続き定義開始コマンドを書く時、引数を定義することが出来ます。
> カーソルの座標などに基づいて何かの処理をさせるなどの場合でしたら引数で座標を受け取る必要があるでしょうが、
> イベントのメイン部で宣言した変数などにフォームから値を与え、その値を使って手続きをさせるような場合でしたら、
> 引数で変数値を渡す必要はないように思えます。
引数を使わなくても実行できるならば、それで差し支えないですよ。
引数を使う場合には、
引数と仮引数が同名でなくてもよいところが便利なところですよ。
したがって、引数を仮引数に受け取って動作する手続きならば、引数の変数名が突然変わっても問題がありません。
手続き内で共通・固有・局所変数などを参照していない場合には、
独立性の高い手続きを作ることが出来るという点が有用なところですね。
「独立性の高い手続き」とは、すなわち「ブラックボックス」として使える手続きという意味です。
オマケとしては、[トレース出力]ウィンドウで出力結果を見たときに、引き渡す値が見えるので便利な点もありますよ。
■参考
フォームアプリケーション入門|手続き定義開始の中に書いてある引数がよく解りません
http://www.geocities.jp/siliconvalley_bay_7565/Question_and_Answer.htm
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2341
/ inTopicNo.3)
Re[1]: 手続き定義の引数について
▲
▼
■
□投稿者/ 今村 誠
-(2007/03/31(Sat) 19:00:51)
沼田さんこんにちは
> イベントのメイン部で宣言した変数などにフォームから値を与え、
> その値を使って手続きをさせるような場合でしたら、引数で変数値
> を渡す必要はないように思えます。
> この理解で正しければ良いんですが、例えばできるだけ引数で渡し
> て手続き内の処理をさせる方が良い。
引数を渡して手続きで自動を宣言してぴったりくる名前の変数に替えると
見通しはいいと思います。
ボタンで印刷させる場合は、レポートファイル名を定数を渡して受け取っ
た手続きで自動変数&Sreportname等で受け取ると分かり易いとおもいます。
全てのボタンに付ける引数になる定数部分を局所変数で定義するのは、
労力を使うので、どれがどれの変数だったのか忘れたりします。
今回の処理では、検索の引数として渡さなくてもボタンの部分で代入する
だけで&Lnowを&Lcountに変更すれば動作します。
先日局所変数の値をフォーム間で受け渡しをする処理を作っていたのですが
&実行リターンで受け渡しをしようとしたら受け渡しできるフォームとできない
フォームがあるので原因の解明は迷宮入りです。
おそらく表の計算式やボタンのどこかに使っていると思いますが、たくさん
使っているシーンがあるので探すより絶対使っていないであろう組み込み変数
に変更しました。
手続きに入った後は確認が取れるので、なるべく局所変数の記述ヶ所を減らす
ことでエラーが減ったり、見通しが良くなったり、ケース分けしなくていいの
であれば自動変数を減らすことより引数を多用する方を私は選びます。
組み込み変数や共通変数を便利だからと使いすぎるより、手続きに入ってから
自動の変数を宣言して、終了状態の取得や状態に合わせたメッセージパターンを
増やしていくと自動変数も便利になると思います。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2342
/ inTopicNo.4)
モジュール強度とモジュール結合度
▲
▼
■
□投稿者/ ONnoji
-(2007/03/31(Sat) 20:23:01)
引数を使う意味を考える時には、
「構造化プログラミング」で提唱された、
「モジュール強度」と「モジュール結合度」という概念を知っておくと良いですよ。
※参考 URL
プログラム作成|モジュール設計
・モジュール強度(凝集度) Module strength / Module cohesion
・モジュール結合度 Module coupling
http://www.netlaputa.ne.jp/~hijk/study/pe/program.htm#A03
凝集度と結合度について
・凝集度(コヒージョン)
・結合度(カップリング)
http://homepage3.nifty.com/koha_hp/KeyWords/KW.Coupling.html
設計におけるオブジェクトの責務分配に有効なものさし
― 凝集度と結合度 ―
http://www.ogis-ri.co.jp/otc/hiroba/technical/Cohesion_Coupling/Cohesion_Coupling.html
桐の釣魚大全|手続きの引数
http://blogs.yahoo.co.jp/siliconvalley_bay_7565/2566291.html
【引用】
■桐の釣魚大全 − 手続きの引数
「引数」と聞いただけで、腰が引けてしまう人がいるかもしれません。
でも桐の「関数」を利用したことがある人ならば、「引数」を使っているはずです。
そう!「関数名のカッコ」の中に書くあれです。
※「引数」がない「関数」もあります。
「イベントハンドラ」には「引数」があるのが普通です。
※「引数」がない「イベントハンドラ」もあります。
同様に「一般手続き」にも「引数」が使えます。
「手続きの引数」というのは「DOS桐」にはありませんでした。これはちょっと不便だったんです。
「手続きの引数」はプログラミングの常識なのですが、遅ればせながら「Win桐」で実現したわけです。
「一般手続き」において常に「引数」を使う必要はないのですが、「引数」を使うと便利な場合が多いのです。
要はケースバイケースでして、「引数」を使う使わないの見極めることが重要です。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2344
/ inTopicNo.5)
Re[3]: 過去ログ
▲
▼
■
□投稿者/ ONnoji
-(2007/04/02(Mon) 10:57:36)
過去の桐井戸端BBS (桐ver.8)
11363 手続き定義開始の中に書いてある引数がよく解りません 2001/05/28-08:14
http://www.fuku3.com/~habata/kbbs/kakov8/11363.htm
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2345
/ inTopicNo.6)
Re[3]: フォームの引数
▲
▼
■
□投稿者/ 尾形
-(2007/04/02(Mon) 12:48:46)
便乗質問お願いします
A.WFMを開く時、コード番号○○、を指定してあけたい時の
定石、お作法ってどんな感じなのでしょうか
ついでにいえば、引数を複数指定したいのですが
例えば、コード○○,50音順 みたいな感じで
よろしくお願いします
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2346
/ inTopicNo.7)
フォームに引数はありません
▲
▼
■
□投稿者/ ONnoji
-(2007/04/02(Mon) 14:02:13)
> 便乗質問お願いします
> A.WFMを開く時、コード番号○○、を指定してあけたい時の
> 定石、お作法ってどんな感じなのでしょうか
> ついでにいえば、引数を複数指定したいのですが
> 例えば、コード○○,50音順 みたいな感じで
これって今村さんに対する質問ですか???。
一応、私のご返事ですが・・・、
フォームには引数も仮引数リストもありませんけれど・・・???。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2347
/ inTopicNo.8)
Re[4]: フォームの引数
▲
▼
■
□投稿者/ ただの初心者
-(2007/04/02(Mon) 15:14:01)
私が尾形さんの質問にRESをつけるのはおかしいのですが、ま、経験談としていわせてください。
固有変数を使って、フォームを開く前に定義しておくか、メイン部分で変数読込みを使うかじゃないでしょうか。ちなみに変数読込みはどこでも(フォーム開始イベント)使えるみたいです。
多数の変数を使うのは桐ではできないんじゃないかと思います。たしか以前1000くらいの要素数の変数を定義したら、すぐオーバーフローしました。私は要素数はせいぜい200くらいだと思っています。変数が使えないとするとテーブルしかないんじゃないでしょうか。以前なぜ作業用テーブルが必要なんだと詰問され、スルーしたことがありますが、変数の代わりにテーブルを使うというのも一つの理由です。
ちなみに私のプログラミングの経験は、桐以前は、エクセルのVBAと一太郎のマクロしかありません。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2348
/ inTopicNo.9)
Re[5]: フォームに引数はありません
▲
▼
■
□投稿者/ 尾形
-(2007/04/02(Mon) 16:04:18)
どうも、すいません
自分としては一応、ONnojiさんにお尋ねしたつもりでした
ONnojiさんはこのあたりの事にとても詳しそうなので
なにか定石みたいなのがあるのかなぁ、と思いまして
どうも失礼しました
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2349
/ inTopicNo.10)
[開始時実行コマンド]ボタン
▲
▼
■
□投稿者/ ONnoji
-(2007/04/02(Mon) 16:23:55)
2007/04/02(Mon) 16:26:35 編集(投稿者)
> 自分としては一応、ONnojiさんにお尋ねしたつもりでした
> ONnojiさんはこのあたりの事にとても詳しそうなので
> なにか定石みたいなのがあるのかなぁ、と思いまして
私へのご質問でしたか、失礼しました。(^^ゞ
[フォーム開始]イベントか[開始時実行コマンド]ボタンで処理すると良いではないでしょうか。
私の場合、[開始時実行コマンド]ボタンで、一般手続きを呼び出しています。
※実際には[タイマー2]イベントでコマンドボタンの[実行]メソッドを使っていますが・・・。
処理する際に参照する値は、組み込み変数でもOKでしょうし、
別のフォームの局所変数の値を参照してもOKです。
※私の場合は、別のフォームの局所変数の値を参照しています。
※それ以外に、自身のフォームの局所変数の値を保存したテキストファイルを読み込んで、処理する場合もあります。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2350
/ inTopicNo.11)
Re[5]: フォームの引数
▲
▼
■
□投稿者/ うにん
-(2007/04/02(Mon) 20:29:09)
多数の変数を使うのは桐ではできないんじゃないかと思います。たしか以前1000くらいの要素数の変数を定義したら、すぐオーバーフローしました。私は要素数はせいぜい200くらいだと思っています。
組み込み変数+共通変数:128 KB(最大)
固有変数:256 KB(最大)
自動変数+局所変数:フォームウィンドウ単位で 512 KB(最大)
ですから、長い文字列を変数に入れたらすぐあふれますね。
(最大でなくデフォルトは64KB)
データベースですから、普通はそんなにたくさん変数が必要にはなりません。
変数より、データベースサイズをどうにかして欲しいT_T
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2351
/ inTopicNo.12)
Re[7]: [開始時実行コマンド]ボタン
▲
▼
■
□投稿者/ 尾形
-(2007/04/03(Tue) 07:59:34)
どうも、ありがとうございます
やはりこのあたりの方法なのですね
複数の値を参照させたい時がパニくってしまうのでした
> ※私の場合は、別のフォームの局所変数の値を参照しています。
この方法を参考にさせて頂きます
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2358
/ inTopicNo.13)
Re[2]: 手続き定義の引数について
▲
▼
■
□投稿者/ 沼田
-(2007/04/04(Wed) 00:13:46)
今村さん、ありがとうございます。
> 全てのボタンに付ける引数になる定数部分を局所変数で定義するのは、
> 労力を使うので、どれがどれの変数だったのか忘れたりします。
今まで色んな場面で悩んできましたが、たぶんここあたりが一番苦労したところでしょう。
後で混乱しないように覚えておきやすい変数名にした方が良いのは分かっていますが、だからといってやたらと長い変数名にしてしまうと、プログラムそのものを後で見直した時には、余計に訳が分からなくなります。
全く、滑稽です。
引数っていうのは、これを解決させる働きの方が多いのかもしれません。
手続きはサブルーチンですから、いくつかの場面から呼び出される場合が多いと思いますが、元のルーチンでの変数名を手続き内でも使おうとしますから、どちらででも理解しやすい変数名にしようと、つまらないところで時間を取られてしまうことも良くあります。無駄ですね。
引数は、こんな無駄を省いてくれる機能だと思えば良いんですね。
何か、スッキリしたような気がします。ありがとうございました。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2359
/ inTopicNo.14)
Re[3]: モジュール強度とモジュール結合度
▲
▼
■
□投稿者/ 沼田
-(2007/04/04(Wed) 00:40:09)
ONnojiさん、みなさん、いつもありがとうございます。
モジュール設計という観点が重要だと言うことは、いくつかのプログラムの中で手続きを書いていく中で感覚的に分かってきました。
仲間の中でイベントが分かりにくいと言う人がいます。cmdで書いていけば、内容を順に追っていけば流れが分かるのに、kevで書かれていると何がどうなっているのか分からない、というのです。
オブジェクトの責務分配まで行くと理解するのに骨も折れますが、モジュール強度というのは何となく分かります。
イベントはその状況に応じた手続きを、その必要な時にだけ呼び出す部品のようなものでしょう。たぶんこれが独立したモジュールという概念じゃないかなと感じています。
プログラム全体の中で、そのイベントがどの程度の処理を受け持っているのか、その軽重を評価するのがモジュール設計?、そんな気がします。
この評価がきちんとできれば、無駄な手続きも減らせるし、無駄に変数でメモリを消費することも抑えられる、ということなんでしょうね。
手続き実行コマンドに限らず、引数をうまく使うことで効率の良いプログラムを書くことが出来るということなんだろうなと感じました。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2363
/ inTopicNo.15)
後で読み返したときに理解し易いモジュール
▲
▼
■
□投稿者/ ONnoji
-(2007/04/04(Wed) 07:37:27)
http://www.geocities.jp/siliconvalley_bay_7565/kakko_log.htm
2007/04/04(Wed) 09:36:40 編集(投稿者)
2007/04/04(Wed) 09:15:18 編集(投稿者)
2007/04/04(Wed) 09:14:11 編集(投稿者)
2007/04/04(Wed) 09:09:22 編集(投稿者)
> モジュール設計という観点が重要だと言うことは、いくつかのプログラムの中で手続きを書いていく中で感覚的に分かってきました。
> 仲間の中でイベントが分かりにくいと言う人がいます。cmdで書いていけば、内容を順に追っていけば流れが分かるのに、kevで書かれていると何がどうなっているのか分からない、というのです。
イベントは発生する順番を[トレース出力]ウインドウで確認しない限り、実際の挙動は確かめられません。
頭の中で想像したとおりに、イベントが発生しているとは限りません。
だから、[トレース出力]ウインドウの出力結果を参照することが非常に重要だと思います。
> オブジェクトの責務分配まで行くと理解するのに骨も折れますが、モジュール強度というのは何となく分かります。
> イベントはその状況に応じた手続きを、その必要な時にだけ呼び出す部品のようなものでしょう。たぶんこれが独立したモジュールという概念じゃないかなと感じています。
> プログラム全体の中で、そのイベントがどの程度の処理を受け持っているのか、その軽重を評価するのがモジュール設計?、そんな気がします。
モジュールとは、ある機能を有したプログラムの単位とも言えるでしょう。
桐の場合は、[手続き定義開始]...[手続き定義終了]で定義される一般手続き・イベントハンドラです。
モジュールの機能は1つだけにします。これが望ましいモジュール強度です。
※機能的強度 (functional) 単一の固有機能を実行する。 外界とは機能のみが共有されている。
モジュールは(出来るだけ、)引数で呼び出すのが望ましいです。
※データ結合 (data) 二つのモジュール間のインタフェースをデータ要素の 受け渡しのみで行う。
※相手のモジュールをブラックボックス化できる。 定義されている構造体のメンバのうち、 必要なものだけを下位関数に渡すなど。
※モジュール結合度が最も低く、互いのモジュールが影響を受けにくくなる。
> この評価がきちんとできれば、無駄な手続きも減らせるし、無駄に変数でメモリを消費することも抑えられる、ということなんでしょうね。
> 手続き実行コマンドに限らず、引数をうまく使うことで効率の良いプログラムを書くことが出来るということなんだろうなと感じました。
プログラムの設計で一番重要なことは、
・後で読み返したときに理解し易いモジュール
・(理解し易いゆえに、)修正し易いモジュール
・(独立性があるゆえに、)再利用できるモジュール
だと思います。
これらは、構造化プログラミングの最も基本的な考え方ですよ。
なお、これは上の3点の裏返しの
・後で読み返したときに、サッパリ分からないモジュール
・(理解し難いゆえに、)修正し難いモジュール
・(独立性が無いゆえに、)再利用できないモジュール
を考えてみればわかります。
うんと昔にこれらの反省から、構造化プログラミングが提唱されたというわけです。
ちなみに、「効率や無駄を省く」という考え方は、
「後で読み返したときに理解し易いモジュールを作る」こととは直接関係ありませんよ。
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2365
/ inTopicNo.16)
イベントとイベントハンドラとモジュール
▲
▼
■
□投稿者/ ONnoji
-(2007/04/04(Wed) 13:21:31)
2007/04/06(Fri) 08:18:46 編集(投稿者)
2007/04/04(Wed) 13:28:49 編集(投稿者)
> モジュール強度というのは何となく分かります。
モジュールとは、ある機能を有したプログラムの単位とも言えるでしょう。
桐の場合は、[手続き定義開始]...[手続き定義終了]で定義される一般手続き・イベントハンドラです。
モジュール強度で望ましいのは、あれもこれもと欲張らずに、
ひとつの機能 = ひとつのモジュール
とすることです。
> イベントはその状況に応じた手続きを、その必要な時にだけ呼び出す部品のようなものでしょう。
「イベント(発生)」と「イベントハンドラ(起点)」と「モジュール(機能)」は区別したほうがいいですよ。
反射神経のように、「イベント」が発生します。
例えば、だれかに足を踏まれたら、痛いと感じるでしょう〜。
これはイベントの発生と同じです。
その時、思わず声を上げるとします。
この部分が、「発生したイベントに対応して呼び出されるイベントハンドラ」になります。
イベントハンドラもモジュールと呼べなくはないですが、イベントハンドラはただの起点・出発点とする方がよいです。
つまり、イベントハンドラ(起点)から、別途用意したモジュール(機能)を呼び出すというわけです。
なぜならば、イベントハンドラの手続き名はどのフォームでも同一なので、これをモジュール(機能)として扱うには難があります。
しかし、急いでいるときや、簡単な内容の場合は、イベントハンドラに処理内容を記述してしてしまうこともありますが、
基本的には、イベントハンドラは、動作の起点・出発点と考えるのがよいと思います。
例えば、「痛い!」と日本語で声を上げるか?、「オーマイゴッド!」と英語で声を上げるか?の違いがありますが、
これは、イベントハンドラ(起点)が呼び出すモジュール(機能)が違うか、
または、イベントハンドラ(起点)が呼び出すモジュール(機能)が同じでも引数が違うことに相当します。
> たぶんこれが独立したモジュールという概念じゃないかなと感じています。
私が申し上げたかった「独立したモジュール」というのは、
そっくりそのまま、別のイベント( .kev )に貼り付けて即使用できるモジュール(機能)のことです。
こういうモジュール(機能)は、引数で呼び出すようになっています。
> プログラム全体の中で、そのイベントがどの程度の処理を受け持っているのか、その軽重を評価するのがモジュール設計?、そんな気がします。
モジュール設計に関しては、構造化プログラミングの参考書か、インターネットをご参考にしてください。
私がお勧めする構造化プログラミングの参考書は、ストラクチャード・プログラミング入門〔改訂2版〕です。
↓
かっこうログ
http://www.geocities.jp/siliconvalley_bay_7565/kakko_log.htm
引用返信
[メール受信/OFF]
削除キー/
編集
削除
■2368
/ inTopicNo.17)
Re[1]: 手続き定義の引数について
▲
▼
■
□投稿者/ アックン
-(2007/04/04(Wed) 13:59:11)
沼田さん
具体例でしたら、桐CDに入っている「桐てんぷとDM」のkevとcmdがわかりやすくていいと思いますよ。
アックン(=^・^=)
引用返信
[メール受信/OFF]
削除キー/
編集
削除
トピック内ページ移動 / <<
0
>>
このトピックに書きこむ
過去ログには書き込み不可
Mode/
通常管理
表示許可
Pass/
HOME
HELP
新規作成
新着記事
トピック表示
ファイル一覧
検索
過去ログ
-
Child Tree
-
-
Antispam Version
-