[344]

BBS
鉄道解析ごっこ
mail to: adrs
旧
旧 		新
新 		Diary INDEX
Geo日記 		戻る
前 		LIST
主目次

ＶＢＡマクロにも一休和尚数珠(句読点)問答の誤動作発生！

　一休さん話に、句読点の役割を諭す数珠発注の話があり、句読点無用を言う仏具屋に「二重にしてくびに掛ける数珠」を発注、仏具屋は首の廻りを２周する長い数珠を収めたところ、「発注仕様と違う！『二重にし手首に掛ける数珠』と言ったろう」と、句読点無用論の仏具屋をやり込めたというお話です。

　マクロに使うVisual BASIC/VBAでは、この一休話と同様の誤動作を起こして、修正できなくなることがたまに起こる様です。これまで誤動作の原因が全く分からず、誤動作するプログラムラインを新たに打鍵し直してから、元の誤動作ラインを丸ごと削除すると正常動作する不思議な経験を時折していましたが、動けばマ良いか！と納期に追われて原因追求などして来ませんでした。
　それが街のカルチャースクールのパソコン教室に通う連れあいからＶＢＡマクロの誤動作の現物を持ち込まれて「講師の先生も必死に見てくれたけど分かんなかったの。ちょっと見てよ〜」と、強制割り込みが掛かりました。こちらはタブロイド判全７ページ相当の長い講演会全文記事を読み始めていた処で、中断したくは無かったのですが、最優先割り込みには勝てません。携帯電話を家に置いて喫茶店にでも避難してから読み始めるべきでした！

　プログラムラインを追いますと、表示はテキスト通りながら、途中改行符号"_"：アンダースコアの次が１行余分に空いています。それを削除しましたが正常動作に至りません。どうも、ここで１続きのプログラムラインが切断されて、別の中間コードで記録されてしまって、後から修正を加えても１行には復旧できなかった模様です。それならアンダースコアを省いて文字通り連続行として打鍵すれば動いて良いはず！･･････で、案の定正常動作です。
　講義では「"_"：アンダースコアが何か」の説明は全く受けていないとのこと。居眠りでもして聞いてなかった可能性は残りますが、配布された講義メモにも記載は無いようです。ExcelではないＶＢ領域の話と言えばそれきりですが、傍流でも使う以上は簡単に説明しませんと時に二進も三進も行かなくなってしまいます。

　するともう一題、不動作サンプルが持ち出されてきて、良くみますと、テキストのデータ区切りがカンマ","ではなく、"､"：半角読点になっていて先ずそれが間違いですが、実際に打鍵されている内容はカンマ","です。この廻りの打ち直しでの誤動作かと、空行を作り、そこに新たに誤動作行を入力し直し、それまでの誤動作行を一括削除すると、やはりちゃんと動きます。

　さらに１題は、行の打鍵順が指定されていて、末行のコマンド・エンド部を先に打鍵してから、中間処理部を打鍵する指示なのを、勘違いして記述順まで入れ替えてしまって不動作となっている例題。End Sub 、End Function、End If などは冒頭行入力時にシステムが勝手にコマンド終端部を挿入してくれるので問題なく、後から途中に Else If など他命令を挿入できますが、そうではない多行に亘るコマンドでは他命令に誤解されてしまい自動では戻せない現象が起こりうるのでしょう。打鍵側がプログラムラインのアルゴリズムを考えながら入力していれば、行の逆順打鍵エラーは起こさない訳で、論理とは切り離された純文字列扱いで入力しているのでエラーとは気付けないのでしょう。

　以上のトラブルを統一的に説明できるのは、先ず、何等かのプログラムラインの誤入力で別の中間コードが記録され、後で修正した分は不動作の文字列扱いや他のコマンドとして解されて、見た目には正しいリストでも、内容が間違ったままになる、「一休さんの句読点話型エラー」ということのようです。一旦、誤ったコードで記録されると、見た目を修正してもコードは正しくならず、その行は新規入力して、誤動作行を全面削除することになると。（意図してテスト・ランさせてないのに、システムが勝手に命令終端を判断して中間コード化してしまうVisual Basicそのものがお節介に過ぎる問題があります。他のインタープリターではSAVEで一旦プログラム・ファイル化するか、「goto 行番号cr」とでもしないと中間コード変換動作はしませんから、今回のVBAの様な、ややこしいERRORは起こしません。）

