▼ げんたさん
> > 最終的にはCSMacroMgrとあわせて
> 統一する案には賛成です。

どもども～。
確かにCEditDocに入れるのは気持ち悪いといえば気持ち悪いですね。
でもまぁそのあたりの整理はまた後ほどやるとして。。。

こういうのはどうでしょう？（ってもう実装してたりするけど）

キーマクロは、デフォルトでマクロ保存用フォルダにRecKey.macというファイルを作るようにします。
DLLSHARE（共通メモリ）に、そのファイル名（今のところRecKey.macに固定）を入れるようにします。

で、キーマクロを実行するときは、DLLSHAREにかかれているファイル（RecKey.mac）を読み込んで実行する。
そうすれば、共通メモリに入れておくのはCKeyMacroMgrではなくて、ファイル名だけになってグー。

こうしておけば、「記録したキーマクロが、そのウィンドウでしか使えない」という制限はなくなるし、
CKeyMacroMgrにどんとかまえたメモリ領域（下記）

#define MAX_STRLEN 70
#define MAX_KEYMACRONUM 10000
KeyMacroData m_pKeyMacroDataArr[MAX_KEYMACRONUM];
char m_szKeyMacroDataArr[MAX_KEYMACRONUM][
MAX_STRLEN];

を、リストにして、メモリの節約もできるという具合。
今のところうまく動いているみたいです。

今日はこの辺にして、また後日CSMacroMgrと混ぜ合わせに挑戦してみます。では。

▼やざきさん
>・CSMacroMgr
>・CKeyMacroMgr
>・CMacro
>ようにしました。
検討すべきクラスを1つ忘れていますよ．
CSMacroMgr::Macro1 というマクロを「1つ」管理する(貧弱な)クラスがあります．(structだけど一応クラスね)

これはCMacroに統合した方がいいかも．

>保存をCMacroでやるか、CKeyMacroMgrでやるか、
>それに読込をCMacroでやるか、CKeyMacroMgrでやるかが
1マクロに関することはCMacroだけど，ファイル処理までやらせるのは荷が重い...ってことですよね．

ファイルのopen/close処理はCKeyMacroManagerで行い，実際の文字列化はCMacroで行うのはどうですか．

ofstream fp( "macro.mac" );
fp << macros[n];

if( !fp ){
error handling
}
--
ifstream fp( "macro.mac" );
macros[n].clear();
fp >> macros[n]

if( !macros[n].ready() ){
error handling
}
--
ostream& operator<<( ostream&, CMacro& );
istream& operator>>( istream&, CMacro& );

って感じで．わかってもらえました？

▼ horさん
> ▼ やざきさん
> > マクロをいじっています。
>
> ご苦労様です。
>
> マクロで扱える引数を CEditView::HandleCommand にあわせて最大４っつにしていただけると
> 置換や、外部コマンド実行のオプションを扱えるように変更するのも難しくないかな、と思うのですが
> …いかがでしょう？

をを、グッドアイディアですね。
いま内部でも引数ひとつしか扱えないので、できる限り扱えるようにしてみます。