TKRetunToFolder.macについて - 公開マクロサポート会議室（秀丸メール関連） - スレッド00193, 2008/05/02

TKRetunToFolder.macについて

山紫水明 さん　08/05/02 21:00

hajimett さん，
秀丸メールサポート会議室より移りました。

>ソート順が「元に戻る」のではなく、
>送受信昇順（かな？）に「変更」されてしまいます。

　多分設定に関係しているのかなと思います。
「フォルダごのメール一覧のソート方法」が「フォルダごとに設定」になってい
ると思いますが，いかがでしょう。
　このマクロを公開した時は多分この辺の細かい設定はなかったのかも知れませ
ん。私自身はこの設定をしていませんでしたので気がつきませんでした。
　ここは確かにマクロに手を入れる必要がありそうです。

　では，　(^^)/~
　　　　　　　　　　　　山紫水明

RE:00193 TKRetunToFolder.macについて

hajime さん　08/05/08 12:52

山紫水明さま
>「フォルダごのメール一覧のソート方法」が
>「フォルダごとに設定」になっていると思いますが，いかがでしょう。
ご指摘の通りでした。設定変更により問題は解決。
大変便利に使わせていただいております。
ご丁寧にありがとうございました。

RE:00196 TKRetunToFolder.macについて

山紫水明 さん　08/05/08 20:18

　hajimeさん，

>ご指摘の通りでした。設定変更により問題は解決。

設定を変更しなくても，ソート順が戻るようにしてみました。
こちらがよろしければ，お試しください。
http://homepage2.nifty.com/12sun/sansui.html

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00197 TKRetunToFolder.macについて

hajime さん　08/05/13 02:44

山紫水明さま　さっそくありがとうございます。

ところで、ドキュメントファイル記載
「秀丸エディタ＆鶴亀メール常連さんフォーラム」
という表現は、せっかくファイル名も変えたことですし修正しても、
っておもいました。トリビアルなことで申し訳ありません。

設定は、秀丸メールで件の設定を変えようとすると
「スレッド表現でも使う場合はこっちが便利だよ」と
フォルダ毎の設定に、指導的に（半ばデフォルト的に？）
変更を誘導されるためにそう設定しただけなんです。
どうして、その方が便利なのか、分かってさえないんです。
だから、古いままでも構わなかったんですが。

どうして、フォルダ毎の方が便利なんでしょうね。
指導的に誘導するからにはきっと重要な違いがあるんだと
思うんですが・・・
＃なんかまた、板違い的な内容になってしまったかな。

RE:00200 TKRetunToFolder.macについて

hajime さん　08/05/13 03:22

山紫水明さま　改訂版使ってみました。
メールリストのフォーカスが、移動処理したあと
ソートの最も遠いところに飛んでいってしまいます。
これですと、元のマクロの方が有り難いです。
細かく検証したわけではありませんが、とりあえず、
気づいたところを書きました。

RE:00201 TKRetunToFolder.macについて

山紫水明 さん　08/05/13 20:43

　hajimeさん，

　御報告ありがとうございます。

>ところで、ドキュメントファイル記載「秀丸エディタ＆鶴亀メール常連さんフ
>ォーラム」という表現は、せっかくファイル名も変えたことですし修正しても、
>っておもいました。トリビアルなことで申し訳ありません。

　その通りでした。修正いたします。

>どうして、フォルダ毎の方が便利なんでしょうね。
>指導的に誘導するからにはきっと重要な違いがあるんだと思うんですが・・・

　私も理由はよくわかりません。ただ，「ヘルプ」によれば，
---------------------------------------
　例えば、特定のフォルダに特定のメーリングリストのメールを振り分けるよう
にしていて、そこのフォルダでのメールのソート方法をSubject順にしたい、と
いう場合は、「フォルダ毎に個別」を指定してください。
　一般には、「すべてのフォルダ共通」にしておくだけでも不便なことは無いと
思います。
---------------------------------------
ということのようです。

>メールリストのフォーカスが、移動処理したあと
>ソートの最も遠いところに飛んでいってしまいます。

　修正の結果，他のところで具合が悪くなりました。やはり，自分とは異なった
設定の方に試行していただくとバグがわかります。
　修正したものを，再度アップしておきました。

　では，　(^^)/~
山紫水明

RE:00202 TKRetunToFolder.macについて

hajime さん　08/05/16 01:10

>　例えば、特定のフォルダに特定のメーリングリストのメールを振り分
最初の[...]をとって、とかいう設定をしていうと便利とか
そういう絡みなんでしょうか。

さて、
新しいマクロ　つかってみました

これまでのものにもあった現象かも知れませんが
「
スレッド表示状態から返信編集開始→送信
自動振り分け（ゴミ箱行き）が機能しゴミ箱に移動
」
という事例で、期待される動作は、
とりあえず返信元のメールにフォーカスがあった状態で
スレッド表示状態を保つことなんですが、
一覧表示に変わっちゃう場合があります。
再現パタンの検証するほど事例も積んでませんし、
たぶん他の振り分けでどうなるんだろうってのも
ありますが、その辺未検証です。
曖昧な情報で、申し訳ありませんが、一応ご報告を。

