起動時の自動実行マクロで送受信後DLL初期 - 秀丸メール・バグ関係 - スレッド06174, 2001/11/27

起動時の自動実行マクロで送受信後DLL初期

WIZ さん　01/11/27 19:53

WIZです。

不具合なのかうちの環境かわからないんですが、

NT4.0 Server SP6a
鶴亀メール 1.48
IE5.5 SP2
LAN接続

の環境で、全般的な設定の送受信→接続で、

・ダイヤルアップ接続を Windows側にまかせる
・送受信が終わった後のダイヤルアップ接続の切断
　を切断する

で以下のマクロを起動時の実行指定にしている場合、
マクロの実行終了後にDLLの初期化エラーがでます。
なお、起動後に手動でマクロを実行した場合はDLLの
初期化エラーが出ることはありません。リモートア
クセスサービスは一時期入れてましたが削除したと
ころこの現象に遭遇しています。細かいメッセージ
は手元に環境が無いんですぐに確認できないので申
し訳ないです。又、明らかに RAS???.DLL が無いか
らDLLの初期化エラーになるのは仕方ないんですが、
起動時に自動実行した時だけってのが不可解で…。
-------------------------------------------------
loaddll "TKInfo.dll";
if(result) {
#n = dllfunc("TransmitAll");
}
endmacro;
-------------------------------------------------

RE:06174 起動時の自動実行マクロで送受信

ひろさん　01/11/27 20:17

　WIZ さん今日は、ひろです。
　解法は解りませんが、気付いた部分に回答します。

> 鶴亀メール 1.48
　Ver.1.52 がでています。

> ・ダイヤルアップ接続を Windows側にまかせる
> ・送受信が終わった後のダイヤルアップ接続の切断
> 　を切断する
　OS の種類によって設定項目が変わりますので、外しているかもしれません
が Windows 側の設定がもっと詳細に解れば、何かの手助けになるかもしれま
せん。

> loaddll "TKInfo.dll";
　この様な目的ならば、マクロは末尾のような物の方がよいでしょう。

　また不具合報告の場合、「全般的な設定」→「基本」→「詳細」の「鶴亀
メールの動作をdump.txtに記録する（デバッグモード）」を ON にすると、
「ホームディレクトリ」に dump.txt が作成されるので、起動後の内容をこ
ちらにアップすると、良いかもしれません。

//---------------- trasmit.mac --------------------------------------
loaddll "TKInfo.dll";
if(result)#tmp = dllfunc("StartReceiveAll");
freedll;
endmacro;

RE:06175 起動時の自動実行マクロで送受信

WIZ さん　01/11/27 22:30

　ひろさん、こん○○は。

>> ・ダイヤルアップ接続を Windows側にまかせる
>> ・送受信が終わった後のダイヤルアップ接続の切断
>> 　を切断する
>　OS の種類によって設定項目が変わりますので、外しているかもしれません
>が Windows 側の設定がもっと詳細に解れば、何かの手助けになるかもしれま
>せん。
単純にLAN経由の接続で、IPアドレスと Defautl Gayteway を
ルーターと同じセグメントを指定すれば、そのままルーター直
でインターネットに接続できる設定なんですよ。ダイアルアッ
プの定義はして無いし。

>　また不具合報告の場合、「全般的な設定」→「基本」→「詳細」の「鶴亀
>メールの動作をdump.txtに記録する（デバッグモード）」を ON にすると、
>「ホームディレクトリ」に dump.txt が作成されるので、起動後の内容をこ
>ちらにアップすると、良いかもしれません。
ずっと、デバッグモードで dump は取りつづけているんで、こ
の時も取っているんですが、出社しないことには…。

そうそう、最新は1.52ですか。寝込んでて、1.51～で確認でき
てないんで、1.52で改めて再現テストをやらないとだめですね。
1.50までのままかと(汗)　改版履歴を見ると、1.50→1.51の時、
ダイアルアップ接続の切断処理で修正が入っているので、直っ
ているのかな(汗)

それと、ご指摘いただいたマクロですが…実は、受信メールが
ある場合の後処理をごちゃごちゃやってまして…。純粋に、
「送受信のみ」の場合でも同じだったんで、最小限のソースだ
け載せてたんです。

