VC++って__func__マクロの名前が違うのね
Cのマクロに関数名を取得する__func__というのがある。
例えば
printfDx("関数名=[%s]", __func__);
と書くと
現在実行中の関数がdispTalkMessagePreparation4だとすると
関数名=[dispTalkMessagePreparation4]
と画面に出力されるのだ。
ようするにソースファイル名を出力する__FILE__マクロや
ソースの行番号を出力する__LINE__マクロのお友達みたいなものになる。
なんでこんな事を確認しようとしたかというと
現在、作成中のイベントを終了した後、
かげさんが「行カーソル」と呼んでいる水色の▼の
表示位置がおかしくなったためだ。
実は、初音ミク冒険記のイベント製作中に
この行カーソルがズレるというのは
何度か確認していて、原因は例外なくdispTalkMessagePreparation4などの
dispTalkMessagePreparation系の会話メッセージ表示準備関数を使った後に
メッセージ送りボタンを押した時にendMessageString関数を
呼び出す処理を書き忘れていたことだった。
しかし、今回は、なぜかendMessageString関数をちゃんと呼んで
行カーソルの位置補正をクリアしているのに
最終的に行カーソルの位置補正が行われていて
わけがわからん!![]()
でも行カーソルの位置補正の変数を使っているのは
・dispTalkMessagePreparation4
・dispTalkMessagePreparation5
・endMessageString
の3つだけ。
しかも、今回のLuaスクリプトでは登場人物の説明をするどうかを表示しないので
dispTalkMessagePreparation5を使っていない。
ということは、予期しないパターンで
dispTalkMessagePreparation4
endMessageString
の順に処理された後で
もう一度dispTalkMessagePreparation4を呼んでいるはず。
ただ、dispTalkMessagePreparation4は
ゲームループの都度呼ばれるので
ブレイクポイントは貼りたくない。
ということでDXライブラリの非公開関数の中にある
ログ出力関数を使うことにした。
一応、dispTalkMessagePreparation5が呼ばれていた時のことも考慮し
3つの関数の終わりにログ出力を埋め込む。
ここでそれぞれの関数名をログ出力でコピペするってのも良いんだけど
ErrorLogFmtAdd("関数名=[%s]", __func__);
のように同じ行をコピペするほうが手間がかからないというわけだ。
が・・・
なぜか__func__が使えない。
おかしいなぁ、C99で増えたマクロだから
.NET以降のVC+なら対応していると思ったんだけど・・・
マイクロソフトのサイトに有る定義済みマクロ
によるとどうやらVC++では__FUNCTION__というものになってるらしい・・・
マイクロソフトも、どうせ対応するなら__func__で使えるようにもしておけよ!![]()
後で、どっかのヘッダにdefineしておこうかな。
ということで、結局、調べ物をしたから
かえって時間がかかってしまったけど
期待通りにログを出力できた。
まぁ、今後、関数名を取得するマクロを使えるようになったので良しとしよう。
ログを見ると、やっぱり、endMessageStringの後に
dispTalkMessagePreparation4が1回だけ呼ばれていた![]()
・
・
・
ε-( ̄ヘ ̄)┌ ダミダコリャ…
見なおしたけど、該当のイベントのLua関数は問題ないぞぉ!
ん?
該当のイベントのLua関数?
該当じゃないイベントのLua関数が犯人か?
試しに、怪しいと思われるLua関数にある
最初のdispTalkMessagePreparation4の引数を変えて
ログを出力してみる。
おぉ! 別のやつが呼ばれていたのか・・・
でも、なんで?
あ! そうか、イベントフラグの設定タイミングと
Lua関数の呼び出しタイミングの関係で動いちゃうのね。
しかも、1つ前のLua関数でメッセージ送りボタンを押したかの判定に成功するので
別のLua関数でもメッセージ送りボタンを押したことになって
するっと流れてしまうという話か!
なるほどねぇ。
理由が分かったので無事に直せたよ!
| 【固定リンク】 | 【コメント (0)】 | 【トラックバック (0)】