また、一番古いマクロに戻していたときに生じた現象ですが、
送信済みメールを再編集して送信したとき、
受信フォルダにいってしまう（残ってしまう？）という
現象が生じましたが、あたらしいバージョンでは生じていません。
（改良されたってことかもしれませんが）
単に再現性の問題かも知れないと思って、一応ご報告します。

RE:00203 TKRetunToFolder.macについて

山紫水明 さん　08/05/17 16:38

　hajimeさん，

>とりあえず返信元のメールにフォーカスがあった状態でスレッド表示状態を保
>つことなんですが、一覧表示に変わっちゃう場合があります。

　一覧表示に変わるのではなく，スレッド表示だけれども，スレッドが閉じてし
まうということではないでしょうか？そうであれば，これは今のところ仕様，と
いうか，送信済みメールにフォーカスをあわせる処理の関係上，どうしてもそう
なってしまいます。解決方法が見つかれば，修正したいところです。

　それから，振り分けられた時には，振り分け先にフォーカスを移せるようにし
た方がいいかもしれないなとも考えています。

>送信済みメールを再編集して送信したとき、受信フォルダにいってしまう（残
>ってしまう？）という現象が生じましたが、あたらしいバージョンでは生じて
>いません。
>（改良されたってことかもしれませんが）

　草稿フォルダにいったん保存すると，送信元に戻らないということがあり，そ
こを改良しましたので，そのおかげでそちらの現象もなくなったのかも知れませ
ん。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00204 TKRetunToFolder.macについて

hajime さん　08/05/20 21:50

大体パタンが分かってきました。
スレッド表示から返信作成し始めても、
振り分け設定が絡むと、一覧表示になっちゃうようです。
マクロ処理の途中で横取りされちゃうんでしょうか？
ちなみに、振り分け先が編集開始フォルダと同じ場合
にそのような現象を多く観察しております。
＃振り分けられているのですからそうであるのが自然なのでしょうが。

>>送信済みメールを再編集して送信したとき、受信フォルダにいってしまう（残
>>ってしまう？）という現象が生じましたが、あたらしいバージョンでは生じて
>>いません。
>>（改良されたってことかもしれませんが）
>
>　草稿フォルダにいったん保存すると，送信元に戻らないということがあり，そ
>こを改良しましたので，そのおかげでそちらの現象もなくなったのかも知れませ
>ん。

最近、送信済みメールを再編集して送信したら、
送信済みフォルダに残っちゃうって現象が生じました。
これも再現パタンがつかめないんですが、
なんだかやっぱり複雑ですね。。。

RE:00205 TKRetunToFolder.macについて

hajime さん　08/05/28 10:41

続きのご報告
やはり
振り分け設定と競合した気に、スレッド表示で編集はじめても
振り分け終わったときに一覧表示になってしまうようです
おなじフォルダで毎回生じますので再現性はばっちりです
ちょっとこれでは不便な点もあるので、
古いマクロに戻して使っています。
なにか確認するべき事項があればご指摘ください。

RE:00208 TKRetunToFolder.macについて

山紫水明 さん　08/06/01 09:29

　hajimeさん，

>振り分け設定と競合した気に、スレッド表示で編集はじめても
>振り分け終わったときに一覧表示になってしまうようです

　その後，少し方式を変更してやっていましたが，十分なテストができないまま
になっていました。
　ベータ版としてあげておきますので，よろしければ試してください。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00213 TKRetunToFolder.macについて

hajime さん　08/06/03 15:04

#filterの値は、振り分けを優先するかどうかってことですよね。
編集開始
（っていうか、返信元のメールファイルのある）
フォルダに入れたいので、
#filter=0でテストしようと思います。

RE:00215 TKRetunToFolder.macについて

hajime さん　08/06/03 15:59

未だ一度しか作動させていませんが、

tkinfo.dllのSetFindPack関数でエラーが発生しました。
発生箇所は、先頭から120桁目です。
エラー内容＝閉じカッコが必要です。

というエラーが出て、何回か検索画面が表示されるという
事態が生じました。
いちおう。フォルダ移動は成功しているようです。

RE:00216 HMMRetunToFolder.macについて

山紫水明 さん　08/06/03 20:59

　hajimeさん，

>#filterの値は、振り分けを優先するかどうかってことですよね。
>編集開始（っていうか、返信元のメールファイルのある）
>フォルダに入れたいので、#filter=0でテストしようと思います。

　いや，振り分けが設定してあれば，必ず振り分けが優先されます。これはマク
ロでは制御できません。
　この設定は，振り分けられた場合にその振り分け先のフォルダにフォーカスを
移すかどうかということです。
　もし送信メールはすべて送信元のフォルダに入れたいのであれば，振り分けの
対象を受信メールに限定するように振り分けを設定したらいかがでしょう。

>tkinfo.dllのSetFindPack関数でエラーが発生しました。
>発生箇所は、先頭から120桁目です。
>エラー内容＝閉じカッコが必要です。
>
>というエラーが出て、何回か検索画面が表示されるという
>事態が生じました。

