V5.21β6No.02508
秀まるお さん 09/08/06 13:45
 
 V5.21β6をアップロードしました。

 お気に入りフォルダのボタンをフォルダ枠右上に付けました。

http://hide.maruo.co.jp/software/bin2/hmmail521b6_signed.exe

[ ]
RE:02508 期待したものとは別のアカウントNo.02510
緒方聡 さん 09/08/06 20:27
 
いつもお世話になってます。
以下、報告です。

【環境】
秀丸メール 5.21beta6
Windows XP

【再現率】
10/10 (100%)

【手順】
1. ふたつのメールアカウントを用意(AとBとする)
2. それぞれを別のアカウントグループに分ける(αにAとβにBとする)
3. Aにフォルダを作成する
4. Bにメールを出す
5. Bを右クリックして「B宛のメールを受信」を選択する

【問題点】
Aのアカウントで受信処理を行ってしまう

【補足1】
その後、Bを右クリックすると、Aの一番下のフォルダのコンテキストメニューが表
示される。
ツリー上で選びなおしたらコンテキストメニューは元に戻る。

【補足2】
手順 5 で「リモートメール」を選択した場合にAのリモートメールを表示する。
今回は両方とも IMAP4 アカウント。


再現しなかった場合は必要な情報は提供しますのでご連絡ください。

[ ]
RE:02510 期待したものとは別のアカウントNo.02511
秀まるお さん 09/08/07 09:24
 
 こちらでしくこくテストしてみたんですけど再現しないです。

 思った点を書かせていただきますと…

■1.フォルダを作成したりメールを送信したりというのは再現には無関係だと
思います。

■2.アカウント上でマウス右ボタンをクリックした時に、メール一覧がたしか
に切り替わるのが確認出来ます。その時点で、以前選択してたアカウントが何だ
ったかというのは忘れてるはずでして、「受信」のコマンドが以前選択してた方
のアカウントで実行されてしまうというのはちょっとよく分かりません。

■3.もしかしてですが、「送受信の開始直前」の所に何かマクロかDLLを登録
されているとしたら、それが関係してるってことは無いでしょうか。例えばその
マクロで別アカウントを選択するようなことをすると、そっちで受信が開始され
てしまいます。

■4.参考までに、僕の所でその「アカウントをマウス右ボタンクリックして受
信」とやった時の、dump.txtに出力されるログを書きますと、

09:15:13.591 (8512) NotifyFolderChanged
09:15:13.591 (2304) SetNull at pHidemaruView
09:15:17.396 (13120) Cmd 40003
09:15:17.396 (7932) CheckTuruKameMainInDialog
09:15:17.396 (7823) InitPatrol

 のような記録が出ます。NotifyFolderChangedというのはフォルダの選択が切
り替わってメール一覧がそのフォルダになったことを表してまして、SetNull at
 ...というのはメール内容枠に空っぽを表示した、という意味です。Cmd 40003
というのは、「受信」のコマンドを実行しています。その後は受信の処理が続き
ます。

 「全般的な設定・上級者向け・動作の記録」の中にあるdump.txt作成オプショ
ンをONにしていただいて、それで出てきたdump.txtの内容を教えていただければ、
それで何か分かるかもしれないです。もしよかったら教えてください。

[ ]
RE:02511 期待したものとは別のアカウントNo.02513
緒方聡 さん 09/08/07 11:29
 
>■3.もしかしてですが、「送受信の開始直前」の所に何かマクロかDLLを登録
>されているとしたら、それが関係してるってことは無いでしょうか。例えばその
>マクロで別アカウントを選択するようなことをすると、そっちで受信が開始され
>てしまいます。

マクロを DLL 化した以下のコードが原因でした。

extern "C" void _cdecl AtSendReceive() {
 int n = GetTransmitCommandCode();
 if (n == 40003 ||   // 受信
   n == 40216 ||  // 送受信
   n == 40024 ||  // すべて送受信
   n == 40143 ||  // すべて受信
   n == 40074 ||  // リモートメール
   n == 40209 ||  // リモートメール - 現在メールの再受信
   n == 1) {   // 定期受信
  int i = 0;
  while (true) {
   std::string account(Account(i));
   if (account == "") {
    break;
   }
   LoadAccountProp(account.c_str());
   SetAccountProp("fRecvLog", 1);
   SaveAccountProp();
   i++;
  }
  DWORD filterLog = 2;
  set_reg_value(FILTER_LOG_KEY, REG_DWORD, (CONST BYTE *)&filterLog, sizeof
DWORD);
  EnvChanged();
 }
}

以下は元のマクロで、同じ処理をしていますが、こちらだと問題が発生しません。


