[ 新規に投稿する ]
V9.19β10No.11025
秀丸担当 さん　22/09/14 16:11　[ コメントを投稿する ]
　 V9.19β10を公開しました。
V9.19はあまり追加せずいったん落ち着かせる方向にしたいと思っているのですが、また追加や変更をしてしまっています。

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

32bit版：
https://hide.maruo.co.jp/software/bin3/hm919b10_signed.exe

64bit版：
https://hide.maruo.co.jp/software/bin3/hm919b10_x64_signed.exe
[ △ ]
RE:11025 searchoptionの fEnableSearchOption2No.11026
こみやんま さん　22/09/15 16:36　[ コメントを投稿する ]
　 searchoptionの fEnableSearchOption2の
#fEnableSearchOption2 = 0x80000000 は intに収まってない

ヘルプにある 0x80000000 はintに収まっていません。

秀丸マクロの場合、ビットをそのまま対象のマクロのintptr_tのビット並びで解釈するので、問題はないですが(それでもint32_tを超えた値を指定しているので、例としては若干不適切には見えてしまいますが、64bitでも同じ0x80000000でしょうから仕方がないのかも？)

jsでは、スリ潰れているのではないかと思います。


#a = 0x80000000;
message(str(#a));

js {
var test = "あいうえお\r\n";
setVar("#b", 0x80000000); // これが(setVar(...)の段階で擦り潰れるのであれば、#fEnableSearchOption2 = 0x80000000 との論理和などを渡すhidemaruGlobal内のいくつかの関数はそのオプションを機能させうるとは思い難い...
var c = getVar("#b");
message(c);

}

message(str(#b)); // 0になってる... この伝達状態ではjsからはおそらく機能していないのでは...?
[ △ ]
RE:11026 searchoptionの fEnableSearchOption2No.11027
秀丸担当 さん　22/09/15 18:06　[ コメントを投稿する ]
　 確かに32bitの最上位ビットだけの場合、setVarはマイナスかプラスかによってうまくいかないことになってしまいました。
setVarはどのエディションでも差異無く32bit(符号付き)ということになっているので、最上位ビットだけを渡す必要がある場合は、何らかの別の方法にするしかないと思います。

js上で明示的に0x80000000だけを指定したいという場合は問題なさそうでした。
setsearch("test",0x80000000);

明示的に0x80000000指定ではなく、何が入っているかわからないけど、とにかくsearchoptionを変数でsetVarで渡したいという場合は、0x80000000にはならない（必ず0x3800がある）ので、よほどのことがなければ問題になることは無いと思います。
[ △ ]
RE:11027 searchoptionの fEnableSearchOption2No.11028
秀丸担当 さん　22/09/15 18:24　[ コメントを投稿する ]
　 >searchoptionを変数でsetVarで渡したいという場合は、0x80000000にはならない（必
>ず0x3800がある）ので、よほどのことがなければ問題になることは無いと思います。

と思ったのですが、マイナスと扱われるかどうかだけでよくて、0x3800はあってもなくても同じでした。
なので、どっちにしてもsearchoptionをsetVarを渡すことはできるようでした。
[ △ ]
RE:11028 searchoptionの fEnableSearchOption2No.11029
こみやんま さん　22/09/15 18:30　[ コメントを投稿する ]
　 渡す時には、javascriptの「数値」を「数字」にして、そのままevalしているので、セーフ(ビットの並びはjsではなく秀丸マクロが処理するから)で、
一方、マクロからjsに返ってくる際は、
すでに秀丸によって32ビットに収まる値(0x80000000なら-0x80000000)になって渡ってくるからよく考えればセーフなんですかね？

(32bit同士は大丈夫だけど、秀丸エディタ64bit⇒jsは返りし大丈夫なんだろうか...)

(うーむ、ぎりぎりの実装な気配ですが、現状たしかにセーフっぽいです）
[ △ ]
RE:11029 searchoptionの fEnableSearchOption2No.11030
こみやんま さん　22/09/15 19:59　[ コメントを投稿する ]
　 秀丸マクロの方ですが、
64bit版の方は、ビット自体は足りていますが、
32bit版と互換にするため、
searchoption 相当の引数を受け取るものは、
-0x80000000 相当のビット部分の符号を反転させて 0x80000000 にしているように思えます。

setsearch "abc", -0x80000000, 0x00000001;
// setsearch "abc", 0x80000000, 0x00000001; と同一になってると思われる。

if (searchoption > 0) {
    message("反転する");
}

ということは、(他がプラス値の)OR演算しかしないため、(どんどん数値が大きくなる一方なので)
var fEnableSearchOption2 = -0x80000000

にしておけば、32bitでも64bitでも、値を別空間へと橋渡ししていくさいでも大丈夫なのかなーと思いました
[ △ ]
RE:11030 searchoptionの fEnableSearchOption2No.11031
秀丸担当 さん　22/09/16 10:08　[ コメントを投稿する ]
　 JavaScript上の数値の-0x80000000は、setVarできる最小値と同じになって、そこから | 0x123とかしても通用するようでした。
-0x80000123はできないので、ちょっと混乱しそうではありますが、１つの解決策にはなると思います。

いろいろ回避策を考えるより、0x40000000のビットが最後に空いているので、もし問題があったらこれを使ってしまった方がいいような気もしてきました。
今後何か増やすような場合、最上位ビットを使うのはなるべく避けるようにしようと思います。
[ △ ]
RE:11025 hidemaru.getInputStates()は...No.11032
こみやんま さん　22/09/16 23:45　[ コメントを投稿する ]
　 hidemaru.exeのネイティブ用の関数としても用意したほうがいいかなぁと思います。

Hidemaru_GetInputStates()

こういった役割の関数を一番上手く利用できるのは、非同期の
スレッドから状況を監視して、何かを満たしていたら、
それに応じたアクションをすることでしょうし。
[ △ ]
RE:11025 V9.19β10No.11033
こみやんま さん　22/09/17 02:17　[ コメントを投稿する ]
　 refreshtabstop_pause を JSの関数へと移植しやすれているのではないかと思います。
()
[ △ ]
RE:11033 V9.19β10No.11034
こみやんま さん　22/09/17 02:22　[ コメントを投稿する ]
　 enablebreak 文をJSへと移植しやすれているのではないかと思います。
[ △ ]
RE:11034 V9.19β10No.11035
秀丸担当 さん　22/09/20 13:08　[ コメントを投稿する ]
　 Hidemaru_GetInputStatesもあったほうがよさそうです。
追加しておこうと思います。
不足の点のご指摘もありがとうございます。
修正しておきます。
[ △ ]
[ 新規に投稿する ]