コンソールアプリケーションであれば 「・・を 表示し」 などをソースプログラム中に埋めることで気になる個所でのデータの値を表示させる方法が使えました。
しかしGUIアプリケーションは(通常は)そもそもコンソール(コマンド プロンプト)は開かず、したがって「数値表示」「表示」「改行」などの処理単語も今までのようには使えず、工夫が必要となります。
■コンソールを開く
構文=
コンソールを開く → ・
コンソールを閉じる → ・
メインウィンドウの他に、コンソールウィンドウ(コマンド プロンプト類似の黒いウィンドウ)を開きます。コンソールは閉じることもできます。
コンソールアプリケーションでおなじみの「数値表示」「表示」「改行」などを使って、各種情報をそのコンソールに簡単に表示できます。スクロールするので多量の情報から過去を閲覧するのも容易です。
■GUI出力とコンソール出力の使い分け
GUIアプリケーションでのデバッグ情報の表示は以下の方法があります。
(1) 「メッセージをダイアログで表示」 を使う
−−−−−−−−−−−−−−−−−−−−
<文字列>を メッセージをダイアログで表示
−−−−−−−−−−−−−−−−−−−−
とすることて、デバッグ情報をダイアログを使って表示させることができます。
スポット的に少ない個所で情報を見たい場合に向いています。
この方法は簡便ではあるのですが、ダイアログが出る都度、ボタンを押し先に進める必要があるほか、表示された情報がすぐ消えてしまうため、多量・高頻度の情報表示には向いていません。
(2) コンソールを開く
たとえば「メインとは」冒頭で、
−−−−−−−−−−−−−−−−−−−−
コンソールを開く
−−−−−−−−−−−−−−−−−−−−
とすることでコンソールが開き、コンソールアプリケーションのときのように「表示」系の単語を使ってデバッグ情報をコンソール中へ表示できます(開いたコンソールはアプリケーションの終了時に自動的に消えます)。
多くの情報をひんぱんに見るのに向いています。
さらには、条件コンパイル機構を使い、「コンソールを開く」などのデバッグ用の処理を条件ブロックで囲めば、テスト系と本番系で同じソースにすることも可能です。
プログラム例: (コンソールへのデバッグ情報表示)
デバッグモードは 定数 1。 ←本番ではここを0にするだけで良い
条件コンパイル デバッグモード。 ←本番ではこのブロックは生成されない
主要なデータを表示とは (・ → ・)
・・・・・・
・・・・・・。
条件コンパイル終り
メインとは
デバッグモード ←条件コンパイル扱いになるので
ならば コンソールを開き 偽の場合にはまったくコードは
つぎに 生成されず無駄にならない
〜略〜
デバッグモード
ならば ・・・を 数値表示し 改行し
つぎに
−−−−−−
注:「<定数> ならば」の構文は条件コンパイルと同じ効果を持ちます
■イベント引数をダンプ
たとえばボタンを押下したとき、スタックに次のようなデータが積まれてイベント処理語が呼び出されます。
/ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄\
ボタン押下処理とは (引数1、引数2、・・、引数個数 → ・)
・・・・
・・・・。
\___________________________/
上記のようなイベント引数を丸ごとモニタ表示する処理単語があり、デバッグ用途に使うことができます。
構文=
(引数を使い切るタイプ)
<引数1> <引数2>、・・、<引数個数>
イベント引数をダンプ → ・
(引数を温存するタイプ)
<引数1> <引数2>、・・、<引数個数>
透過的にイベント引数をダンプ
→ <引数1> <引数2>、・・、<引数個数>
注:情報はコンソールウィンドウに表示されます。
あらかじめ「コンソールを開く」しておいてください
プログラム例1:
○○のイベント処理とは
イベント引数をダンプし 終り ←モニタが終ったらとりあえずリターン
・・本来の処理・・
・・本来の処理・・。
プログラム例2:
○○のイベント処理とは
透過的にイベント引数をダンプし
・・本来の処理・・
・・本来の処理・・。
プログラム例1は、ダンプだけおこなって直ちにリターンしてしまうものです。とりあえずイベント処理語が呼ばれたこと、そしてそのときの引数を確認するのが目的です。
プログラム例2は、モニタしたあと後続して本来のイベント処理に入ります。ダンプしつつ、本来のイベント処理もおこないたい場合に使います。
実行例1: (引数が無い場合(引数個数=0のみが積まれていたとき))
イベント引数: なし
実行例2: (引数が3つある場合)
イベント引数: abc | def gg | 引数3
■評価時モニタの制御
GUIライブラリは内部でGUIエンジンであるところのTcl/Tkにコマンドを送出することで描画をおこなっています。Tcl/Tkへのコマンドとレスポンスのやり取りは裏側で行われるので表には見えません。
Tcl/Tkレベルでの動作に興味がある場合は以下の機能を使い、やり取りをコンソールにモニタ表示させることができます。(あらかじめ「コンソールを開き」を実行しておきます)
構文=
評価時モニタをオン → ・
評価時モニタをオフ → ・
評価時モニタをオン2 → ・
評価時モニタをオフ2 → ・
注:「2」が付いたものはTcl/Tkからの戻値も含めて表示します
「2」が付かないものは戻値は表示しません
評価時モニタをオンにすると大量の情報がコンソールに表示されるようになります。「メイン」冒頭ではオンにせず、確認したい個所のみをオン/オフ制御するのも良い方法です。
■位置をモニタ表示、サイズをモニタ表示
ウィンドウやキャンバスでの位置や座標を調査するためにコンソールに値を表示したいことがあるかも知れません。
しかし、位置やサイズは、それぞれに X、Y でワンセットとなるため、見やすく数値表示したり空白で区切るのは意外と面倒なものです。そのような情報をコンソールに表示するのに便利な単語を用意してあります。
あらかじめ「メイン」冒頭で「コンソールを開く」してからお使いください。
構文=
<位置X>と <位置Y>を 位置をモニタ表示 → ・
<サイズX>と <サイズY>を サイズをモニタ表示 → ・
<位置X>と <位置Y>と <サイズX>と <サイズY>を
位置とサイズをモニタ表示 → ・
指定した位置やサイズをコンソールに表示します。
プログラム例:
300と 400を 位置をモニタ表示し
↓画面への表示
300,400
50と 25を サイズをモニタ表示し
↓画面への表示
50x25
300と 400と
50と 25を
位置とサイズをモニタ表示し
↓画面への表示
300,400 50x25
上記のうち、「位置とサイズをモニタ表示」を使うサンプルが window-geometry-debug.src です。
起動するとまずコンソールが開き、メインウィンドウの位置とサイズをそこへに表示します。
そのあとボタンを押すと再度同じようにコンソールに表示しますが、このとき表示されるサイズは当初より大きくなっており、そちらが本当の値です。
ウィンドウの位置とサイズ:96,96 200x200 ←起動直後
ウィンドウの位置とサイズ:96,96 309x305 ←ボタン押下後
前者は「メイン」の最後で測定した値です。Mindのプログラムとしては「メイン」の終わりまで実行していますが、実際にはまだウィジェットやウィンドウは描画が完了しておらず、もう少し(ごくわずかですが)時間が必要です。
一方、後者ではボタンを押すまでの時間的猶予があるためウィンドウの描画はすべて終わっており、正しいウィンドウサイズが表示されます。
- 注
-
「ウィンドウの位置とサイズを得る」という処理単語がありますが、それが返して来るデータ順は本処理単語が必要とするデータ順にまったく同じであるため、次のようにモニタ表示することができます。
ウィンドウの位置とサイズを得て 位置とサイズをモニタ表示する
たとえばゼロ除算や配列要素番号異常などの重大エラーが発生したとき、コンソールアプリケーションであればメッセージがコンソールに表示された後、アプリケーションが強制終了しましたが、GUIアプリケーションでは重大エラー発生時にはエラーメッセージがダイアログとして表示され、OKボタン押下を待ってから終了する進行になります。
■Mindのライブラリが検出するエラー
ゼロ除算や配列要素番号異常など、コンソール系アプリケーションでも発生するような重大エラーのほか、GUIライブラリ管轄で検出するエラーもあります。たとえば、無効なIDを付与する、誤ったデータ値をGUI系の処理単語に与えた・・などです。
サンプルとして、"jyudaierr.exe" を実行してみてください。これはわざとゼロ除算をおこなうものです。
■GUIエンジンが検出する重大エラー
GUIプログラムの誤りに関してはできる限りGUIライブラリ内(Mind側ライブラリ)で検出するようにしていますが、それらで検出できず、GUIエンジン(Tcl/Tk)に制御が渡されたあとでエラー発生することもあります。つまりGUIエンジンレベルでスクリプトのエラーを検出するケースです。
GUIエンジン内で発生したエラー表示は上記のようなものです。このダイアログが表示されると、あとはプログラム終了するしかなくなります。
英語で書かれているので分かりにくいかと思いますが、このようなエラーはGUIエンジン内で原因不明なエラーが発生したというよりは、アプリケーションプログラムが誤った処理をおこなった結果であることかほとんどです。
ソースコードを修正してデバッグ情報を表示させ、 「どのソースコード個所に来たときにエラーが発生したか」 を調べ、さらにエラー発生した処理単語へ渡すデータが正しいか・・などを調べると原因が掴みやすいです。
記: プログラムのエラー原因について弊社宛質問される場合、でれきば上記方法でソースコードの該当箇所を把握されてから問い合わせをいただけるようお願いします。