#n = dllfunc("GetTransmitCommandCode");
if (#n == 40003 ||
  #n == 40216 ||
  #n == 40024 ||
  #n == 40143 ||
  #n == 40074 ||
  #n == 40209 ||
  #n == 1) {
 #i = 0;
 while (true) {
  $account = dllfuncstr("Account", #i);
  if ($account == "") {
   break;
  }
  #n = dllfunc("LoadAccountProp", $account);
  #n = dllfunc("SetAccountProp", "fRecvLog", 1);
  #n = dllfunc("SaveAccountProp");
  #i = #i + 1;
 }
 openreg "CURRENTUSER", "Software\\Hidemaruo\\TuruKame\\Config";
 writeregnum "FilterLog", 2;
 closereg;
 #n = dllfunc("EnvChanged");
}


DLL のコードが断片ですみません。
必要であれば、すべてお送りします。

[ ]
RE:02513 期待したものとは別のアカウントNo.02514
秀まるお さん 09/08/07 12:14
 
 まだテストしてませんが、EnvChangedがだめだと思います。

 EnvChangedを呼び出すと、極端に言うなら秀丸メールを一度終了してまた起動
しなおすのに似たような処理が動きます。

 EnvChangedを呼ばないように直してもらうわけにはいかないのでしょうか。ど
うしてもそこが鬼門になって、対応に大変手間がかかっています。

 振り分けログをどうしも見る必要があるということでしたら、DLLの動作条件
に「振り分けログをONにする必要があります」みたいな条件をつける、という作
戦にしてもいいんじゃないかと思います。というか、どっちにしてもDLLの中で
勝手に設定を書き換えているわけだから、DLLの動作条件としてそういう条件を
つけて困るユーザーさんはいないんじゃないかと思いますけども。

 ということでどうでしょ?

 それか、僕のサンプルみたいに

 GetLastRecvMailSubject
 GetLastRecvMailFrom
 GetLastRecvMailBodyTop

 を使うように直してもらうのがパフォーマンス的にはいいんじゃないかとは思
います。

[ ]
RE:02514 期待したものとは別のアカウントNo.02515
秀まるお さん 09/08/07 12:19
 
 っとコメントしたところでしたが、マクロのEnvChagnedだと問題なくて、DLL
からEnvChagnedするとだめということで、これはこれで何か原因があると思うの
で、どっちにしても調べて修正させていただきます。

[ ]
RE:02514 期待したものとは別のアカウントNo.02516
秀まるお さん 09/08/07 12:25
 
 1つわかりました。

 EnvChanged関数のパラメータを省略されてるのが原因だと思います。

 EnvChanged関数の宣言を、

   void (_cdecl* EnvChanged)( int fReloadAll );

 みたいに宣言した上で、

 EnvChanged( 0 );

 のように呼び出さないとだめです。

 マクロではパラメータを省略してもいいですが、DLLを直接呼び出すときは、
パラメータを省略した場合にはそこには不定な値が指定されたのと同じになって
しまいます。大抵はその値は0以外になるので、それでフォルダ枠も含めて全部
リフレッシュされてるのだと思います。

 ちなみに秀丸マクロのdllfuncでは、パラメータが省略されて呼び出されても
うまくいくように、dllfunc関数で指定されたパラメータよりも4つほど余計に、
数値の0のパラメータをスタックにpushしてから関数を呼び出すようなつくりに
なっています。

[ ]
RE:02516 期待したものとは別のアカウントNo.02517
秀まるお さん 09/08/07 13:04
 
 サンプルDLLでテストしてみたところ、やはりEnvChanged関数呼び出しパラ
メータ次第のようでした。

 EnvChagned( 0 ); だとうまくいきますが、EnvChagned( 1 );だとぜんぜん関
係ないアカウントで受信してしまいました。

 ということで、とりあえずEnvChanged関数呼び出しに数値パラメータの「0」
を追加するということでお願いします。ほかもtkinfo.dllの関数を直接callする
場合、パラメータの省略はできないということでお願いします。



 EnvChanged( 1 )とされた場合におかしくなる件については、これも直すに越
したことはないので、なんとか原因を調べて修正したいと思います。(もし可能
なら)

[ ]
RE:02517 期待したものとは別のアカウントNo.02518
秀まるお さん 09/08/07 16:59
 
 EnvChagnedのパラメータが0以外の時におかしくなるのも、調べてみたらやは
り元々のバグでした。

 マクロのEnvChagned関数でも起こりえるようです。

 ということでどっちにしても、こちらのバグも修正させていただきます。

[ ]
RE:02518 期待したものとは別のアカウントNo.02519
緒方聡 さん 09/08/08 22:30
 
EnvChanged(0) のように呼び出すことで、
期待通りの動作になりました。

dllfunc での使われ方だけを見て関数のプロトタイプを
定義していましたが、これからはヘルプを見るようにします。

なお、ヘルプに

  返り値(数値型)
    返り値に意味はありません。

と書かれている場合、返り値は void ということでよいでしょうか?

[ ]
RE:02514 期待したものとは別のアカウントNo.02520
緒方聡 さん 09/08/08 23:16
 
> それか、僕のサンプルみたいに
>
> GetLastRecvMailSubject
> GetLastRecvMailFrom
> GetLastRecvMailBodyTop
>
> を使うように直してもらうのがパフォーマンス的にはいいんじゃないかとは思
>います。

これは興味があります。
現在は、受信ログを直接読んで、メールを自前でデコードしたりして
とても複雑なので、上記関数を使えば、ソースコード量が 1/3 ぐらいに
なるような気がしています。

まずマクロを DLL 化して安定させ、それから上記への置き換えに
取り組んでみようと思います。

[ ]
RE:02519 期待したものとは別のアカウントNo.02521
秀まるお さん 09/08/09 15:27
 
 返り値に意味が無い関数についてはvoid宣言していただくのが適当だと思いま
す。

[ ]