V8.75β2No.09517
秀丸担当 さん　17/08/03 17:15
　

V8.75β2を公開しました。

以下のページの「先行開発バージョンはこちら」からダウンロードできます。
http://hide.maruo.co.jp/software/hidemaru.html

32bit版：
http://hide.maruo.co.jp/software/bin3/hm875b2_signed.exe

64bit版：
http://hide.maruo.co.jp/software/bin3/hm875b2_x64_signed.exe
[ △ ]
RE:09517 V8.75β2No.09518
vscode-life さん　17/08/04 14:40
　

β２試しました。
骨格としては動作しているようです。
ありがとうございます。

これはめちゃくちゃに応用範囲が広がったと思います。
(というか、出来ないことの95％ぐらいが一撃で消えたぐらいの感触ですｗ）

ただ、私が試した範囲では、wszReturn に有意な値が返ってくることはなく、
関数実行後も、元の値(キャパシティサイズ)がそのまま残っているので、
β２では、エラーがあったとしても特にこのバッファーに結果を格納していないのか
な？ と思いました。


とりあえず、wszReturn の動作を除くと、
ネイティブ／マネージドともに動作しています。
(試験的に、昨夜ローカルで
　・ネイティブな hmJavaVM,
  ・マネージドになる hm.NET に組み入れてみましたが、
 動作しています。)
[ △ ]
RE:09518 V8.75β2No.09519
秀丸担当 さん　17/08/04 15:41
　

早速のご確認ありがとうございます。
wszReturnが働いていないかもしれないとのことで、調べてみたのですが、こち
らで試してみている限りでは動作しているようでした。

１つ言えそうなこととしては、メッセージを受け取ったら、マクロ実行前にすぐ
*(WCHAR*)wParam = '\0';としているので、もし何らかの失敗があるとしても空
の文字列になるはずだと思います。
バッファサイズがそのまま残っているとしたら、呼び元がPostMessageか
SendMessageTimeoutなどですぐ抜けて、wszReturnを参照すると、バッファサイ
ズがそのまま残っていることになると思いますが、どうでしょうか。
[ △ ]
RE:09518 V8.75β2No.09520
vscode-life さん　17/08/04 16:13
　
http://www.maruo.co.jp/turukame/3/x09485_.html#9485
の「③」でも記載したことなのですが、

やはり virtual_file_fullpath 的なものを指定出来た方が
断然良いと思います。



引数が余っていないので、
#define buf 512
struct SEND {
    WORD cbBufSize;
    wchar_t wszPseudoFullPath[buf];
};
struct RECIEVE {
    wchar_t wszRecievedBuf[buf+1];
}


SEND send;
send.cbBufSize = sizeof(SEND)/sizeof(wchar_t);
wstrcpy(&send, L"仮想的なファイルフルパス");
 
SendMessage(...)

RECIEVE *r = (RECIEVE *)&send;
・・・・

みたいな、ソースになりそうですが…


仮想的なファイルフルパス はほとんどのパターンにおいては、
dll自身を呼び出した.macと同じcurrentmacrodirectoryとなるような、仮想的なファ
イルのフルパスを指定する…筈。
(状況が安定するので)


というのも、
「マクロが実行中」なのにもかかわらず
「どこで、どういうファイルで実行してる（つもり）」という情報が
「欠ける」タイミングがあると、

.macの起点情報を拾えない「瞬間」があるので、
dllは苦労する筈です。

また、他のマクロ(大本の呼び出し元マクロ含む)の実行をするような
下記のようなマクロ記述

execmacro "****.mac"

で一見回避できそうですが
「該当行execmacro そのもの」の瞬間、
「マクロが実行されている」のに「マクロ起点情報はない」
みたいになるので、レアバグを生みそうです。
[ △ ]
RE:09519 V8.75β2No.09521
vscode-life さん　17/08/04 16:16
　
了解しました。

(ヘルプにある最小限のネイティブのソース例まる貼り付けでも試したつもりだった
のですが…)

落ち着いて帰宅したら、また見てみます。
[ △ ]
RE:09520 V8.75β2No.09522
vscode-life さん　17/08/04 16:47
　
「WM_REMOTE_EXECMACRO_MEMORY」に仮想ファイルを付けると、
　秀丸のマクロ関連実装ソースがスパゲッティになりそうだ、
　ということであれば、

別の解決方法としましては、
「WM_REMOTE_EXECMACRO_MEMORY」は
マクロ情報は無いもの、として割り切り、

「WM_REMOTE_EXECMACRO_FILE」の方で、execmacro相当の引数のように、
文字列で複数の引数を渡せるようにしてしまうのも
手だと思います。


　
[ △ ]
RE:09522 V8.75β2No.09523
秀丸担当 さん　17/08/04 17:27
　

WM_REMOTE_EXECMACRO_MEMORYの場合、自身のマクロファイル名に相当するものは
確かに無いです。
あったらいい場面もあると思いますが、currentmacrodirectoryを必要とするよ
うなマクロは実際のファイルが存在するようなケースだと思うので、
WM_REMOTE_EXECMACRO_FILEでいいという気がします。

また、WM_REMOTE_EXECMACRO_MEMORYのメモリ上のマクロは呼び元で自由に生成で
きるので、引数のように渡したい情報はマクロそのものに動的に記述することも
一応できると思います。
WM_REMOTE_EXECMACRO_FILEで引数を必要とするとしたら、また仕様を考える必要
があると思います。別の手段としては、WM_REMOTE_EXECMACRO_MEMORYで引数相当
のマクロを生成してからexecmacroでも不可能ではないとは思います。
[ △ ]
RE:09519 V8.75β2No.09524
vscode-life さん　17/08/04 18:47
　
あ、ちょっと勘違いしていました。

endmacroの引数のような値を拾うことが出来るのですね。
(確かに上の方の投稿で秀丸担当さんが投稿してました…
 マニュアルにもそう記載がありました)

お騒がせしました。
[ △ ]
RE:09524 V8.75β2No.09525
vscode-life さん　17/08/07 13:00
　
こちら、
・C系ネイティブ
・C++CLI系マネージド
・C#
・JavaVM経由

すべて基本的な動作は確認できました。

結構使いやすくラップ出来るので
問題ないと思います。
(細かなバグや問題点は、今後いろいろ作っていく中でないと
 なかなか発見が難しそうですが）

ほとんどの人は今回のexec系のReturnとしては
(┌メタな記述)
interface Macro.IReturn {
    get property int Return; // 返り値 (1が実行開始までいった、0が実行開始ま
でいかなかった)
    get property string message; // endmacro のメッセージ
    get property Exception exception; // 指定したファイルが無いや、EvalError
など、Retrun 0時の補足
}
的な感じに作っていくだろうと思います。


ファイルベースでもメモリベースでも、
「endmacroの後の引数文字列が返ってくる仕様」が、
達成状況把握に役立ち秀逸だったと思います。


いやー、これは本当に、これはマジで凄い。
この機能達成は本当に嬉しい!!
[ △ ]
RE:09525 V8.75β2No.09526
秀丸担当 さん　17/08/07 15:38
　

いろいろ試していただいてありがとうございます。
endmacroで返す文字列もできていそうということで、安心しました。
[ △ ]