　自分だけで使うソフトに、汎用のマクロの必要性はほとんど無く、概ね手作業で充分でした。お役人様が他の窓口でも使わせる実用ソフトとか、技術系では実務現場に降ろす設計計算ソフトとか「他人一般に使わせるソフト」に限られるから、ＶＢＡで技術系のユーザー定義函数を作って利用するとかは理解できても、カルチャースクールに集う純シロートの小母ちゃん達に汎用ＶＢＡマクロを教えてどうなるって言うんでしょうねぇ？と疑問を持つのですが、パソコンを購入して講座に参加した人達なのに、マクロの章に入ったらパラパラと辞め出したとか･･････、無理ないと思いますけどねぇ（･･････と、自らの怠惰を言い訳するw）。教室の講師はフィールドの実務に追われた方ではなく、教育講座出ではないでしょうかねぇ。テストのマクロを起動時自動実行のファイルで記録させてしまい、変な動作になるのを原因に気付けず戻せなかった、というのもフィールドでの実務経験の不足でしょう。
　公表仕様と実動作が微妙に違うのはＮ８８−ＢＡＳＩＣなどで散々経験させられ、回避法を編み出して来たわけで、Visual Basic誤動作の新規打ち直し術もその一つでした。

【N88-BASICの無茶な例】
　マニアルには
  • プログラムラインの「REM」、「'」以降、行末の CR-LFまでは「注釈文字列」で一切不動作
  • コロム":" は命令の区切り符号で、１行に複数命令を記述する「マルチステートメント」の場合に使う
    と記述されていますが、では注釈中にコロム":" が記述されていた場合は、注釈でしょうか？命令区切りでしょうか？マニュアルには注釈が一切無く、普通はCR-LF手前なので「注釈文字列」と理解されるでしょうが、実際は、インタープリター・モードでは注釈「Rem」ですが、それをBASICコンパイラで高速化する場合は、そうではなく、マルチステートメントが卓越するのだそうです。実動作で見ますと、インタープリター・モードでは「：」を含んでもSyntax Error！は表示されませんでしたからRem優先動作で問題ありませんが、プログラムをBASICコンパイラにより、約３倍の高速動作となる中間コードに変換する（＝コンパイルする）場合にだけ'Syntax Error!'と表示されて変換不能に陥ります。

    　これはインタープリターモードではRem卓越動作なのに、コンパイラではコロム：卓越動作でマルチステートメント扱いですからNEC側の仕様不統一BUGですし、少なくとも両者の優先度の違いは触れる必要がありますが、NECの見解では「プログラマー側のエラー」でその原因究明は「ユーザーソフトのデバッグ作業で、不当」と言い張るので驚きました。そういう高圧的で無茶な時代もありましたが、今や、見るも無惨に崩壊したPC98王国とはなりました。

    　支配者からの優先割り込みで打ち切られた長い講演会全文記事は、以上のマクロ・バグ探し作業終了後、携帯電話を家に置いて喫茶店に避難して２時間ほどで読み終わりました。泣く子と地頭と山の神には勝てませんです。

    冷や汗！「減圧バルブ」の存在を
    知らずエンジン発電機を操作！ 　　　<2>

    　京都・福知山での花火大会屋台爆発事件で、多数の犠牲者が出ましたが、その原因はどうやらガソリン携行缶が太陽やエンジン排気で熱せられてガソリンが気化し内圧が上がっているのに、内圧を下げずに蓋を開けてしまい、大量のガソリンが吹き出して屋台の火が引火して大惨事になった模様。プロパンやブタンの様に空気より重いガスは地表を漂って引火大爆発の危険がありますが、ガソリン蒸気はそれより分子量が大きく重いので拡散せず、しかも引火性が高いので特に注意が必要です。

    　私自身、エンジン発電機は大イヴェントでの会場電源としてレンタルしたのを扱ったことがありますが、ヒヤリとしたのはガソリン携行缶の「減圧栓」の存在を知らなかったこと。「蓋を開けるときはゆっくりと圧を充分抜いてから開ける」という注意は受けていましたが、こんなに激しい事故に成りうるとは意識して居らず、専用の「減圧栓」があるなんて全く知らずに扱っていたので冷や汗の出る思い。
    　「知らずに」とか、「具体的表示がない」というのは困りますねぇ。重大被害の失火元の屋台の小父さんもこの「減圧栓」を知らなかったのかも知れません。こうした取扱エラーを避けるには、解説表示だけでなく、減圧栓を緩めてからでないと蓋が開けられない構造を義務付ける必要がありそうです。
    Ｐ．Ｓ．
    　使ったのは静音型のディーゼル発電機で、引火性の低い軽油燃料で、軽負荷で最大5時間連続運転程度なので、運転中に燃料補給の必要が生ずることは全くなく、そちらから危険性は有りませんでしたが、安全策を知らなかった不安感というのは大きなものです。

    2013/08/20　18:55
    [Page Top↑] 旧
    旧     		新
    新     		雑談
    Geo雑談     		戻る
    前