　こちらでは同じマクロのはずですが，エラーは出ません。はて？
これはマクロの最後の部分にある
#n = dllfunc("SetFindPack", ・・・
のところですが，そこはまるカッコがの対が引用符の内外合わせて５個，計10個
あるはずです。何らかの事情で消えているということはありませんか？
この命令文が２つあります。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00217 HMMRetunToFolder.macについて

hajime さん　08/06/04 11:35

>>#filterの値は、振り分けを優先するかどうかってことですよね。
>　この設定は，振り分けられた場合にその振り分け先のフォルダにフォーカスを
>移すかどうかということです。
なるほど。
たまに振り分け先から移動している場合もあますので、
値をデフォルトの1に戻した方が勝手が良さそうですね。

>　もし送信メールはすべて送信元のフォルダに入れたいのであれば，振り分けの
>対象を受信メールに限定するように振り分けを設定したらいかがでしょう。
filter.txtの
「B」って文字列を削除すればいいんですよね。
＃えっと、\tB\nを\nに置換すればいいのかな？

あ、でも、当該フォルダにフォーカスを置かないで
編集（新規編集）を始めてしまった場合は、
移動してもらえなくなるわけですね。
ちょっと保留しておきます。

>>tkinfo.dllのSetFindPack関数でエラーが発生しました。
>>発生箇所は、先頭から120桁目です。
>>エラー内容＝閉じカッコが必要です。
>>
>>というエラーが出て、何回か検索画面が表示されるという
>>事態が生じました。
>
>　こちらでは同じマクロのはずですが，エラーは出ません。はて？
>これはマクロの最後の部分にある
>#n = dllfunc("SetFindPack", ・・・
>のところですが，そこはまるカッコがの対が引用符の内外合わせて５個，計10個
>あるはずです。何らかの事情で消えているということはありませんか？
>この命令文が２つあります。

#n = dllfunc("SetFindPack", "(\"" + $subject + "\", target=subject)
and (\"" + $from + "\", target=from) and (\"" + $to + "\", target=to)and (\"
" + $dt + "\", target=\"Date:\"), subfolder=1, inmail=2" );

ですよね。そのままです。

メーラv5.04
エディタv6.14
です。
あとは、、、？

RE:00219 HMMRetunToFolder.macについて

山紫水明 さん　08/06/04 20:53

　hajimeさん，

> #n = dllfunc("SetFindPack", "(\"" + $subject + "\", target=subject)

>and (\"" + $from + "\", target=from) and (\"" + $to + "\", target=to)and (\
"
>" + $dt + "\", target=\"Date:\"), subfolder=1, inmail=2" );
>
>ですよね。そのままです。

　そうですか。あと２つ同じような箇所があるのですが，そこも問題ないのです
ね。
　ちなみに，意図的にこのカッコの一つを削除してしまうと，こちらでも同じよ
うなエラーが出ます。
　ということで，今のところなぜそちらでエラーが出るのかわかりません。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00221 HMMRetunToFolder.macについて

hajime さん　08/06/16 12:16

コメントありがとうございます。
しばらくTK（フォーラムにアップされている方のファイル）を
使っていましたがちょっとまたHMMのβ版を使ってみます。
#confirm = 0;
#time = 0;
#filter = 1;
で使っています。
先ほどちょっと純粋な条件で動作を検討したところ、
件のエラーは出ませんでした。なんででしょう。謎です。

ところで、
送信時振り分け設定が指定ある場合だけ、
検索作業が開始されるという仕組みなのかな
という感触を得ましたが、この判断は正しいですか？

で、
#filter
という変数は、

編集開始フォルダと、
送信メール振り分け先フォルダが
不一致の場合に、
フォーカスを移すメールをどれにするかを
設定する変数。

ってことでしょうか？

というのは、

編集開始フォルダと、
送信メール振り分け先フォルダが
不一致の場合

というのが私の場合非常にまれなため、
ごくまれな現象のために、

編集開始フォルダと、
送信メール振り分け先フォルダが
一致の場合

でも、検索を開始されると
それで作業がしばらく中断してしまう、
ということが生じます。

そこで、
#filter = 0;
で運用しようかと思っているんですが
上記の私の判断（の根拠）は正しいでしょうか？

また何か気になることがあればご報告いたします。

RE:00221 HMMRetunToFolder.macについて

hajime さん　08/06/16 14:30

元の話題（エラー）に関して。
秀丸エディタで検索オプションが正規表現になっていると
おかしくなるような気がしますが、どうでしょうか？

RE:00230 HMMRetunToFolder.macについて

hajime さん　08/06/16 15:00

違いましたね。
なんででしょう。
やはり不便なのでTKの方にもどすことにします。
条件が特定できずに申し訳ありません。

RE:00229 HMMRetunToFolder.macについて

山紫水明 さん　08/06/16 22:57

　hajimeさん，

>送信時振り分け設定が指定ある場合だけ、
>検索作業が開始されるという仕組みなのかな
>という感触を得ましたが、この判断は正しいですか？