RE:06176 起動時の自動実行マクロで送受信

ひろさん　01/11/28 12:10

　WIZ さん今日は、ひろです。
> 単純にLAN経由の接続で、IPアドレスと Defautl Gayteway を
> ルーターと同じセグメントを指定すれば、そのままルーター直
> でインターネットに接続できる設定なんですよ。ダイアルアッ
> プの定義はして無いし。
　それではなぜ、
> > ・ダイヤルアップ接続を Windows側にまかせる
> > ・送受信が終わった後のダイヤルアップ接続の切断
> > 　を切断する
としているのでしょう? もっと単純に、
・LAN 接続
・切断しない
にするのが妥当だと思います。私が想像しているルータとな何か違うのかな?

> ずっと、デバッグモードで dump は取りつづけているんで、こ
> の時も取っているんですが、出社しないことには…。
　これで何か解ると良いですね。

> それと、ご指摘いただいたマクロですが…実は、受信メールが
> ある場合の後処理をごちゃごちゃやってまして…。純粋に、
> 「送受信のみ」の場合でも同じだったんで、最小限のソースだ
> け載せてたんです。
　あらら、そうだったんですか、役に立たない回答ですいません。

RE:06178 起動時の自動実行マクロで送受信

WIZ さん　01/11/28 19:47

ひろさん今日は、WIZです。

>> > ・ダイヤルアップ接続を Windows側にまかせる
>> > ・送受信が終わった後のダイヤルアップ接続の切断
>> > 　を切断する
>としているのでしょう? もっと単純に、
>・LAN 接続
>・切断しない
>にするのが妥当だと思います。私が想像しているルータとな何か違うのかな?
確かに妥当だと思いますし、返す言葉も無いです。ただ、
なぜ、「マクロの自動起動→鶴亀起動時」で指定したマク
ロの実行の時だけ？と。定期受信や手動での送受信、鶴亀
起動後に同じマクロを実行した場合は rasman.dll の初期
化エラーが出てこないので…。仕様ならそれでもOKです。

