「アプリケーションが “なぜか” うまく動作しない」を減らすために
エイタです。シクヨロです。
「先輩、自分が組み込んだ処理がなぜかうまく動かないんですぅ～😢」
それな。
・・・ちょ待てよ。「なぜか」ってことはないっしょ。 そんな言葉を使った瞬間、同期から陰でディスられるよ？ 成長するためには自力で原因を追究するテクニックを身に付けなきゃ。PowerBuilder には問題を解決するための便利な機能が提供されているんだから、それを使わない手はない！
とりま、今回はそんな PowerBuilder ビギナー のためにバイブス上がる情報をマジメに提供していくわけだ。
MessageBox を埋め込みまくる
MessageBox 関数を挿入すれば、「その処理を通るか」を簡単に確認することができます。 単純な方法ではありますが、IDE からの実行ではうまくいくけど配布するとうまくいかないという場合に有効です。
「追加した処理が exe だとなぜか実行されないんだよね」ってときに処理の先頭で MessageBox を呼び出して、「メッセージが表示されない＝そもそも処理自体が呼ばれてないじゃん・・・」なんてことが確認できたりします。
これはやりすぎ
いまひとつクレバーな方法ではないかもしれませんが、確認したい値を手軽に出力することができるのでお世話になっている方も多いのでは。
ただし注意点もあります！
メッセージボックスが表示されるということは、アプリケーションの画面が非アクティブになりコントロールからフォーカスも外れる・・・。すなわち、余計なイベントが発生してしまう (Deactivate、LoseFocus など) ことがあります。 このせいで処理の順序が変わり、想定していた事象が発生しなくなる可能性があることを覚えておいてください。
似たような確認方法として FileWriteEx 関数で「お手製ログファイル」を出力する方法もありますね。 こちらの方法はフォーカスも変わらないので上記のような心配は不要です。
しかし、いずれの方法も本番では挿入したコードを除去する必要があるため、その際に誤って必要な処理まで消してしまうというリスクも・・・。
う～む。
デバッグ実行する
PowerBuilder IDE の「デバッグ機能」、使ったことありますよね。 ツールバーでひなたぼっこしているかわいい虫のアイコン 
のやつです。アプリケーションに問題が発生した場合、まずはこいつを使って確認してみましょう。
問題が発生していると思われる箇所にブレークポイントを張ります。スクリプトエディタ上で右クリックし [ブレークポイントの挿入] ですね。 で、デバッグ実行 (虫アイコン or [Ctrl + D])。
[開始] してアプリケーションを動かすと、ブレークポイントを挿入した行で処理が止まってデバッグ画面が表示されます。
デバッグ画面ではショートカットキーとして [F8] で「ステップイン」、[F10] で「ステップアウト」実行ができ、処理を確認しながらアプリケーションを動かすことができます。
デバッグ中には各変数の現在の値やオブジェクトの状態などを確認できるので原因の特定に役立ちますね！
詳しい話は書ききれないので Debugging an application を見るか、最近リリースされた日本語版ヘルプで [PowerBuilder ヘルプ > ユーザーズ ガイド > アプリケーションの実行 > アプリケーションのデバッグと実行 > アプリケーションのデバッグ] あたりをチェック！
ちなみにデバッグモード中、初期設定ではショートカットキー [Ctrl + C] に「処理の継続」が割り当てられているので、 『デバッグ中にスクリプトをコピーしようとしたら処理が走ってしまった』というのは「PowerBuilder あるある」なので要注意！ その処理が複数テーブルの不可逆的な更新だったため泣きながらデータ復元とか・・・よくやりますよね！
PBDebug 機能を使う
PBDebug 機能、ご存知ですか？
システムオプションから有効にできるこの機能は、実行されたオブジェクトの関数と命令、システム DLL 関数などの情報を時系列で出力することができます。
メニューから [ツール(T) | システム オプション(S)…] で設定します
出力されたログには実行された時刻までは記録されていませんが、どの処理がどのような順番で呼ばれているかが逐一記録され、呼び出した処理からさらに別の処理を読んでいる場合は入れ子構造で出力されます。
このため、アプリケーションがクラッシュした場合に、どの時点で終了したかアタリをつけることができます。
クラッシュした場合のログ（抜粋）
・
・
・
Executing system dll functionExecuting event +CLICKED for class CB_12, lib entry W_SAMPLE07
Executing instruction at line 1
Executing object function SETSORT for class DW_3, lib entry W_SAMPLE07
Executing system dll function
End class function SETSORT for class DW_3, lib entry W_SAMPLE07
Executing instruction at line 2
Executing object function SETREDRAW for class DW_3, lib entry W_SAMPLE07
Executing system dll function
End class function SETREDRAW for class DW_3, lib entry W_SAMPLE07
Executing instruction at line 3
Executing object function RETRIEVE for class DW_3, lib entry W_SAMPLE07
Executing system dll function
End class function RETRIEVE for class DW_3, lib entry W_SAMPLE07
Executing instruction at line 4
Executing object function SORT for class DW_3, lib entry W_SAMPLE07
Executing system dll function <--- ログはここで途切れている・・・
この例のように function SORT を呼んでいるのに End の行がないという場合は、その呼び出しでエラーになっていることがわかります。 このあたりから問題の箇所を探っていきましょう。
と、ここまでは IDE からの実行のはなし。 実はこの PBDebug 機能、配布済みの exe でも有効にすることができるんです。
ね、エモい。
やり方は簡単。 exe 実行時にコマンドラインオプションとして /pbdebug をくっつける。 そんだけ。
PBDebug ログを出力する実行の例
> yabatani.exe /pbdebug
ただし事前に準備が必要です・・・といっても配布するプロジェクトの [全般] タブ、「DEBUG シンボル有効(G)」にチェックするだけ。
配布前にチェック！
でも、デフォルトではチェックが ON なので知らず知らずのうちにログ出力が可能な exe を作っているかも？ ちなみにログは実行した exe と同じディレクトリに “実行ファイル名.dbg” として出力されます。
既に配布済みのアプリケーションで、クラッシュするオペレーションが特定できない場合などにも有効です。
トレース情報を収集する
これはね・・・。
ちょっと内容が濃厚すぎて薄い本が書けちゃうくらいの機能なんです。そのぶん「あんなこと」や「こんなこと」まで、得られる情報もたくさん。 気になるコは試してもいいけど、今回ターゲットにしているビギナーにはちょっぴり早いかな？ なのでここでは割愛します。
好奇心が抑えられない？ そんなアナタは Tracing and Profiling Applications もしくは日本語版ヘルプで [PowerBuilder ヘルプ > ユーザーズ ガイド > アプリケーションの実行 > アプリケーションのトレースとプロファイル] をのぞいてみてね・・・。
まとめ
どれもみんなが抱えている悩みを解決へと導いてくれる機能っしょ？
「ツールに頼るのは甘え」なんて考えは捨てて、マッハで問題のポイントを特定すれば周囲からのリスペクトも間違いない。 せっかく PowerBuilder っていう便利な IDE 使ってるんだから、その機能をフル活用しちゃいましょうよってハナシ。
不正な動作の原因が自身のバッドコーディングだった場合だけじゃなく、「まだ検出されていなかった PowerBuilder の不具合でした」って場合でも発生個所が特定できてりゃ早期解決が見込めるわけよ。
いつまでも「どこがおかしいのかわかりませ～ん😭」なんて言ってないでさ、自力で解決するチカラを身に付けて早く一人前のビルダーになろうぜ？
・
・
・
そう言って時にはやさしく、時には厳しく教えてくれた先輩。
必死になって虫 (バグ) を追いかけていた若かりしあの頃。
そんな日々も、今は昔の話です。
先輩、今の僕はあなたのように一人前になれていますか・・・？
(エイタ)