　振り分け設定がなくても，送信したメールを探すための検索をします。ただし，
この場合はフォルダの中だけ検索しますので，時間はほとんどかからないはずで
す。

>で、#filterという変数は、
>
>編集開始フォルダと、送信メール振り分け先フォルダが不一致の場合に、フ
>ォーカスを移すメールをどれにするかを設定する変数。
>
>ってことでしょうか？

この場合は,
#filter = 0; だったらどこにもフォーカスはないという状態になると思います。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00232 HMMRetunToFolder.macについて

hajime さん　08/06/19 13:33

コメントありがとうございます。

ところで、例のエラーですが、
同じメールに返信するときでも
エラーになる場合とならない場合があります。

変動しうる要因というのはなんなんでしょう。
今日はしばらく調子よく使えていたのですが、
午後よりまたエラーがほぼ確実に出るように
なってしまいました。

再現性は１００％じゃないんですけど、
宛先に「"」の引用符がある場合にエラーになる
確率が高いです。

RE:00238 HMMRetunToFolder.macについて

山紫水明 さん　08/06/19 20:37

　hajimeさん，

>再現性は１００％じゃないんですけど、
>宛先に「"」の引用符がある場合にエラーになる
>確率が高いです。

　これは重要なご指摘でした。宛先や題名に引用符があると確実にエラーになる
ことを確認しました。自分では送信メールの宛先には名前部分は落としているの
で，気がつきませんでした。
　この部分を修正してみました。これですべて解決かどうかわかりませんが，と
りあえずベータ版としてアップしておきました。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00239 HMMRetunToFolder.macについて

hajime さん　08/06/24 02:46

早速試しています。
今度は「検索文字列が長すぎます」ってエラーが出ます。
何度も申し訳ありません。

RE:00245 HMMRetunToFolder.macについて

山紫水明 さん　08/06/24 20:59

　hajimeさん，

>今度は「検索文字列が長すぎます」ってエラーが出ます。

　長いヘッダがあったのではないでしょうか。多分，宛先数がかなり多いとか。
　そのための処理を加えて再度アップしておきました。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00246 HMMRetunToFolder.macについて

hajime さん　08/06/30 16:42

しばらくつかってみました
かなり快調です

ところで、受信（ルート？）フォルダにあるメールに
返信する場合、
受信フォルダに移動してくれる場合と、
送信済みに残る場合とがあり、
ちょっとf('_')?、です。

何か確認すべきポイントについて
ご示唆いただけると幸いです。

RE:00251 HMMRetunToFolder.macについて

山紫水明 さん　08/06/30 21:15

　hajimeさん，

>ところで、受信（ルート？）フォルダにあるメールに
>返信する場合、
>受信フォルダに移動してくれる場合と、
>送信済みに残る場合とがあり、
>ちょっとf('_')?、です。

　いったん草稿フォルダや未送信フォルダに保存された場合に，そうなるという
ことはありませんか？
　これはこれで問題ですが。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00252 HMMRetunToFolder.macについて

hajime さん　08/07/28 11:36

久しぶりにエラーが出たのでご報告します

0x200FがSubjectヘッダに使われているメールに返信したら
「閉じカッコが必要です」のエラーがでました
最初原因が分からなかったのですが、
Content-Type: text/plain; charset=utf-8
として送信されたので確かめてみたら、
変なコードのスペースが使われてました。

検索の際に、マッチングできなくなるようです。
これは、秀丸の仕様絡みでしょうか・・・

RE:00254 HMMRetunToFolder.macについて

hajime さん　08/07/29 09:02

>0x200FがSubjectヘッダに使われているメールに返信したら

ちなみに、この文字コード（Unicode)にのみあるコード
は、秀丸エディタの行末（論理行末じゃなくて右端）に
ある時には、0x0030に化けます（ので、0x30になります）
報告した方が良い現象でしょうか？

RE:00255 HMMRetunToFolder.macについて

hajime さん　08/07/29 20:31

>>0x200FがSubjectヘッダに使われているメールに返信したら
どうもこのコードにそもそも文字は割付られていないようですね。
ちなみに、送り主のメーラはHotmailなんですが・・・

RE:00255 HMMRetunToFolder.macについて

山紫水明 さん　08/07/29 20:36

　hajimeさん，

>0x200FがSubjectヘッダに使われているメールに返信したら
>「閉じカッコが必要です」のエラーがでました
>最初原因が分からなかったのですが、
>Content-Type: text/plain; charset=utf-8
>として送信されたので確かめてみたら、
>変なコードのスペースが使われてました。

>ちなみに、この文字コード（Unicode)にのみあるコード
>は、秀丸エディタの行末（論理行末じゃなくて右端）に
>ある時には、0x0030に化けます（ので、0x30になります）
>報告した方が良い現象でしょうか？

　マクロ実行時ではなく，エラーが出るSubjectヘッダを検索語にして通常の検
索をした場合にも同じエラーが出るようでしたら，報告されたらいかがでしょう。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00257 HMMRetunToFolder.macについて

hajime さん　08/07/31 07:40

