V9.15β1No.10739
秀丸担当 さん 22/03/31 16:03
 
V9.15β1を公開しました。

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

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

64bit版:
https://hide.maruo.co.jp/software/bin3/hm915b1_x64_signed.exe

[ ]
RE:10739 V9.15β1No.10740
グズラ さん 22/03/31 17:09
 
グズラです。

https://www.maruo.co.jp/hidesoft/2/x39632_.html#39632
> 39632 【すべて再度色付け】で色の付け方がスキップされる?
が直っているかを確認したところ、たしかに
> いったんリセットしてから数え直すよう
にはなっていますが、見出しバーに表示されている色付け情報を消去して「再度色付
け」すると、次に色付けした検索文字列が最後に採用された色で色付けされてしまい
ます。

以下の手順で再現できるかと思います。

1.動作環境-検索-検索の色付けで、色の付け方を「固定の色を順番に使用」として
おき、「色の設定」を例えば


黄色

としておく。
2.検索で「すべて検索-色付け」を3回やる。(赤、青、黄色で色付けされている)
3.見出しバーに表示されている色付け情報から、赤の検索文字列を消去する。
4.「再度色付け」を実行する。
5.検索で「すべて検索-色付け」をやると、黄色で色付けされる。
異なる検索文字列(しかも直前に検索した文字列)が同じ色で色付けされるのは好ま
しくないので、できれば緑で色付けされて欲しいです。
実現するのが難しいのであれば元の仕様に戻して頂いても構いません。
(異なる検索文字列は可能な限り異なる色で色付けされて欲しいので)
※消去する検索文字列を増やして試したところ、色付けのカウンタの制御が難しそう
だなと感じました。

[ ]
RE:10740 V9.15β1No.10741
秀丸担当 さん 22/03/31 17:33
 
早速のご確認ありがとうございます。
確かに消したものがあるとそうなってしまうと思います。
以前の動作だとしても、既存の個数や再度色付け実行回数によっては被るタイミング
はあると思います。
16個未満であれば、被っていないところを探して次へ進むようにしてみます。

[ ]
RE:10739 V9.15β1 フィードバックNo.10742
ohtorii さん 22/04/03 15:26
 
お疲れ様です

動作することを確認しました!

>getresultex(25)を追加して起動数の上限のエラーが発生したかどうかを取得可能に
>修正。

ご対応頂きありがとうございます!


■ヘルプの文言について(ご提案)
getresultex(25)の返値はresult値と真偽が逆なので一瞬迷いました。

以下のように具体的な値が書いてあると助かります

(新)25:newfile等で新しく秀丸エディタが起動するとき、起動数の上限によってエ
ラーになったかどうか (1=失敗/0=成功) (V9.15以降)

よろしくお願いいたします。

[ ]
RE:10742 V9.15β1 フィードバックNo.10743
秀丸担当 さん 22/04/04 09:13
 
ご確認ありがとうございます。
getresultexで、どちらの値のときに失敗かは確かにわかりづらかったです。
25以外の他の番号でも、失敗を判断するところは値としてわかるように書いておきま
す。

[ ]
RE:10739 V9.15β1No.10744
Y_H さん 22/04/04 12:49
 
> バックタグジャンプのアクティブ切り替えの仕方をタグジャンプと同じに合わせる
>(アクティブが消失する問題対策)

こちらの対応ありがとうございます。
8.99.4から9.15β1に更新させていただきましたが、以下のような状態になります。

1回目のバックタグジャンプでは正しく戻るようになりました。
ただ、再度タグジャンプを行うと、それ以降のバックタグジャンプでは、
タスクバーが点滅するようになってしまいました。

フォーカスはタグジャンプした先のままで、カーソルは両方に表示されています。
また、2回目以降は常にこの状態になるようです。

1回目と2回目以降で動作が異なるというところは同じようです。
なにか設定の組み合わせなどによるものなのでしょうか。

よろしくお願いいたします。

[ ]
RE:10744 V9.15β1No.10745
秀丸担当 さん 22/04/04 15:18
 
詳しい情報ありがとうございます。
あまり変化が無いということで、すみません。
再現しないということと、起きるか起きないかは明確な線引きがなさそうなこともあ
り、いただいた情報を元にまた調整してみます。

[ ]
RE:10745 V9.15β1No.10746
Y_H さん 22/04/04 15:31
 
>再現しないということと、起きるか起きないかは明確な線引きがなさそうなことも
>あり、いただいた情報を元にまた調整してみます。

何度も調査していただき申し訳ありません。
なにか原因がわかれば、対応していただけたらと思います。

