桐の釣魚大全のトップ > 目からウロコのデータベース桐プログラミング入門
トップページに戻る
鋭意校正中です。
念のためにブラウザでＦ５キーを押してリロードしてからお読みください。
目からウロコのデータベース桐プログラミング入門 ― 桐のイベント処理の入門講座の副読本
By ONnoji Copyright (C) 2024
このテキストの内容は、［フォーム＋イベント処理］の初級者向けです。
初級者の前に最初に立ちはだかる難問は、「変数って何ですか〜？」です。
なお、このテキストは拙作ｗｅｂページの「桐の釣魚大全」の
「桐のイベント処理の入門講座」
新 フォームアプリケーション入門 §１
新 フォームアプリケーション入門 §２
の副読本として執筆したものです。
◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇
１ 変数って何ですか〜？
１．１ 数学じゃないよ〜
「変数って何ですか〜？」、これはプログラミングを始めたばかりの人が思う疑問のひとつでしょうね。
そう言えば、学校で大嫌いな数学の時間にお勉強したｘ，ｙ，ｚも変数でしたね。
しかし、プログラミングの場合の変数は数学とは全く関係がありません。
なので、［変数イコール数学］というイメージは頭の中から消してください。
それでは、あらためて変数とは何かと簡単に言うと単純に「メモリー」の事なのでした。
さらにもう少し詳しく言うと、ＰＣに搭載されているメモリーに割り振った［名前付きのメモリー］のことです。
［名前付のメモリー］なので、［名前を指定して【値】を入れる］ことが出来ますし、
［名前を指定して【値】を取り出す］ことも出来るというわけです。
ところで、プログラミングの書籍などでは変数とは［名前が付いた箱］といった比喩（例え話）が見受けられますが、
このような比喩（例え話）は頭の中が混乱するだけなので忘れてください。
１．２ 等式じゃないよ〜
変数は［名前付きのメモリー］ですから、名前を付けてメモリーに割り振る必要があります。
これを、［変数を宣言する］と言います。
具体的には、［変数宣言］コマンドで
変数宣言 局所，文字列｛ &variableName ｝
変数宣言 局所，文字列｛ &変数名 ｝
のようにします。
［変数宣言］はコマンド名ですが、［局所］と［文字列］というキーワードは何でしょうか？
ここでは先に［文字列］キーワードを説明して、［局所］キーワードは［変数のスコープ］の項で後述します。
"文字列"キーワードは変数の［データ型］として "文字列型" を指定する意味になります。
いきなり［データ型］と聞いても驚かないでください。
実は［表ファイル(.tbx)］を定義する時に選ぶ［項目のデータ型］と全く同じ種類なのです。
桐のようなデータベースソフトでは、データベースで指定できる［項目のデータ型］と［変数のデータ型］は１対１で対応するものなのです。
なので、任意のレコード（行）の［項目の【値】］を任意の名前の［変数の【値】］として入れることが出来ます。
変数に【値】を入れることを［代入］と呼びますが、この時に［項目のデータ型］と［変数のデータ型］が一致していなければなりません。
ただし、数値・通貨・長整数・整数のデータ型の場合には、それぞれのデータ型の扱える数値範囲を超えないならば代入出来ます。
具体的には、［代入］コマンドで
代入 &variableName = [名前] ※変数名のアンパサンド(＆)記号は変数であることを示す接頭辞です
代入 &変数名 = [住所] ※項目名を直接（リテラルに）記述する阿合には項目名の前後を角カッコ([])で囲みます
のようにします。
しかし、［代入］コマンドは省略できるので、（また非常に多く使用するのため）
&variableName = [名前]
&変数名 = [住所]
のように［代入］コマンドは省略して書きません。
もちろん、律儀に［代入］コマンドを書いてもＯＫなのですが、Ｗｉｎ桐では［代入］コマンドを省略するのが一般的です。
（注）これは、桐の［代入］コマンド相当のＶＢＡの ［LET］ステートメントで ［LET］を省略するのと同じです。
これまで、任意レコード（行）の［項目の【値】］を任意の名前の［変数］に代入する例を挙げましたが、
任意の名前の［変数］に、任意の【式】の結果である【値】を代入することも出来ます。
具体的には
&variableName = [名前] + "様" ※プラス記号(＋)は、文字列型の値を連結する演算子です
&変数名 = [郵便番号] + " " + [住所]
のように【式】の値を変数に代入できます。
なお、【式】の【値】にもデータ型がありますので、［変数のデータ型］と［【式】の値のデータ型］は一致していなければなりません。
ただし、数値・通貨・長整数・整数のデータ型の場合には、それぞれのデータ型の扱える数値範囲を超えないならば代入出来ます。
このように代入は
&variableName = 【式】(expression) ※expression（英：式、表現）
という形で、左辺の変数に右辺の【式】を代入しますが、これを数学の等式と混同しないようにしてください。
そうです、［変数］は数学の変数ではありませんし、［代入］は数学の等式でもありません。
さらに付け加えるならば［プログラミング］は数学ではありません。
２ 関数ってなんですか〜？
エクセルと同じように桐にも多くの関数が用意されています。
中学校で大嫌いな数学の時間にお勉強した y = ax が一次関数でしたね。
しかし、桐のというよりも、コンピュータの世界の関数は中学校の数学の関数とは形が違います。
桐の関数は次のようなものです。
#数値( 式 ) カッコ内の【式】のデータ型は文字列型です
#文字列( 式 ) カッコ内の【式】のデータ型は数値・通貨・長整数・整数型です
#日時値 【式】を必要としないのでカッコがありません
#日時値( 式 ) カッコ内の【式】のデータ型は文字列型
ちなみに、カッコがある関数と、カッコが無い関数がありますが、ほとんどの関数にはカッコ必要です。
ところで、冒頭でコンピュータの世界の関数は中学の数学の関数とは違いますと紹介しましたけれど、
高校の数学の時間に習った関数の ｆ( x )、ｇ( x ) と恰好がよく似ていますね。
数学の関数とは、任意の【式】を与えると、その式に対応した【値】が決まるというものですから、
エクセルや桐のようなコンピュータの世界の関数も性質は同じです。
これを、関数の［返り値］や［戻り値］と言いますので覚えておいてください。
#数値( 式 ) → 返り値は数値型です
#文字列( 式 ) → 返り値は文字列型です
#日時値 → 返り値は日時型です
#日時値( 式 ) → 返り値は日時型です
また、カッコの中に入れる【式】を関数の［引数］と言います。
【式】が文字列型でも引数というは不思議に感じるかもしれませんが、関数の［引数］とはカッコの中に入れる【式】のことだと覚えてください。
関数は表定義の項目計算式にも使用出来ます。
その際には、表定義の計算項目のデータ型は、項目計算式に指定した式や関数の戻り値と同じにします。
それによって項目計算式の項目には式や関数の戻り値が表示されるというわけです。
なお、変数に関数の戻り値を代入するには次のようにします。
&variableName = #数値( 式 ) ※変数名のアンパサンド(＆)記号は変数であることを示す接頭辞です
&変数名 = #文字列( 式 ) ※関数名のシャープ(＃)記号は関数であることを示す接頭辞です
もちろん、変数には関数以外の式や複数の関数を組み合わせた式も代入できます。
&variableName = 1 + 1
&変数名 = #文字列( 2024 ) + "円" ※プラス記号(＋)は、文字列型の値を連結する演算子です
繰り返しになりますが、これは［代入］コマンドで変数に式の値を代入することです。
しかし、［代入］コマンドは敢えて書かずに省略しますので、見かけが数学の等式のように見えますが、決して数学の等式ではありませんよ。
３ イベント駆動型のプログラミング
今では見ることが無くなったMS-DOS用の桐ver.5でもプログラミングが出来ました。
そうです、一括処理というプログラミング手法です。
その後、MS-Windowsに対応して発売された桐ver.7において一括処理が利用できるようになりました。
この時の一括処理は、MS-DOSの時代に蓄積された桐ユーザのプログラム資産を、そのまま利用できるように工夫されたものでした。
しかし、MS-DOSには矩形をしたMS-Windowsのウィンドウという概念がありませんでした。※矩形（読み）くけい：（意味）長方形・四角形
そこで、桐ver.7の一括処理では矩形をしたMS-Windowsのウィンドウも扱えるように機能が拡張されました。
MS-DOS時代の桐の一括処理コマンドは画面（スクリーン）の縦横の座標を指定するのが特徴です。
画面表示 ( <開始行>, <開始桁> ) - ( <終了行>, <終了桁> ), 式, 左寄せ, 青, 下線, 反転
キー入力 ( <開始行>，<開始桁> ) - ( <終了行>，<終了桁> )，プロンプト = "文字を入力してください", &文字列型の変数
このようにＷｉｎ桐においてもMS-DOSの画面（スクリーン）を再現した一括処理になるので、これを便宜上、古典一括処理コマンドと呼ぶことにします。
しかし、MS-Windowsの高解像度の環境でMS-DOSの画面（スクリーン）を再現するのは、さすがに時代錯誤でMS-Windowsに適合しませんから、
桐ver.7では矩形をしたMS-Windowsのウィンドウを扱えるように拡張した一括処理も同時に用意されました。
余談ながら、その当時のパソコン雑誌のライターの多くが旧態依然とした桐ver.7のプログラミング方法に対して失望を表明しています。
しかし、MS-DOSの時代に蓄積された桐ユーザのプログラム資産を大切にするという管理工学研究所の遠謀深慮に気付いたライターは非常に少なかったのです。
以下の例は、［表のウィンドウ］と［フォームのウィンドウ］を扱う為のプログラムですが、
なんと３ステップのコマンドを実行しないと、矩形をしたMS-Windowsのウィンドウが扱えないのです。
―［表のウィンドウ］を操作する手順
表 "Jusho.tbl"
ウィンドウ作成 表, ハンドル = &hWnd
ウィンドウ会話 &hWnd, 更新 = 禁止, 許可作業 = なし, 項目番号 = &Field, 終了状態 = &OK
―［フォームのウィンドウ］を操作する手順
表 "Jusho.tbl", 使用フォーム = "Jusho.wfm"
ウィンドウ作成 フォーム, ハンドル = &hWnd
ウィンドウ会話 &hWnd, 初期項目 = @bOK, ボタン = &Obj,終了状態 = &OK
これを便宜上、拡張一括処理コマンドと呼ぶことにします。
古典一括処理と拡張一括処理は、表示方法として画面（スクリーン）と矩形をしたMS-Windowsのウィンドウの違いこそありますが、
どちらもフロー（つまりプログラムの流れ）を一括処理ファイルに記述して実行する点で全く同じです。
このような一括処理のスタイルを「フロー駆動型」と呼びます。
「フロー駆動型」の難点としては、フロー（つまりプログラムの流れ）をすべて記述しなければプログラムが完成しないことが挙げられます。
また、フロー（つまりプログラムの流れ）の途中でエラーが発生すると、初めからやり直しになります。トホホ〜。
このように「フロー駆動型」は非常に手間がかかり大変なのです。
その後桐ver.8が発売されて「フォーム＋イベント処理」のプログラミングが出来るようになりました。
これは、フォームを利用するユーザの操作によってイベントが発生して、そのイベントに対応するプログラムが実行されるというものです。
実行されるプログラムには［コマンドボタンの機能名：手続き実行］から呼び出す手続き（一般手続きと呼ぶ）と、イベント発生で実行する手続き（イベントハンドラと呼ぶ）の２種類があります。
実際にはイベントハンドラは案外と出番が少なくて、多くのケースでは［コマンドボタンの機能名：手続き実行］から一般手続きを呼び出します。
このような「フォーム＋イベント処理」のプログラミングスタイルを「イベント駆動型（イベントドリブン）」と呼びます。
「フォーム＋イベント処理」のプログラミングでは、まず［フォームのウィンドウ］を開くだけで準備が完了するので実に簡単です。
そして、イベント処理ファイルに［コマンドボタンの機能名：手続き実行］に対応する一般手続きや、イベントの発生に対応するイベントハンドラを付け加えていけばＯＫです。
つまり、「フォーム＋イベント処理」では、拡張一括処理のように［表のウィンドウ］や［フォームのウィンドウ］を３ステップのコマンドを使って開く必要がありません。
「フォーム＋イベント処理」では、桐の［ファイル］メニューの［開く］ダイアログでフォームを開いたら、すでにプログラムが実行可能の状態になっています。
さらに、開いた［フォームのウィンドウ］から別のウィンドウ開くには［コマンドボタンの機能名：開く］でフォームファイル名や表ファイル名を指定するだけで済みます。
以上をまとめてみると、「フロー駆動型」の一括処理は、「イベント駆動型」の「フォーム＋イベント処理」と比べると、扱い難いものであると理解していただけるでしょう。
また、古典一括処理と拡張一括処理のコマンドの中には「フォーム＋イベント処理」で実行できないものが４０種余りありますので、
桐ver.8以降の桐10ｓや桐ｓでは「フロー駆動型」の一括処理の勉強はまったく不要になったと言えます。
また、「フロー駆動型」と「イベント駆動型」では、制御の主体が「フロー（プログラムの流れ）」と「ユーザの操作」と異なっています。
これは「制御主体の反転」と言うべきで、そのために「フロー駆動型」と「イベント駆動型」を同時に勉強すると頭の中が大混乱になってしまいます。
「順番として、履歴を勉強してから、一括処理を勉強して、最後にイベント処理を勉強する」と考える人が案外と多く居ますが、
それでは、「イベント処理で使えないコマンド」や「制御主体の反転」に思いがけず遭遇して、分けが分からなくなるのでお勧めしません。
ということで、一括処理（履歴を含む）の勉強はスルーして、「フォーム＋イベント処理」の勉強だけすることをお勧めします。
なお、古典一括処理と拡張一括処理のコマンドは以下の拙作ｗｅｂページに掲載していますので参考にしてください。
１５ コマンド｜桐の釣魚大全のトップ > フォームアプリケーション教書 第１部
■レガシー（古典一括処理・拡張一括処理）なコマンド
■［フォーム＋イベント］で利用できるコマンド その１／その２
http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section15
（注意）
桐ver.7以降では、フォームのコマンドボタンの［機能名：開く］で一括処理(.cmx)を指定することが出来ます。
しかし、見かけはフォームですが、出発地点としてフォームを［踏み台］にしているだけであって実際には一括処理と同じです。
なおこの場合には、制御の主体がフォーム側にあるために、純粋な一括処理と全く同じ挙動をするわけではありません。
従って、コマンドボタンの［機能名：開く］で一括処理(.cmx)を指定する方法はおススメしません。
４ 変数のスコープ
４．１ 局所変数を使う
初級者は［スコープ］と聞いて難しそうに感じるかもしれないですが、単純に「範囲」のことです。なぁ〜んだ。(^^♪
コンピュータの技術は英語圏で発達してきたので、どうしても英語が多くなります。
しかし、これは仕方ないので慣れてください。
ここでは［変数のスコープ（範囲）］について説明します。
「フォーム＋イベント処理」では、フォーム定義の変数管理とイベント処理の［名札 メイン］で、共通・固有・局所の３種類のスコープ（範囲）の変数を宣言できます。
共通・固有・局所の３種類のスコープ（範囲）の中で最も利用するのは局所のスコープです。
局所のスコープでは、変数の有効範囲が変数を宣言した［フォーム］の中に限定されます。
つまり、複数の［フォーム］で同じ名前の局所変数を宣言したとしても、それぞれのフォーム毎に局所変数が独立して用意されるのでお互いに干渉しません。
一方、もしも複数の［フォーム］で同じ名前の共通変数または固有変数を宣言すると、これらの変数は唯一１つだけ用意されるので、変数を宣言する度に変数は上書きされてしまいます。
また、変数を上書きする際に、既に宣言済みの変数のデータ型と異なる場合にはエラーが表示されてしまいます。
ということで、「フォーム＋イベント処理」では変数のスコープ（範囲）に局所にするのがベストの選択になります。
しかし、もしも複数の「フォーム＋イベント処理」において、共通に利用できる変数が必要な場合には、スコープ（範囲）を共通または固有にします。
共通変数と固有変数の違いは、共通変数は削除しない限り残り続けますが、
固有変数は［フォームのウィンドウ］をすべて閉じた時にリリース（解放）されて消えて無くなるという点です。
ただし、これには注意が必要で、［表のウィンドウ］が開いていた場合には、その表(.tbx)が開く前に宣言された固有変数はリリース（解放）されません。
普通の場合、「フォーム＋イベント処理」では局所変数だけで十分ですので、あえて共通・固有変数を宣言する必要はありません。
特に固有変数は、［フロー駆動型］である［一括処理］のレガシー（遺産）でもありますので、積極的に利用する必要はありませんよ。
どうしても広域的な変数が必要な場合には、種類が限られていますが［桐の組み込み変数］を上手に利用する方が簡単で便利です。
４．２ スコープ（範囲）が異なる同名変数がある場合
スコープ（範囲）が異なる同名変数がある場合を考えてみましょう。
例えば、「フォーム＋イベント処理」の［名札 メイン］で 共通変数：&address 固有変数：&address 局所変数：&address を宣言したとします。
スコープ（範囲）が異なるので当然ですが３個の変数が出来ているわけです。
名札 メイン
変数宣言 共通，文字列｛ &address ｝
変数宣言 固有，文字列｛ &address ｝
変数宣言 局所，文字列｛ &address ｝
そして引き続き次の代入コマンドを実行したとします。
&address = "港区西麻布"
ここでクエスチョンです。
"港区西麻布"という値が格納されている変数は次のＡＢＣのどれでしょうか？？
Ａ 共通変数：&address Ｂ 固有変数：&address Ｃ 局所変数：&address
正解は、Ｃの 局所変数：&address です。
そして、他の Ａ 共通変数：&address Ｂ 固有変数：&address には "港区西麻布" は代入されていません。
それは、変数のスコープ（範囲）には以下のように優先順位があるからなのです。
【優先度が低い】 組み込み ＜ 共通 ＜ 固有 ＜ 局所 ＜ 自動 【優先度が高い】
このように［スコープが異なる同名の変数］を宣言してしまうと優先順位が高い方の変数が使用されるので注意が必要です。
これを避けるためには、変数名の先頭に接頭辞を付けて同名の変数を宣言しないようにするのがベストです。(^^ok
【変数のスコープ（範囲）を表す接頭辞の例】
自動 … なし &address / &住所
局所 … m &mAddress / &m住所 ※ m はモジュールの意 または［名札メイン］の意と解釈してもＯＫ
固有 … g &gAddress / &g住所 ※ g はグローバルの意
共通 … p &pAddress / &p住所 ※ p はパブリックの意
上の例のようにスコープ（範囲）を表す接頭辞を用いれば、スコープ（範囲）が異なる同名変数によるトラブルは発生しません。
そして、接頭辞を見るだけでその変数のスコープ（範囲）が識別できるので一石二鳥というわけです。
特に「フォーム＋イベント処理」では、手続き（一般手続きとイベントハンドラ）内で自動変数を宣言するので、［名札 メイン］で宣言する局所変数には接頭辞( m ) が必須になります。
４．３ 自動変数
自動変数は一般手続きとイベントハンドラの中で宣言できる変数です。
自動変数は非常に多く宣言するので、変数のスコープ（範囲）を表す接頭辞は付けません。
もしも、局所変数と同名の自動変数を宣言した場合には、自動変数が優先して使用されます。
従って［名札 メイン］で宣言する局所変数には接頭辞( 例： m )を付けて自動変数と衝突しないようにしてください。
自動変数のスコープ（範囲）は変数を宣言した手続き（一般手続き・イベントハンドラ）の中だけです。
例えば、一般手続き：cmd検索実行( )で自動変数：&found を宣言して、cmd検索実行( )から別の一般手続きを［手続き実行］コマンドで呼び出した場合、
呼び出された一般手続きで自動変数：&found を宣言しても構いません。
その場合には、手続きが異なるので、つまりスコープ（範囲）が異なるので自動変数：&found は別々に用意された独立した変数なのでお互いに干渉しません。
自動変数は、変数を宣言した手続き（一般手続き・イベントハンドラ）の実行が終了する時に自動的にリリース（解放）されます。
※手続きに変数の値を渡す場合には、値渡しの引数を使用します。
※手続きに変数を受け渡す場合には、参照渡しの引数を使用します。
以上、言葉で説明すると難しく感じると思いますが「案ずるより産むが易し」です。
いろいろ体験するうちに自然に理解し身に付くようになります。
以上まとめると、局所変数は個々のフォーム毎に、自動変数は個々の手続きごとに作られるということです。
また、局所変数はフォームを閉じると自動的にリリース（解放）されて、自動変数は手続きが終了すると自動的にリリース（解放）されます。
５ 変数名に日本語は使えますか〜？
５．１ 桐では変数名も日本語に対応しています
従来からコンピュータ言語では日本語の変数名は誤動作の元になることがあるので、変数名に日本語を極力使わないようにする場合が多いです。
しかし、桐では日本語の変数名でも何の問題はありません。
これは桐が最初から日本語対応だったからです。
例えば著者( ONnoji )のｗｅｂページのプログラミング例には、英語または英語風の変数名がたくさん使われています。
その理由は、遠い昔の８〜１６ビットＣＰＵ時代のコンピュータ言語では、日本語の変数名が利用できないか、仮に利用できても誤動作の原因になっていたからなのです。
また、コンピュータは英語圏で発達したので、どうしても英語のキーワードが多くなり、書籍・雑誌・ｗｅｂに掲載されるプログラミング例も英語チックなものが多くなりがちです。
それらの影響から著者( ONnoji )は、桐を使う以前からの習慣に従って、「フォーム＋イベント処理」でも英語または英語風の変数名を使っています。
しかし、表(.tbx)の項目名には普通に日本語を用いることが多いので、項目名に１対１対応する変数名は日本語の変数名にしていますよ。
プログラムの作り方は自由ですから、十人がプログラムを作れば、十通りのプログラムが出来ても不思議ではありません。
従って変数の命名も自由ですが、局所変数には接頭辞( 例： m )を付けて自動変数と衝突しないように注意することをおススメします。
※（注意）変数の命名は自由ですが、実際には桐の仕様と文法規約（シンタックス）に従う必要があります。
５．２ 習慣的に使われる変数名
変数の命名は自由ですが、歴史的によく使われる変数がありますので以下に紹介します。
それは「遠い昔、銀河系の地球でコンピュータ言語が発明された時以来」の習慣です。
次の１文字の変数名は普通に使いますよ。
それは、アイ、ジェー、ケー つまり i j k です。
桐の場合には、変数を直接（リテラルに）記述する場合には、接頭辞のアンパサンド記号(＆)を付けますので
つまり、&i &j &k ですが、これはプログラミングに慣れている人にはまったく違和感がありません。
これらの変数は整数のカウンタとして使います。
すなわち、&i が 1、&i が 2、&i が 3、… &i が n のように値が増加していくケースです。
これは「ヒツジが一匹、ヒツジが二匹・・・、ヒツジがｎ匹」というやつです。(^^ゞ
例えば、
&step = 1
&loop = 10
繰り返し &i = 1, &loop, &step
** &i の値が、１から１０になるまで１（&step）増分して繰り返す
繰り返し終了
ちなみに、&j &k は、さらに繰り返しが入れ子になる場合に使いますよ。
また、ネット上でプログラミング例を見ると、３文字の変数名を非常によく見かけると思います。
これは遠い昔の８〜１６ビットＣＰＵ時代のコンピュータ言語において長い変数名が使えなかったことによるレガシー（遺産）です。
例えば、著者( ONoji )はカウンタとして &cnt をよく使います。
本当は &count でも良いのですが、３文字のレガシーで &cnt です。
&count ⇒ &cnt は、いわゆる母音抜きなのですが、だいたい意味が通じますよね。AKIBA ⇒ AKB とかね (*^^)ok
例えば、
&cnt = 1
繰り返し ( &cnt <= 10 )
** &cnt の値が、１から１０になるまで１増分して繰り返す
&cnt = &cnt + 1
繰り返し終了
とかですね。
ところで、&cnt = &cnt + 1 はヘンテコに見えるでしょう。
でもこれは、&cntに１加算した結果を &cnt 自身に代入するという意味なのです。
つまり、加算（インクリメント）のコマンドになるわけです。
ちなみに、桐以外のコンピュータ言語でも基本的に同じですが、
i = i + 1 と書かずに i++ と書く言語が多いですよ。
もしも、i++ なんて見るとますます頭の中が混乱してしまいますよね。
６ プログラムの制御構造
プログラムの制御構造というのが普通に当たり前に常識としてありますので以下に簡単に紹介します。
それは次の３つです。 ※構造化プログラミング フリー百科事典『ウィキペディア（Wikipedia）』より
１．順次（sequence） 部分プログラムを順々に実行する。
２．選択（selection） 条件式が導出した状態に従い、次に実行する部分プログラムを選択して分岐する。
３．反復（repetition） 条件式が導出した特定の状態の間、部分プログラムを繰り返し実行する。
たぶん↑これで意味内容を理解できる初級者はまず居ないですよね。
ということで、それぞれの意味を噛み砕いて説明しますね。
６．１ 順次（sequence）
順次（sequence）とは、プログラムは先頭の行から順番に実行されるように記述することです。
部分プログラムとは「フォーム＋イベント処理」の場合では、［名札 メイン］・［一般手続き］・［イベントハンドラ］です。
「先頭の行から順番に実行するって当たり前じゃん」と思う人が多いと思いますが、これにも歴史的な経緯があるんですよ。
実は、初期のプログラミング言語では、プログラムの途中から実行したり、上から下へ順番に実行しないで、途中まで行って上に戻ったり、途中を飛ばして下へ進んだり、
ありとあらゆる勝手気まま（恣意的）にプログラムの流れを作っていたんですよ。
これはカオス（混沌）状態と同じで、いわゆるスパゲッティなプログラムなわけです。
だから、「どげんかせんといかん」と考えた人達が現れたんですね。
そうして、「プログラムは上から下へ流れるように書きましょう」という共通認識が培われたというわけです。
６．２ 選択（selection）
選択（selection）とは、ある条件を満たしている時に実行する範囲と、条件を満たしていない時に実行する範囲を分けて作りましょうということです。
これはＷｉｎ桐ではお馴染みの if ( 条件 ) ... else ... end です。※実はＤＯＳ桐には if else end がありませんでした。これホント(@_@)
似た物としては、ケース開始 ケース( 条件 ) ... ケース その他 ... ケース終了 があります。※これはＤＯＳ桐にもありました。
ということで、ＤＯＳ桐時代の一括処理を見ると、［ケース開始 ... ケース終了］がたくさん書いてありますよ。
ところが、ＤＯＳ桐には［分岐］と［名札］コマンドがあるので、［ケース開始 ... ケース終了］を使うべきところで、
［条件 分岐］と［名札］コマンドでプログラムの流れを選択していた初級者も居たと思います。
さらに、ＤＯＳ桐ではプログラムの制御構造を知らない初級者によって［条件 分岐］と［名札］コマンドを使ったスパゲッティなプログラムが大量生産されていたワケなんです。
ちなみにＤＯＳ桐の時代は、MS-DOSのバッチファイルや、NEC PC-9801のＢＡＳＩＣ言語の全盛期であり、
これらではスパゲティなプログラムが自由自在に作れるので、ＤＯＳ桐の利用者も全然気にしていなかったと思われます。
しかし、当時すでにスパゲッティなプログラムが作れない、または原則禁止のプログラミング言語もありまして、※例えばdBASE言語には分岐命令がありません
そういうプログラミング言語を使っている人たちからみると、ＤＯＳ桐はとても恐ろしく見えたと思います。
かくゆう著者( ONnoji )が初めて桐ver.2の一括処理を見せてもらった時には、あまりにもスパゲッティなプログラムが多いので驚いて腰を抜かしましたよ。
６．３ 反復（repetition）
反復（repetition）は、同じ範囲を繰り返して実行することです。
Ｗｉｎ桐では、［繰り返し ... 繰り返し終了］コマンドが相当します。
これは難しくないので、すぐに理解出来るでことしょう。
一番のキモは、［繰り返し ( 条件 ) ... 繰り返し終了］の場合には、 if ( 条件 ) ... else ... end の場合と同じように、
( 条件 )に記述する条件式が最終的に論理値を生成している点を理解することです。
つまり、 条件式の結果（これは評価とも）が１イチ(真)か０ゼロ(偽)のどちらかということです。
これさえ理解すればＯＫです。
７ モジュラー設計
７．１ ひとつのモジュールはひとつの機能を担当する
実は、スパゲッティにならなければ何でもよいのか？というわけではないのです。
もう一つ重要なポイントがブロック化です。
分かり易く言えば、ブロック玩具のレゴ(LEGO)のように細かい部品に分けてプログラムを作るということです。
この場合のブロックは範囲という意味ではなく、［機能］という視点でのブロックです。
このブロックをモジュールと呼びます。
「フォーム＋イベント処理」では、モジュールは［名札 メイン］・［一般手続き］・［イベントハンドラ］になります。
モジュールで一番重要な点は、「ひとつのモジュールはひとつの機能を担当する」ということです。
従って、あれもこれも何でもできる［名札 メイン］・［一般手続き］・［イベントハンドラ］では駄目なんです。
実は、初級者の場合には機能を分割（分担）して、個々のモジュールに切り分けることが上手に出来ません。
だって、慣れていないのですから当たり前ですよね。
繰り返しになりますが、「ひとつのモジュールはひとつの機能を担当する」という事を常に念頭に置いていれば、
上位の機能（モジュール）と下位の機能（モジュール）の関係で手続きが作れるようになります。
※これは、メインルーチンとサブルーチンというものと同じ考え方です。
そして、一般手続きの機能（モジュール）は特定のオブジェクトと結びついていないので、同じイベント処理の別の機能（一般手続き・イベントハンドラ）からも呼び出せます。
従って、一度作った一般手続き（モジュール）は、更に別の「フォーム＋イベント処理」にも流用して再利用し易くなります。
再び繰り返しになりますが、初級者の場合には機能を分割（分担）して、個々のモジュールに切り分けることが上手に出来ません。
しかし、面倒臭がってモジュール化をしないと、一か月後、数か月後、一年後と時間が経てば経つほど記憶も曖昧になって、
さらに「ひとつのモジュールはひとつの機能を担当する」という原則を守らなかったことによる複雑さも加わり、謎のプログラムに変容していくのです。
しかし、適切にモジュール化しておけば、記憶が曖昧になっていても、プログラムの複雑さが軽減されているで、何とかなるのです。(*^^)ok
自分で作ったプログラムが解読出来なくて何時間も格闘するするのは時間の無駄でしょう。
だから、未来への投資だと思って、後々のことを考えて拙速にならないように気を付けてください。
以上をまとめると、「プログラムは（作成後に時間が経過して）未来の自分という他人が読んでも分かり易いように書く」という教訓が得られることでありましょう。(^^ゞ
＜参考＞
［プログラムの制御構造］や［モジュラー設計］というのは、いわゆる［構造化プログラミング］と呼ばれるものです。
［構造化プログラミング］は、はるか昔に提唱されてきた考え方ですので、現代では特に［構造化プログラミング］が雑誌やネットで騒がれることはありません。
また、［構造化プログラミング］とされる範囲は非常に広くて様々な議論があるので、初級者は［構造化プログラミング］を特にお勉強される必要はないと思います。
７．２ 適切なモジュールの大きさは
機能という観点から離れて、人間の理解しやすさから考えると、モジュールの大きさはＡ４の用紙一枚くらいがよさそうです。
これは多くの行のプログラム（手続き）は、少ない行のプログラム（手続き）よりも読み難いという意味です。※もちろん空行を除くとします。
もしも、あまりにも長大なプログラム（手続き）になる場合には、分割を考えた方がよい場合が多いです。
しかし、長大なプログラム（手続き）でも、内容が一本道で複雑ではない場合には、理解し易いので分割しない方がベターです。
一方、行数が少なければベストかというとそれは違います。
もしも、機能として分割した結果が、実質的に１〜３行くらいのコマンドになる場合には分割しない方がベターです。※ただし例外も存在します
つまり、あまりに細かく分割すると、モジュール（手続き）の数が多くなってしまい、分かり易さを損なうことになります。
７．３ 字下げと空行で読み易くする
ネット上で桐のプログラミング例を見ると、空行を一切使わずにコマンド（メソッド含む）を書いたプログラムを見かけると思います。
ハッキリ言いましょう、空行を一切使わずにコマンド（メソッド含む）を書いたプログラムは読み難いです。キッパリ(^^)v
しかしこれには理由があって、それはMS-DOSのＤＯＳ桐の時代に外部記憶装置が低速だったことによるレガシー（遺産）なのです。
当時は、オーディオカセットテープを円盤にしたようなＦＤ（フロッピーディスク）が使われていて、それはそれは超低速なのでした。
従って、当時の桐ユーザは古典一括処理のファイルをほんの少しでも速く読み込もうとして、涙ぐましい努力をしていたのです。
その結果として、空行を一切挿入せずに、まるでお経のような古典一括処理を書く人が多かったと推察いたします。
当然ですが、もちろん字下げもしませんよ。アハハha。
しかし、MS-Windowsの時代にはＨＤＤ（ハードディスク）や、更に高速なＳＤＤ（シリコンディスク）の外部記憶装置を使用するので、このようなレガシーは一切不要になりました。
というわけで、Ｗｉｎ桐のプログラムでは、段落の区切りとして空行を挿入してプログラムを読み易くするように心がけてください。
また、字下げ（インデント）をしてプログラムを読み易くするように心がけてください。
現代はMS-DOS時代のようにプアー（貧しい）ではなく、MS-Windowsの時代はリッチ（豊か）なのですから、もうMS-DOS時代のレガシーを引きずる必要はありません。
なお、拙作にプログラムの字下げを自動的に作るの整形ユーティリティ：utx_list3 がありますので、興味をお持ちの方はダウンロードしてください。
８ コメント行
８．１ コメント行は必要ですか？
コメント行は基本的に必要ありません。
モジュールに関する内容を詳細に解説したコメント行があるプログラムでは、
その後の改修（改訂）の際にコメント行のメンテナンスを忘れたり怠ったりすることによって、解説内容と実際との間に不整合が生じる可能性があります。
というわけで、出来るだけコメント行を少なくするか、潔くコメント行を書かないようにしましょう。
コメント行が一切書かれていなくても、順次・選択・反復の制御構造を用いて、意味が分かり易い変数名を使用したプログラムであればプログラムは理解し易いハズです。
８．２ コメントアウト
桐のプログラムでは、アルタリスク（＊）記号で始まる行はコメント行として扱われて実行されません。
もしも、あるコマンドを実行した際にエラーが表示された場合には、エラーした行にアルタリスク（＊）記号を付けてコメントアウトしましょう。
しかし、コメントアウトしないで、直ちにエラーした行を削除してしまうと、何がエラーの原因だったのかを調べる手掛りを失うことになります。
ということで、直前値キーなどを使い、エラーした行をコピーしてコマンドの修正を試みましょう。
ちなみに、コメントアウトする行には、将来本当に削除してしまう行と、削除せずに備忘として残しておく行の２種類があります。
著者( ONnoji )の場合には、
＊ 全角アスタリスク記号は、将来本当に削除してしまう行
** 半角アスタリスク記号は、削除せずに備忘として残しておく行
のように全角のアルタリスク（＊）記号と半角のアルタリスク（*）記号を使い分けて区別していますよ。
９ 柔らかな機械
ここに書くのはこの小論の締めくくりとして、著者( ONnoji )が「フォーム＋イベント処理」の初級者である貴方へ贈る言葉です。
誰でも知っているようにパソコンはハードウェアと呼ばれます。
一方、オペレーティングシステムのMS-Windowsやアプリケーションであるエクセルや桐はソフトウェアと呼ばれます。
従って、［フォーム＋イベント処理］もソフトウェアということになりますね。
このソフトウェアという言葉を、［柔らかな機械］と考えていただきたいのです。
見えなくて、実際に触ることも出来ないけれど、それは機械と同じなんだとね。(*^^)ok
だから、機能だとかモジュラー設計だとか、まるでハードウェアと同じような言葉が飛び出してくるのです。
ハードウェアのメンテナンスや故障診断と、ソフトウェアのそれはまったく同じではありませんが、
ソフトウェアが［柔らかな機械］だと考えればイメージしやすくなるでしょう。
最後にスターウォーズの有名なセリフの駄洒落で締めくくりたいと思います。(^^ゞ
フォームを使え。感じるのだ。 Use the Form. Feel it.
フォームと共にあらんことを。 May the Form be with you.
それでは。(@^^)/~~~
２０２４年４月 八重桜の季節にて 著者( ONnoji )記す
トップページに戻る
桐の釣魚大全のトップ > 目からウロコのデータベース桐プログラミング入門