>　マクロ実行時ではなく，エラーが出るSubjectヘッダを検索語にして通常の検
>索をした場合にも同じエラーが出るようでしたら，報告されたらいかがでしょう。

具体的なご指摘ありがとうございます。
普通に検索したときには
「サポート対象外の言語云々」というエラーが出ます。
対策されていましたね。

マクロでも同様の表示が出た方が望ましい
ということはないでしょうか。
こういう場合のマクロに望まれる動作が
どのようなものであるべきかが私には分からないのですが。
＃つまり、そこまでは求めるべきではないとか。

RE:00258 HMMRetunToFolder.macについて

山紫水明 さん　08/07/31 20:46

　hajimeさん，

>マクロでも同様の表示が出た方が望ましい
>ということはないでしょうか。

　望ましいには違いないのですが。
　こちらで再現できれば，何か考えられるかも知れませんが，今のところ手がか
りがありません。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00259 HMMRetunToFolder.macについて

hajime さん　08/08/04 11:14

試しにHotmailからきたメールを検索してリスト作成して
Subject:の最後にスペースの見えるメールを探し出し、
その文字をコピーして秀丸エディタにペーストして、
コードを確認して、0x200Fだったら、
そのメールを使って動作実験できるかと思います。
今のところ、私のところでは、２人の人からのメールが
上記に該当しました。
レアなケースなので気にすることはないかも知れませんが。

RE:00260 HMMRetunToFolder.macについて

山紫水明 さん　08/08/06 22:06

　hajimeさん，

>試しにHotmailからきたメールを検索してリスト作成して
>Subject:の最後にスペースの見えるメールを探し出し、
>その文字をコピーして秀丸エディタにペーストして、
>コードを確認して、0x200Fだったら、

　最後が空白のメールはたまにあるようですが，いずれもコードは 0x20 で実験
用のサンプルは見つかりませんでした。ご指摘の例はかなりまれなケースのよう
です。
　情報いろいろありがとうございます。この件は差当りは保留しておきたいと思
います。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00252 HMMRetunToFolder.macについて

hajime さん　08/11/21 16:24

久しぶりにおかしなことがあったのでご報告いたします。
送信操作をしたあと、次の閲覧操作のためにフォルダを
異動してしまうと、そのフォルダにメールが異動してしまう、
ということが何度かありました。
PCが不安定なときに生じるようで、動きが緩慢なときに
生じます。マクロが動作終了していないうちにフォルダ
を異動してしまうと、フォルダ情報取得のタイミングが
何か影響するのでしょうか。あるいは、プログラム的には
あり得ない挙動でしょうか？
一応ご報告しておきます。

あと、やはり、一旦「未送信」に入れた場合には、
マクロが効かないのは、仕様上どうにもならないでしょうか。
完全に他力本願なのに要望を出すなんて、心苦しいのですが・・

RE:00291 HMMRetunToFolder.macについて

山紫水明 さん　08/11/21 20:58

　hajimeさん，

　こちらではいずれの症状も起こっていませんので確答は申し上げられませんが，
秀丸メールおよびマクロのバージョンは何でしょう？最新バージョンで起こって
いるのでしょうか？

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00292 HMMRetunToFolder.macについて

hajime さん　08/11/27 08:51

Hmm V5.10
HMMReturnToFolder.mac Ver.1.05β2
です。

最近、メールの振り分けで間違い（誤振り分け）が
頻発するようになりました。

このマクロが振り分けるべきメールが、というより、
自動振り分けの設定（受信時に、みたいな）をして
あるメールが、どこかに行ってしまうことが気になります。

マクロ動作中に私が次のメールの閲覧返信作業に入
るために、別のフォルダにフォーカスを移すこととか、
自動受信（時間毎に受信するようにしてある）が、
このマクロの動作中に始まることととか、
そういうことが同時に生じた場合、
なにか予期せぬことが生じるようです。

要因が複雑で条件を特定できませんが、
自動振り分けの動作とマクロの動作が重なったときが
怪しいような印象があります。
動作のきちんとした仕組みを理解していない上での、
あくまでも、素人的「気分」での怪しみなので、
全く外しているかもしれませんが・・・

RE:00295 HMMRetunToFolder.macについて

山紫水明 さん　08/11/27 22:42

　hajimeさん，

>マクロ動作中に私が次のメールの閲覧返信作業に入るために、別のフォルダに
>フォーカスを移すこととか、自動受信（時間毎に受信するようにしてある）が、
>このマクロの動作中に始まることととか、そういうことが同時に生じた場合、
>なにか予期せぬことが生じるようです。

　マクロ冒頭のオプションで「振り分けされた場合は振り分け先のフォルダににフ
ォーカス移動。」を選んでいると，マクロ終了までにかなり時間がかかる時があ
ります。このオプションを外した場合はどうなるでしょう。

>あと、やはり、一旦「未送信」に入れた場合には、マクロが効かないのは、仕
>様上どうにもならないでしょうか。