dump.txt
アカウントやListコマンドの内容等は省略/伏字にしてます。
時間帯が、10:54の送受信が起動時のマクロによる送受信で、
11:09の受信が定期受信の時の内容です。
-----------------------
10:54:02.954 ( 986) 鶴亀開始 V1.52 IEVersion=5, fWin98=0, fWin2000=0 fLargeM
em=1
10:54:02.994 ( 775) HmCreate
10:54:02.994 (3818) call WinMainSub
10:54:03.004 (3818) FrameWndProc: WM_CREATE
10:54:03.004 (3818) ClientWndProc: WM_CREATE
10:54:03.034 (3818) return WinMainSub
10:54:03.034 ( 777) HmCreate return
10:54:03.205 ( 931) AddIconToTaskbar()
10:54:03.205 ( 933) AddIconToTaskbar() Do.
10:54:03.205 (6104) StartAutoDownTimer()
10:54:03.205 (6112) StartAutoDownTimer() set
10:54:03.215 (3011) entered
10:54:03.215 (3818) CommandMacroSub TKStartUp.mac
10:54:03.255 (5324) ProcessCommand 40024
10:54:03.255 (3250) EnterTrans(), dwRet = 0
10:54:03.255 (3260) EnterTrans() entered
10:54:03.255 (2109) ProcessTransmitSub()
10:54:03.255 (2112) fSetReceivedIcon = 0
10:54:03.265 ( 583) RASSUB::EnsureOnline()
10:54:03.265 ( 592) RASSUB: GetConnectedState
10:54:03.565 ( 594) RASSUB: already connected
10:54:03.565 ( 433) CSock::CSock()
10:54:03.565 (2219) ProcessTransmitSub() new pSock
10:54:03.565 (2239) ProcessTransmitSub() ModelessDialog, TransDlgProc
10:54:03.565 ( 56) SilentDialogBox()
10:54:03.565 (1643) TransDlgProc() WM_INITDIALOG
10:54:03.565 (1661) IDTIMER_TRANS_START set
10:54:03.575 (1724) IDTIMER_TRANS_START kill
====== 2001/11/28 10:54:03 mode=送信 account=********@*********.com
10:54:03.575 ( 523) CSock::PostExit()
10:54:03.575 (1934) IDTIMER_SOCKET_END received
10:54:03.575 (1973) IDTIMER_TRANS_START post
10:54:03.575 (1724) IDTIMER_TRANS_START kill
10:54:03.575 ( 677) CSock::StartRecvSub()
10:54:03.575 ( 488) CScok: WSAStartup() done
====== 2001/11/28 10:54:03 mode=受信 account=********@*********.com
サーバーを検索中 - *********.com
接続中
R +OK QPOP (version 2.53) at *********.com starting. <44834.1006912347@****
*****.com>
S USER ********
R +OK Password required for ********.
S PASS ****
R +OK ******** has 3 messages (39851 octets).
S STAT
R +OK 3 39851
S UIDL
R +OK uidl command accepted.
: : : : : : : :
.
R ...(111バイト)
S LIST
R +OK 3 messages (39851 octets)
: : : : : : : :
.
R ...(28バイト)
S QUIT
R +OK Pop server at *********.com signing off.
10:54:05.147 ( 523) CSock::PostExit()
10:54:05.147 (1934) IDTIMER_SOCKET_END received
10:54:05.147 (1973) IDTIMER_TRANS_START post
10:54:05.147 (1724) IDTIMER_TRANS_START kill
====== 2001/11/28 10:54:05 mode=送信 account=********@*********.com
10:54:05.147 ( 523) CSock::PostExit()
10:54:05.147 (1934) IDTIMER_SOCKET_END received
10:54:05.147 (1973) IDTIMER_TRANS_START post
10:54:05.147 (1724) IDTIMER_TRANS_START kill
10:54:05.177 ( 677) CSock::StartRecvSub()
====== 2001/11/28 10:54:05 mode=受信 account=********@*********.com
サーバーを検索中 - ****.*********.com
接続中
R +OK <28335.1006912348@*********.com>
: : : : : : : :
S QUIT
R +OK
10:54:07.260 ( 523) CSock::PostExit()
10:54:07.260 (1934) IDTIMER_SOCKET_END received
10:54:07.260 (1973) IDTIMER_TRANS_START post
10:54:07.260 (1724) IDTIMER_TRANS_START kill
====== 2001/11/28 10:54:07 mode=送信 account=invalid@*********.com
10:54:07.270 ( 523) CSock::PostExit()
10:54:07.270 (1934) IDTIMER_SOCKET_END received
10:54:07.270 (1973) IDTIMER_TRANS_START post
10:54:07.270 (1724) IDTIMER_TRANS_START kill
10:54:07.270 ( 677) CSock::StartRecvSub()
====== 2001/11/28 10:54:07 mode=受信 account=invalid@*********.com
サーバーを検索中 - ****.*********.com
接続中
R +OK <28348.1006912350@*********.com>
: : : : : : : :
S QUIT
R +OK
10:54:07.781 ( 523) CSock::PostExit()
10:54:07.781 (1934) IDTIMER_SOCKET_END received
10:54:07.781 (1973) IDTIMER_TRANS_START post
10:54:07.781 (1724) IDTIMER_TRANS_START kill
====== 2001/11/28 10:54:07 mode=送信 account=*******@****.freemail.ne.jp
10:54:07.791 ( 523) CSock::PostExit()
10:54:07.791 (1934) IDTIMER_SOCKET_END received
10:54:07.791 (1973) IDTIMER_TRANS_START post
10:54:07.791 (1724) IDTIMER_TRANS_START kill
10:54:07.791 ( 677) CSock::StartRecvSub()
====== 2001/11/28 10:54:07 mode=受信 account=*******@****.freemail.ne.jp
サーバーを検索中 - ****.freemail.ne.jp
接続中
R +OK <27466.1006912349@****.freemail.ne.jp>
: : : : : : : :
S QUIT
R +OK
10:54:09.093 ( 523) CSock::PostExit()
10:54:09.093 (1934) IDTIMER_SOCKET_END received
10:54:09.093 (1973) IDTIMER_TRANS_START post
10:54:09.093 (1724) IDTIMER_TRANS_START kill
10:54:09.093 (1745) IDTIMER_TRANS_END set
10:54:09.393 (1931) IDTIMER_TRANS_END kill
10:54:09.393 ( 103) EndSilentDialog()
10:54:09.393 (2002) TransDlgProc() WM_DESTROY
10:54:09.393 ( 97) SilentDialogBox() exit
10:54:09.393 (2241) ProcessTransmitSub() ModelessDialog, TransDlgProc exit
10:54:09.393 (1050) RestoreTransmitTaskbarIcon()
10:54:09.393 ( 956) SetReceivedTaskbarIcon Reset!
10:54:09.393 ( 986) 常駐鶴亀アイコンを戻します。
10:54:09.393 ( 998) 鶴亀本体アイコンを戻します。
10:54:09.393 ( 168) RASSUB::HangupDialupNetwork()
10:54:12.628 ( 452) CSock::~CSock()
10:54:12.628 (2340) ProcessTransmitSub() exit
10:54:12.628 (3265) LeaveTrans()
10:54:12.628 (6104) StartAutoDownTimer()
10:54:12.628 (6112) StartAutoDownTimer() set
10:54:12.638 (3018) leave
11:09:12.632 (3617) FrameWndProc() IDTIMER_AUTODOWN
11:09:12.632 (6124) StopAutoDownTimer()
11:09:12.632 (3002) CTrans::AutoDown()
11:09:12.632 (3250) EnterTrans(), dwRet = 0
11:09:12.632 (3260) EnterTrans() entered
11:09:12.632 (2109) ProcessTransmitSub()
11:09:12.632 (2112) fSetReceivedIcon = 0
11:09:12.642 ( 583) RASSUB::EnsureOnline()
11:09:12.642 ( 592) RASSUB: GetConnectedState
11:09:12.642 ( 594) RASSUB: already connected
11:09:12.642 ( 433) CSock::CSock()
11:09:12.642 (2219) ProcessTransmitSub() new pSock
11:09:12.642 (2239) ProcessTransmitSub() ModelessDialog, TransDlgProc
11:09:12.642 ( 56) SilentDialogBox()
11:09:12.642 (1643) TransDlgProc() WM_INITDIALOG
11:09:12.642 (1661) IDTIMER_TRANS_START set
11:09:12.652 (1724) IDTIMER_TRANS_START kill
11:09:12.652 ( 677) CSock::StartRecvSub()
====== 2001/11/28 11:09:12 mode=受信 account=********@*********.com
サーバーを検索中 - *********.com
接続中
R +OK QPOP (version 2.53) at *********.com starting. <47427.1006913256@****
*****.com>
S USER ********
R +OK Password required for ********.
S PASS ****
R +OK ******** has 4 messages (69093 octets).
S STAT
R +OK 4 69093
S UIDL
R +OK uidl command accepted.
: : : : : : : :
.
R ...(147バイト)
S LIST
R +OK 4 messages (69093 octets)
: : : : : : : :
.
R ...(37バイト)
S RETR 4
R +OK 29242 octets
: : : : : : : :
.
R ...(29245バイト)
11:09:20.153 (1467) fSetReceivedIcon ++
11:09:20.163 (1781) サーバー上に残す
S QUIT
R +OK Pop server at *********.com signing off.
11:09:20.433 ( 523) CSock::PostExit()
11:09:20.433 (1934) IDTIMER_SOCKET_END received
11:09:20.433 (1973) IDTIMER_TRANS_START post
11:09:20.433 (1724) IDTIMER_TRANS_START kill
11:09:20.444 ( 677) CSock::StartRecvSub()
====== 2001/11/28 11:09:20 mode=受信 account=********@*********.com
サーバーを検索中 - ****.*********.com
接続中
R +OK <7101.1006913264@*********.com>
: : : : : : : :
S QUIT
R +OK
11:09:27.163 ( 523) CSock::PostExit()
11:09:27.163 (1934) IDTIMER_SOCKET_END received
11:09:27.163 (1973) IDTIMER_TRANS_START post
11:09:27.163 (1724) IDTIMER_TRANS_START kill
11:09:27.163 ( 677) CSock::StartRecvSub()
====== 2001/11/28 11:09:27 mode=受信 account=invalid@*********.com
サーバーを検索中 - ****.*********.com
接続中
R +OK <7228.1006913270@*********.com>
: : : : : : : :
S QUIT
R +OK
11:09:28.215 ( 523) CSock::PostExit()
11:09:28.215 (1934) IDTIMER_SOCKET_END received
11:09:28.215 (1973) IDTIMER_TRANS_START post
11:09:28.215 (1724) IDTIMER_TRANS_START kill
11:09:28.215 ( 677) CSock::StartRecvSub()
====== 2001/11/28 11:09:28 mode=受信 account=*******@****.freemail.ne.jp
サーバーを検索中 - ****.freemail.ne.jp
接続中
R +OK <12241.1006913270@****.freemail.ne.jp>
: : : : : : : :
S QUIT
R +OK
11:09:30.638 ( 523) CSock::PostExit()
11:09:30.638 (1934) IDTIMER_SOCKET_END received
11:09:30.638 (1973) IDTIMER_TRANS_START post
11:09:30.638 (1724) IDTIMER_TRANS_START kill
11:09:30.638 (1745) IDTIMER_TRANS_END set
11:09:30.939 (1931) IDTIMER_TRANS_END kill
11:09:30.939 ( 103) EndSilentDialog()
11:09:30.939 (2002) TransDlgProc() WM_DESTROY
11:09:30.939 ( 97) SilentDialogBox() exit
11:09:30.939 (2241) ProcessTransmitSub() ModelessDialog, TransDlgProc exit
11:09:30.939 (1050) RestoreTransmitTaskbarIcon()
11:09:30.939 ( 956) SetReceivedTaskbarIcon Reset!
11:09:30.939 ( 986) 常駐鶴亀アイコンを戻します。
11:09:30.939 ( 998) 鶴亀本体アイコンを戻します。
11:09:30.939 ( 168) RASSUB::HangupDialupNetwork()
11:09:30.939 ( 452) CSock::~CSock()
11:09:30.939 (2281) fSetReceivedIcon != 0
11:09:30.939 ( 954) SetReceivedTaskbarIcon Set!
11:09:30.949 (2340) ProcessTransmitSub() exit
11:09:30.949 (3265) LeaveTrans()
11:09:30.949 (3076) CTrans::AutoDown() exit
11:09:30.949 (6104) StartAutoDownTimer()
11:09:30.949 (6112) StartAutoDownTimer() set
11:09:48.073 ( 956) SetReceivedTaskbarIcon Reset!
11:09:48.073 ( 986) 常駐鶴亀アイコンを戻します。
11:09:48.073 ( 998) 鶴亀本体アイコンを戻します。
11:09:48.133 ( 931) AddIconToTaskbar()