ちなみに、grep結果だけでなく、ソースファイル内の#includeからもタグジャンプが
できますが、
ソースファイルとヘッダーファイルを同じウィンドウ内で開き、片方を別ウィンドウ
に分離してから、
#includeのところでタグジャンプとバックタグジャンプを繰り返す分には、問題なく
移動できます。
しかし、初めから別ウィンドウで開いていると、今回の動作が発生するようです。

[ ]
RE:10746 V9.15β1No.10747
秀丸担当 さん 22/04/04 16:23
 
分離の具合の情報ありがとうございます。
ウィンドウ分離の具合をいろいろなパターンで試してみて、こちらで初めて再現させ
ることができました。
とはいえ、再現できたのはV9.13までのほうで、V9.15β1では大丈夫になっているこ
とが確認できました。
V9.15β1の修正は一定の効果はあったのだと思いますが、V9.15β1での再現はできて
いないです。何はともあれ、もう少し調整してみます。

[ ]
RE:10739 V9.15β1No.10748
こみやんま さん 22/04/04 17:44
 
>V9.15β1を公開しました。

■マクロ実行での「""のくくり」

動作確認できました。ありがとうございます。
動作しているといえば、動作していますが、
""を除去している順番と、除去した情報をキャッシュへと記憶する順番のためか「"
"」が外側から除去されていくため、
「1回目は実行できない」が「2回目以降は実行できる」といった状況が発生します。
具体的には、"" が二重になっているなどです。

""C:\test\b.mac""

まぁこのようなことはワザと実験でやっているとかでない限り起きないいと思います
ので、
あまり気にする必要はないでしょう。


■Hidemaru_SetStaticVariable と Hidemaru_GetStaticVariable

動作の確認できました。(x86, x64) (共有フラグ -1,0,1,2)

確認する上で書いた関数呼び出し付近の記述
(https://github.com/komiyamma/hm_cpp_invoke/commit/0fcbc6c388788857f819edb8d
d901cdcf81151ba)

[ ]
RE:10747 V9.15β1No.10749
Y_H さん 22/04/05 09:13
 
引き続き調査いただき、ありがとうございます。

> とはいえ、再現できたのはV9.13までのほうで、V9.15β1では大丈夫になっている
>ことが確認できました。

これは、当初の「最初の一度だけフォーカスが戻らない」の方はV9.15β1で直ってい
て、
V9.15β1の「2回目以降はタスクバーが点滅するようになった」の方はそもそも発生
しない
ということになりますでしょうか?

ちなみに、こちらの環境は、Windows10のProを利用しています。
よろしくお願いいたします。

[ ]
RE:10748 V9.15β1No.10750
秀丸担当 さん 22/04/05 09:21
 
早速ご確認ありがとうございます。
""については、確かにそういうことが起こり得ますが、意図的にしないとそうならな
いので、あまり気にすることはないかもしれません。
Hidemaru_SetStaticVariableとHidemaru_GetStaticVariableについてもありがとうご
ざいます。

[ ]
RE:10749 V9.15β1No.10751
秀丸担当 さん 22/04/05 10:02
 
再現できたのは、あらかじめ分離した2つのウィンドウを出し、1つはタグジャンプ
元、もう1つはタグジャンプ先をあらかじめ開き、タグジャンプして、バックタグジ
ャンプをするという操作でした。
Windows 11で再現していました。
ウィンドウそのままにもう一度同じことをすると起きないので、最初の一度だけの問
題がV9.15β1で起きなくなったということになると思います。
2回目以降の問題は、こちらでは今のところ発生していないです。

[ ]
RE:10750 V9.15β1No.10752
こみやんま さん 22/04/05 11:31
 
>早速ご確認ありがとうございます。
>""については、確かにそういうことが起こり得ますが、意図的にしないとそうなら
>ないので、あまり気にすることはないかもしれません。
>Hidemaru_SetStaticVariableとHidemaru_GetStaticVariableについてもありがとう
>ございます。

ちょっと追加で調査していたのですが、

Hideamru_SetStaticVariable の返り値がおかしいかもしれません。
(秀丸で宣言している変数のスコープと対応してない印象、やむをえない実装上の結
果なのかどうか判断微妙)

L"" のLは目がチカチカするだけなので抜いて記述します

■マクロ内容が以下のようなものだとして