　補助マクロの「エディタ起動時に発信フォルダ名をヘッダに追加するマクロ」
を「エディタ起動時」の自動実行マクロ登録する必要がありますが，いかがでし
ょう。
　秀丸メールVer.1.12 でこのマクロの動作に関係するバグがあり，修正しても
らっています。まだ Ver.1.13 の正式版は出ていませんが，ベータ版があります
ので，それで試してください。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00297 HMMRetunToFolder.macについて

hajime さん　08/12/01 01:07

#confirm = 0;
#time = 0;
#filter = 0;
で運用しています。
問題を特定するためになにか変更すべきことはありましょうか？
マクロを改造して動作logをとれれば分かるでしょうか。

RE:00298 HMMRetunToFolder.macについて

hajime さん　08/12/01 02:05

マクロの最新バージョンが1.06であることに気づき
先ほど入れ替えました
「送受信の直前」とは「送受信の開始直前」のことですよね

また秀丸メールも最新β版に入れ替えてみました

さらに、HMMReturnToFolder.mac v.1.03のアーカイブファイルから
HMMSetRootHeader.macをとりだし、
「送信用のエディタ起動時」の自動実行に登録してみました
ドキュメントを読むと未送信フォルダに保存されちゃうと
本体マクロが動作しないような印象があるのですが、
HMMReturnToFolder.mac v.1.06ではその辺が検討されたと理解しています

ということで、最新の環境に変更して様子を見ることにしました

RE:00299 HMMRetunToFolder.macについて

hajime さん　08/12/01 10:23

早速ですが
（もしかしたら古いバージョンからの動作かも知れませんが）
気づいたことがあるのでご報告いたします。

AUTHコマンドで、サーバーがエラーを返した
場合の動作です。
マクロがない場合には、本体フォーラムに投稿した
（01500 「AUTHコマンドで、サーバーがエラー」時の動作について）
のような動作になりますが、
本マクロがあると、「送信済みメールは振り分け設定に従いました。」
と表示されて、メール編集窓が閉じ、本体の検索が始まります。
全部探し終わるまでかなり時間がかかります。
そして先ほどの編集済みのメールを探そうと「送信済み」を開くも
そこには保存されてないのです。
そうです。ターゲットがないので、全部検索していたのです。
設定に依存することなのかも知れませんが、
ご確認いただけると幸いです。

#move = 0
というのは、マクロが動作を失敗した場合となりますか？

RE:00300 HMMRetunToFolder.macについて

山紫水明 さん　08/12/03 21:04

　hajimeさん，

>AUTHコマンドで、サーバーがエラーを返した
>場合の動作です。

　メールが送信されなかった場合の対応は，このマクロでは考えていませんでし
た。その場合はこのマクロを中止する以外にないだろうと思います。
85行目の
closehidemaruforced #handle;
のすぐ後に
if( dllfunc("TransmitError") ) {
message "送信できませんでしたのでマクロを終了します。";
endmacro;
}
を追加してみて様子を見てください。本体の出すメッセージとの関係でこのメッ
セージが不要であれば，message の行は削除してください。

>#move = 0
>というのは、マクロが動作を失敗した場合となりますか？
　そうですが，振り分けによって送信済みフォルダに当該メールなくなっている場
合を想定しています。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00301 HMMRetunToFolder.macについて

hajime さん　08/12/03 22:27

ありがとうございます。
じつは、マクロを1.06にバージョンアップしてから、
何度か書き終えた内容を消失して消沈していたところです
これで問題解決になると嬉しいです

ところで、全く別の観点になりますが、
もし可能でしたら、ですが、今後の改訂の視点として、
「RootHeaderを、未送信に保存する時以外にも活用する」
というのをご検討いただけると幸いです。

補助マクロを入れてから思うことしばしばなのですが、
ヘッダに情報が明示的に見えるので（見えるようになったおかげで）、
新規編集開始時に「あ、しまった、ここじゃない」と
と思うことがある（保存すべきじゃないフォルダに
フォーマスがあったことに気付いたという場面です）。
で、その時にヘッダを編集して
「受信」などに書き換えてしまってきちんと動作するように、
対応できないか、というものです。
現在のマクロですと、条件分岐が未だ分かっていないのですが、
ヘッダを書き換えても、動作に反映はされないようです。
しかし、せっかくヘッダがあるので、ヘッダの有無で
動作条件分岐して、ヘッダがある場合にはその情報に従うようには
出来ないものかなぁと思った次第です。
＃存在しないヘッダを書いちゃった場合にどこに飛ぶかとか、
　今思いつくだけでも考慮しないといけない事項はありそうですが、
　もし可能でしたら、ご検討いただけると幸いです。
いつもリクエストばかりで、申し訳ありません。

RE:00301 HMMRetunToFolder.macについて

hajime さん　08/12/03 22:35

これではマクロをカットできないようです。
LANケーブルを抜いて実験すると再現できると思うんですが、
如何でしょう
>85行目の
>closehidemaruforced #handle;
>のすぐ後に
>if( dllfunc("TransmitError") ) {
> message "送信できませんでしたのでマクロを終了します。";
> endmacro;
>}

RE:00299 HMMRetunToFolder.macについて