RE:06179 起動時の自動実行マクロで送受信

ひろさん　01/11/28 20:28

　WIZ さん今日は、ひろです。
> なぜ、「マクロの自動起動→鶴亀起動時」で指定したマク
> ロの実行の時だけ？
　これに関しては仰るとおりです。だから最初に
> 　解法は解りませんが、気付いた部分に回答します。
と逃げていたりします。

　ただアップしていただいたマクロでは、私の環境ではエラーが再現しません???

RE:06180 起動時の自動実行マクロで送受信

WIZ さん　01/11/28 20:56

ひろさんこんにちは、WIZです。

>> 　解法は解りませんが、気付いた部分に回答します。
>と逃げていたりします。
　誤解を与える内容になってすみません。面目ないで
す。

>　ただアップしていただいたマクロでは、私の環境ではエラーが再現しません???
　と言うことは、リモートアクセスサービスをインス
トールして無くても rasman.dll は入っているってこ
と？　で、リモートアクセスサービスの追加/削除を行
うと rasman.dll を初めとするDLLがなくなる？　なら、
追加/削除をしたのが原因？　リモートアクセスサービ
スの追加/削除が原因なら、鶴亀は無罪ですね。

RE:06181 起動時の自動実行マクロで送受信

秀まるお さん　01/11/29 16:15