----------------------------------------------------------------------------
#dll = loaddll( currentmacrodirectory + @"\Dll11.dll" );
$_ = dllfuncstrw(#dll, "abc");
freedll(#dll);
----------------------------------------------------------------------------

■abc関数内で
----------------------------------------------------------------------------
BOOL r = Hideamru_SetStaticVariable("aaa", "", -1 );
----------------------------------------------------------------------------

とするとおそらくFALSEが返ってきます。

■続いて、abc関数内でと書き換えて
----------------------------------------------------------------------------
Hideamru_SetStaticVariable("aaa", "a", -1 );
BOOL r = Hideamru_SetStaticVariable("aaa", "", -1 );
----------------------------------------------------------------------------

さきほどマクロを実行した秀丸エディタプロセスと同じプロセスでマクロを実行する
と今度はTRUEが返ってきます。
(ここまでは、既存のキーが無いところに空値を格納したらfalse、キーがあれば空
文字の代入も当然true扱いは決して不自然ではないのでそうかもねーという挙動)

■ところが、次の挙動で首をかしげることになります。abc関数内を最初の通りに戻
して、
----------------------------------------------------------------------------
BOOL r = Hideamru_SetStaticVariable("aaa", "", -1 );
----------------------------------------------------------------------------
さきほどマクロを実行した秀丸エディタプロセスと同じプロセスでマクロを実行する
と今度もTRUEが返ってきます。


★これは「-1」という意味と合っていません★。
 プロセス内のメモリ管理が「マクロが終わった後も続いている」のであれば、この
挙動は妥当と言えますが、
 -1だとマクロが終了したらクリアされる、という意味合いだと違和感を感じます。
 (まるで、マクロが終了しても静的変数のキー登録だけは残してあって、value相当
だけはクリアしているといった挙動であるかのようなBOOL値が返ってきています)



[ ]
RE:10752 V9.15β1No.10753
こみやんま さん 22/04/05 12:02
 
個人的には、初めてのキーに対して空文字だったからfalseといった必要はなく、
「本当に代入に失敗した」時だけfalseの方が使いやすいかと思います。

得たいのは「実際に内部的に代入したかどうか」ではなく、
SetStaticVariable したにもかかわらず、何らかのエラー等により「代入したハズの
値にはならなかった場合にのみfalse」がほしいわけなので。

[ ]
RE:10753 V9.15β1No.10754
秀丸担当 さん 22/04/05 15:15
 
Hidemaru_SetStaticVariableの返り値は、確かに言われているようになりました。
まず、値""は0,1,2に倣って削除ということにしていました。
そのプロセスで初めて-1が使われたときにコンテナ的なものが作られるのですが、マ
クロが終わったらコンテナは空になります。
コンテナが存在しないときは失敗で、空のコンテナがあれば成功で、そういう結果で
した。
上限があるわけではないのでサイズを気にする必要はなく、表面的には削除でも""の
代入でも、どちらでもいいと思います。
基本trueで、本当に失敗したときだけfalseとなるよにしようと思います。

[ ]
RE:10751 V9.15β1No.10759
Y_H さん 22/04/06 12:37
 
V9.15β2で、前回と同じ動作を試させていただきました。
タグジャンプ元とタグジャンプ先を、別々のウィンドウで開いた状態です。

1回目のタグジャンプ、その後のバックタグジャンプ、2回目のタグジャンプまでは正
常で、
その後の2回目のバックタグジャンプのときにやはりタスクバーが点滅します。
ただ、すぐにその点滅が元に戻るようになりました。

Windowsのタスクバーは自動的に隠すようにしているため、
タスクバーが出てきて点滅し、すぐに隠れるという動きになります。

フォーカスが移らなかったり失われたりすることはなくなりましたが、
それ以降はタグジャンプのときも同じようにタスクバーが一瞬だけ点滅するようです。

自分の環境に依存するようなので恐縮ですが、報告させていただきます。

[ ]
RE:10759 V9.15β1No.10761
秀丸担当 さん 22/04/06 15:17
 
何度もすみません。
詳しい情報ありがとうございます。
2回目の件が、再現させることができました。
Windows 10で、タスクバーを自動的に隠す設定にして、さらにタスクバーを結合しな
い設定にすると、一瞬その状態になっていることが見えました。
再現できたので、こちらで調べて直すことができます。
また修正します。

[ ]
RE:10761 V9.15β1No.10764
Y_H さん 22/04/06 21:00
 
>Windows 10で、タスクバーを自動的に隠す設定にして、さらにタスクバーを結合し
>ない設定

まさにこの環境です。
こんな所の設定が絡んでいたのですか。
解明していただきありがとうございます。

[ ]
RE:10761 V9.15β1No.10774
Y_H さん 22/04/14 10:31
 
V9.15β3で、正しく動作することを確認しました。

当初の問題だった、最初の一度だけフォーカスが戻らない現象や、
その後のタスクバーが点滅する現象なども、すべて発生しなくなり、
正しくタグジャンプやバックタグジャンプを行えるようになりました。

いろいろ対応していただきありがとうございます。

[ ]
RE:10774 V9.15β1No.10775
秀丸担当 さん 22/04/14 11:06
 
ご確認ありがとうございます。
詳しい情報があって助かりました。

[ ]