hajime さん　08/12/03 23:23

誤振り分け　再現しました
秀丸メール本体がv.5.10
マクロ　v.1.06
補助マクロ使用

一応　今回のパタンを記します

１）正しく「マクロで」振り分けられる（メールA）
↓
２）正しく「振り分け設定で」ゴミ箱に移動（メールB)
３）２）の動作と同時に、なぜか、メールAが、
　　メールBの編集開始フォルダに移動してしまう（誤振り分け）

マクロを追っても、どうしてこんな動作になるのか、
私には皆目理解できません。

なお、２）の設定は、MLについて、送信メールは
ゴミ箱に移動し、MLで配信されてきたメールのみ
残すように設定してあるものです。
メールAが、メールBの編集開始フォルダ（メールBの
MLで配信されてきたメールB'が振り分けられるフォルダ）
に移動してしまったのです。

ゴミ箱とか草稿など、Rootフォルダ情報を取得できないフォルダが
絡んで居るんでしょうか・・・

RE:00299 HMMRetunToFolder.macについて

hajime さん　08/12/04 01:19

マクロの最新バージョン1.06について
もう一つ気になることがあるのでご報告申し上げます。

送信動作中に
＃私の環境では、送信が終わるまで相当時間がかかります
時間がもったいないので、別のメールを閲覧しようと、
フォルダを移動しようとすると、
「マクロを中断するか？」というエラーメッセージが出ます。
そのメッセージ枠には「OK」という選択肢しかなく、
ここで、「×」をクリックして中断しないという意志を
表明してみると、猛烈にたくさんのエラー表示に見舞われます。

また、しばらく様子を見てみます

RE:00303 HMMRetunToFolder.macについて

山紫水明 さん　08/12/04 22:30

　hajimeさん，

>これではマクロをカットできないようです。
>LANケーブルを抜いて実験すると再現できると思うんですが、
>如何でしょう

　これについては，別の会議室で"TransmitError"関数の仕様変更をお願いし
ているところなので，それを待って試みてください。

>「受信」などに書き換えてしまってきちんと動作するように、
>対応できないか、というものです。
>現在のマクロですと、条件分岐が未だ分かっていないのですが、
>ヘッダを書き換えても、動作に反映はされないようです。

　このヘッダはあくまでもマクロの補助的なもので，もしご希望通りにすれば
「送信元のフォルダに保存する」という本来の目的から外れてしまいそうです。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00306 HMMRetunToFolder.macについて

hajime さん　08/12/07 10:06

山紫水明さま
>　これについては，別の会議室で"TransmitError"関数の仕様変更をお願いし
>ているところなので，それを待って試みてください。
ご対応ありがとうございました。
本体β13にUPしたところ、
dllfunc("TransmitError")が0ではない値を返すようになり、
適切にマクロをカットできるようにはなったようです。
ところが残念なことに送信失敗した編集内容は保持できません。
山紫水明さまの環境では、LAN接続していない場合（サーバで
エラーが返されて送信失敗した場合のシミュレーション）、
どのような動作になるでしょうか。
closehidemaruforcedがきになっていますが。。

RE:00307 HMMRetunToFolder.macについて

山紫水明 さん　08/12/07 16:44

　hajimeさん，

　秀丸メールの新バージョンに対応した新しいバージョンをアップしていますの
で，そちらをお試しください。

　それから，前回のコメントの追記になりますが，ヘッダを書きかえた場合でも
草稿フォルダか未送信フォルダにいったん保存されれば，新しい保存先が生きて
くるはずです。書きかえたフォルダが存在しない場合の動作まではサポートでき
ませんが。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00308 HMMRetunToFolder.macについて

hajime さん　08/12/08 13:04

HMMReturnToFolder.mac Ver.1.07 に入れ替えました
何度もありがとうございます。
送信エラーへの対応は期待通りの動作をすることを確かめました

ところで、
以下の動作は、予定通りの動作と思われますか？
それとも環境依存での違いが出ているのでしょうか。

・メールエディタ画面から直接今すぐ送信して送信エラーになった場合
　HMMSetRootHeader.macで付したヘッダが消去されたうえで
　エディタ画面に操作が引き渡される