　長らくお待たせしました。結論から言われていただくと、DLLのロードエ
ラーが出るのは仕様です。

　このエラーを出しているのはWindowsでして、鶴亀メールで抑制することが
出来ません。

　鶴亀メールはリモートアクセスサービスがインストールされるかどうかを、
RASAPI32.DLLのロードに成功するかどうかで判断しています。これのロードに
失敗すると、RASはインストールされてない物と見なします。この「ロードを
試みる」ということをすると、なぜかWindowsがエラーメッセージを出してし
まいます。

　僕の記憶が正しければ、このエラーが出るのはWindowsNT4.0だけです。

　他に何か適当なリモートアクセスサービスがインストールされてるかどうか
の判定方法があればいいんですが、とりあえず思いつかないです。

　そもそも、こういう状況になるのはダイヤルアップ接続を切断する設定にし
た場合の話なので、使う側で対処できます。ということで、そういう仕様って
ことにさせていただきます。

RE:06184 起動時の自動実行マクロで送受信

WIZ さん　01/11/29 16:59

秀まるおさん、こんにちは。WIZです。

仕様と言うことで了解しました。結局RASはインストールしました。
最初の送受信でエラーが出る/出ないの違いは、送受信の鶴亀の状態
やタイミングの問題かな。

ともあれ、お手数おかけしました。

