| |
無いよりはあった方がよいのではないか、といった程度ではあるのですが、
「ある」ことにより、秀丸マクロの文字コードが
「マルチバイト」→「Unicode」へと現在よりはスムーズに
移行していけるのではないか、と思っています。
■cp932とcp1200(unicode)
秀丸マクロは、まさにWindowsが抱える「マルチバイトとUnicode」( 以後 「Aと
W」と略す)に２分している問題をそのまま抱えています。
Windows自体は「AとW」、2000年頃には仕様をそれなりに安定させていましたが、
秀丸がマクロ上でUnicodeをなんとか扱えるようになったのは、秀丸エディタ v8以
降からと言ってよく
「秀丸マクロをutf16で保存する」といった風習は、現在はまだあまり浸透してい
ないように思います。
しかし、マルチバイトの行き詰まりが年々大きくなっていることは確かですので、
やがては、秀丸マクロはutf16、といった方向へと傾いていくのでしょう。
■秀丸マクロ用のdllの「AとW」兼用の姿
秀丸マクロでは、dllfuncとdllfuncw、及び、dllfuncstrとdllfuncstrwが存在する
ため、
呼び出し時点ですでに、マルチバイトなのか、Unicodeなのかの振り分けは完了し
ています。
よって、秀丸マクロ上では「パラメータ」に過ぎないdllの関数名を振り分ける必
要はないのです。
★dll製作者がexportの関数名レベルで振り分けしてしまっている例。
__declspec(dllexport) wchar_t * somefuncW( wchar_t *arg) {
wchar_t *a = (wchar_t *)arg;
something;
return p_utf16str;
}
__declspec(dllexport) char * somefuncA( char *arg) {
char *a = (char *)arg;
something;
return p_multibytestr;
}
★dll製作者がexportの関数は同じとする例
__declspec(dllexport) void * somefunc( void *arg ) {
if (macro_codepage == 1200) { // マクロはutf16(cp1200)
wchar_t *a = (wchar_t *)arg;
something;
return p_utf16str;
} else { // マクロはcp932
char *a = (char *)arg;
something;
return p_multibytestr;
}
}
■マクロのコードページの伝達
現在は、特別な仕掛けが存在しないため、上記サンプルでいう「macro_codepag
e」はマクロから伝える必要があります。
dll製作者は、以下のMacroCodePageような関数を制作して、loaddll直後あたり
で、コードページをマニュアルで伝達することでしょう。
dllfunc( #dll, "MacroCodePage", 1200 ); // マクロのコードページをdllへと
伝達することで、dllは(振り分けの必要がある)関数は全て、1200の方が利用される。
dllfunc( #dll, "MacroCodePage", 932 ); // マクロのコードページをdllへ
と伝達することで、dllは(振り分けの必要がある)関数は全て、932の方が利用される。
__declspec(dllexport) int MacroCodePage(int cp) {
macro_codepage = cp;
}
■今回の提案
今回の提案は、この「マクロ自体のコードページの伝達」を
①loaddll直後に秀丸がdllへと伝達する
②マクロ内でdllが秀丸へと問い合わせる
のどちらかを可能としてはどうか、といった提案となります。
(上記でいう、dllfunc( #dll, "MacroCodePage", 1200 ); といったマクロレベ
ルの伝達を記述しなくても、dll内部で済ませられるようにしてはどうかということ
です)
(秀丸マクロ自体もおそらくHIDEMACの「SetCodePage」あたりで同様のことをしてい
るのではないかな？ と推察します。)
|
|