→できれば、X-RootFolder:を残して
　すなわち、編集終了時と同じ状態に
　返して欲しいところですが
　エラー処理のところを
　if( dllfunc("TransmitError") ) {
if( #time ) #n = dllfunc( "SetAutoPushTimerMilli", #time);
message "送信できませんでした。";
$s = dllfuncstr( "SetHeader", "X-RootFolder", $rootfolder );
exit;
　 }
　とすると、ヘッダを戻せるでしょうか？（まだ実験していません）

・あとで送信等で一端未送信フォルダに入った場合で
　メールエディタで開いて今すぐ送信した場合
　　編集を許可していないエディタ画面でAddHeaderかSetHeader関数が
　　呼び出されました
　というエラーが出ます

→こちらの設定依存の現象でしょうか？
　なお、一端草稿フォルダに保存（あるいは移動）したものを
　メールエディタで開いて送る場合は、上記のエラーは出ないです。
　あれ？もしやこれは
　私が未送信メールの編集をデフォルトで許可してないから
　生じるエラーでしょうか（なら試せば良いんですね）
　→その通りでした。この件は自己解決。
　　本件マクロの解説に記載されると良いかもしれませんね。
　　私のような「ユーザ」ですと、これに気づくのに一晩かかります。
　　（なさけなや）

・あとで送信等で一端未送信フォルダに入った場合で
　送信コマンドで未送信フォルダから直接送信する場合、
　あるいは秀丸メール終了時に「残っている、送るか？」という
　警告に対してyesした場合、
　HMMSetRootHeader.macで付したヘッダは発効せず
　送信済みフォルダに保存される（ヘッダが残る）

→こちらの設定依存の現象でしょうか？
　あるいは、この動作については、
　このマクロの対応範囲外でしょうか。

RE:00309 HMMRetunToFolder.macについて

山紫水明 さん　08/12/09 18:48

　hajimeさん，

>　エラー処理のところを
>　if( dllfunc("TransmitError") ) {
> if( #time ) #n = dllfunc( "SetAutoPushTimerMilli", #time);
> message "送信できませんでした。";
> $s = dllfuncstr( "SetHeader", "X-RootFolder", $rootfolder );
> exit;
>　 }
>　とすると、ヘッダを戻せるでしょうか？（まだ実験していません）

　それでいいはずです。

>　私が未送信メールの編集をデフォルトで許可してないから
>　生じるエラーでしょうか（なら試せば良いんですね）

　未送信メールについて「編集不許可」という設定ができましたか。気がつきま
せんでした。どこで設定されていたのでしょう？

>・あとで送信等で一端未送信フォルダに入った場合で
>　送信コマンドで未送信フォルダから直接送信する場合、
>　あるいは秀丸メール終了時に「残っている、送るか？」という
>　警告に対してyesした場合、
>　HMMSetRootHeader.macで付したヘッダは発効せず
>　送信済みフォルダに保存される（ヘッダが残る）
>
>→こちらの設定依存の現象でしょうか？

　未送信フォルダに入れた場合は，これが通常の操作だと思いますが，こちらで
は再現しませんので，設定が関係するのかも知れませんが，今のところよくわか
りません。

　では，　(^^)/~
山紫水明
SANSHISUIMEI

RE:00310 HMMRetunToFolder.macについて

hajime さん　08/12/11 05:30

>　未送信メールについて「編集不許可」という設定ができましたか。気がつきま
>せんでした。どこで設定されていたのでしょう？

設定→メール表示→詳細(その他)　の　一番先頭のメニューです。

>>・あとで送信等で一端未送信フォルダに入った場合で
>>　送信コマンドで未送信フォルダから直接送信する場合、
>>　あるいは秀丸メール終了時に「残っている、送るか？」という
>>　警告に対してyesした場合、
>>　HMMSetRootHeader.macで付したヘッダは発効せず
>>　送信済みフォルダに保存される（ヘッダが残る）
>>
>>→こちらの設定依存の現象でしょうか？
>
>　未送信フォルダに入れた場合は，これが通常の操作だと思いますが，こちらで
>は再現しませんので，設定が関係するのかも知れませんが，今のところよくわか
>りません。

再現しないと云うことは、ちゃんと振り分けされると云うことですよね。
羨ましいです。

ところで、

キャラクタチェック警告の際「このまま送るか」といわれて、
当該文字列に移動して確認しようと思い「いいえ」と回答すると、
秀丸メールで用意されたその動作からマクロが操作を奪い、
送信エラーの時と同じように、「保存するかどうか」を
問い合わせる状態に飛びます（たぶん仕様）。
できれば、キャラクタチェックをしたいので、工夫可能でしたら
よろしくご検討ください。

で、また、障害報告です。
PCに負荷がかかっているときになりやすいようですが、
上記の動作で、マクロが操作を奪うタイミングが遅れると？
あるいは早すぎると？
編集したメールが消失します。2度ほど経験しました。
「振り分けに従いました」と表示して、跡形もなく消えます。

RE:00311 HMMRetunToFolder.macについて

hajime さん　08/12/11 06:46

障害報告（その後）
キャラクタチェック警告の際「このまま送るか」といわれて、
当該文字列に移動して確認しようと思い「いいえ」と回答すると、
「振り分けに従いました」と表示して、編集した文書が消える、
という事態から抜け出せなくなりました。
キャラクタチェックをするためには、
マクロ登録を外さないとなりません。

Pen4 1.9G　640M　XP　です。動作が緩慢なので、
その辺の環境要因によるかもしれません。

RE:00312 HMMRetunToFolder.macについて

hajime さん　08/12/12 15:09

障害報告（追加情報）
エディタ画面で、送信操作直後、中断操作をしても、
同様に、
「振り分けに従いました」と表示して、編集した文書が消える、
という動作になります。
エディタを強制的に閉じるのが難しいんですね。

なお、CPUやWindowsに依存せず出るようです。
Core2Solo+Vista でも出ます。