RE:06184 起動時の自動実行マクロで送受信

WIZ さん　01/11/30 16:51

秀まるおさん、こんにちは。WIZです。

話の流れのついでで、1点質問させて下さい。RASの入ってな
いNT4.0(SV SP6a)で、

・鶴亀起動時に実行するマクロで送受信を行うと、Windowsが
　DLLのロード失敗のメッセージを出す。

・鶴亀起動時に実行するマクロで送受信を行わなければ、鶴
　亀が起動した後に手動／定期／マクロ等で送受信をしても、
　WindowsがDLLのロード失敗のメッセージを出す事は無い。

と、同じ環境でエラーメッセージが出ない条件(偶然？)もあ
るので、しつこいと思われるかもしれませんが、質問させて
もらいました。初回の送受信の時は必ず出るとかであれば、
疑問はないんですが。

あっ、Windows が勝手に出してるメッセージを制御して出さ
ないようにしてくれ、ってわけじゃないんです。やっぱり、
どこかでRASAPI32.DLLのロード成功失敗を一度は見ていると
思うんですが、出ない条件(偶然？)がある、と言うのがやっ
ぱり気になってしまって…。

RE:06193 起動時の自動実行マクロで送受信

WIZ さん　01/11/30 21:45

質問の内容書いてませんでしたm(__)m
------------------------------------------------------
>・鶴亀起動時に実行するマクロで送受信を行うと、Windowsが
>　DLLのロード失敗のメッセージを出す。
>
>・鶴亀起動時に実行するマクロで送受信を行わなければ、鶴
>　亀が起動した後に手動／定期／マクロ等で送受信をしても、
>　WindowsがDLLのロード失敗のメッセージを出す事は無い。

この2つの相反する状態が発生するのは、Windows依存ってこと
になるのでしょうか？
------------------------------------------------------
ってのが質問させてもらいたかったことですm(__)m
差しさわりがなければって事で。

RE:06194 起動時の自動実行マクロで送受信

秀まるお さん　01/12/02 11:00

　僕はもうWindowsNT4.0を最近メインでは使ってないのでなんですが、たぶん、
Windows側がインテリジェントに判断してエラーメッセージを出したり出さな
かったりしているんだと思います。そうでなければ、例えばRAS関係のロード
タイミングとWININET.DLLのロードタイミングの順序の違いによる影響かもし
れません。

　どっちにしても、運用上の工夫で対処してもらえるって話なので、詳しい原
因調査は省略させていただきます。

RE:06196 起動時の自動実行マクロで送受信

WIZ さん　01/12/02 11:56

秀まるおさん、こんにちは。WIZです。

>かったりしているんだと思います。そうでなければ、例えばRAS関係のロード
>タイミングとWININET.DLLのロードタイミングの順序の違いによる影響かもし
>れません。
RAS関係とWININET.DLLロードの順番が違うという差はあるんですね。
もし、まったく全ての処理の流れが同じで…ってことになると、考え
込むところだったんですが、これなら納得です。手が空きそうになっ
たら、VC++辺りでこの辺のコードでも書いて試して見ようかな。お手
数おかけしました。