[1295] プラグインコマンドの問題点 syat 2010年06月30日 07:47

ICONの話で見つかったプラグインについての問題のまとめです。
>>unicode:1272 もかさん
> 1. 新しいウィンドウでプラグインを追加してツールバー・メニューに入れると古い方では、プラグインとアイコンが一致しないので、ツールバーの再表示でおかしくなるかも
> 2. プラグインコマンドをツールバーに登録した後、そのコマンドより先にコマンド登録されるプラグインでコマンドが増えると、登録したものがずれるようにみえる
> 3. PlugId と PluginId が混同されているみたい。ついでに両方とも変数名が m_idなのでなおさら区別がつかない
> 4. 今は20個のプラグインしか登録できないけど、私のはすでに9番目まで使用中
>>unicode:1273 Uchiさん
> 内部的に自動割当されている番号（コマンド番号、ツールバー番号等）を、外部ファイルの sakuraW.ini に書き出しているのが問題なのだと思います。
> このあたりを如何にかすべきでしょう。
>>unicode:1277 Uchiさん
> プラグインのｉｎｉファイルへの書き込み（Pluginh本体ではなく、 Toolbar,CustMenu,KeyBind）を文字列化（PluginId/番号の形）で行うパッチ PatchUnicode#3020889
>>unicode:1281 もかさん
> ・プラグインのボタン番号の内部仕様
> 次からはプラグイン(とマクロのアイコン超過分)だけFuncCodeにしておく
> ・プラグインのボタン番号のini仕様
> 過去のUnicode版との互換性は放棄して上記内部コードで保持すれば今後の分は互換性保てるだろう派
> m_sIdベースにするのもいいかもしれないけど、クラス/関数の依存関係の調査や互換性の検討と末永い保守が必要
> indexの代わりにコマンド番号にするパッチ PatchUnicode#3020183 B案

こんなかんじでしょうか。

[1298] Re:プラグインコマンドの問題点 Uchi 2010年07月01日 00:37

▼ syatさん
> ICONの話で見つかったプラグインについての問題のまとめです。

私的に抜けていると思うものを追加させてもらいます。
> ICONの話で見つかったプラグインについての問題のまとめです。
>>unicode:1281 もかさん
>また今の仕組みだと、プラグインを削除→再登録した場合は、プラグイン番号が変更になり、カスタムメニューなどで使えません。
>(これは、私のパッチでもUchiさんのパッチでも発生します)
>これは、共通設定画面で削除待ちのものを復活させるように同じ番号に戻せば改善されると思います

また、ICONの事とは直接関係しませんが、
プラグインを追加し、再起動しないで、そのまま作業を続けると落ちます。
3回ほど落ちましたが100％です。以降プラグイン追加後は再起動しているので現象は確認できていません。
落ちるまで行った作業はさまざまですが、新しいウインドウでの作業がほとんででした。

もかさんは、落ちないで作業されているようですが、何か違いがあるのでしょうか？
- [1300] Re2:プラグインコマンドの問題点もか 2010年07月01日 02:39
  
  >また、ICONの事とは直接関係しませんが、
  >プラグインを追加し、再起動しないで、そのまま作業を続けると落ちます。
  >3回ほど落ちましたが100％です。以降プラグイン追加後は再起動しているので現象は確認できていません。
  >落ちるまで行った作業はさまざまですが、新しいウインドウでの作業がほとんででした。
  落ちるのは優先度高だとおもいます。
  それはsyatさんのU2パッチを適用後それともrev1779でしょうか。
  エラーコードはなんだったんでしょうか。0x00000005 ならぬるぽ、0xc000000dならstrcpy_sなどの誰かだとおもいます。
  VC Express はJITデバッガがないのでトレース実行かアタッチしないと使えないけど、dumpファイルをWinDbgで開くと場所はわかるはずです。
  >もかさんは、落ちないで作業されているようですが、何か違いがあるのでしょうか？
  なんででしょう。まだ基本的にサクラ帳2010 SP3d使いなので rev1768ベースです。
  パッチ作成時にはrev1779で作業したけどコード修正後のバイナリで多少確認したぐらいで、rev1779の状態では、ほとんどテストしたことがないです。
  - [1301] Re3:プラグインコマンドの問題点 Uchi 2010年07月01日 21:39
    
    ▼ もかさん
    > >また、ICONの事とは直接関係しませんが、
    > >プラグインを追加し、再起動しないで、そのまま作業を続けると落ちます。
    > >3回ほど落ちましたが100％です。以降プラグイン追加後は再起動しているので現象は確認できていません。
    > >落ちるまで行った作業はさまざまですが、新しいウインドウでの作業がほとんででした。
    > 落ちるのは優先度高だとおもいます。
    > それはsyatさんのU2パッチを適用後それともrev1779でしょうか。
    > エラーコードはなんだったんでしょうか。0x00000005 ならぬるぽ、0xc000000dならstrcpy_sなどの誰かだとおもいます。
    > VC Express はJITデバッガがないのでトレース実行かアタッチしないと使えないけど、dumpファイルをWinDbgで開くと場所はわかるはずです。
    > >もかさんは、落ちないで作業されているようですが、何か違いがあるのでしょうか？
    > なんででしょう。まだ基本的にサクラ帳2010 SP3d使いなので rev1768ベースです。
    > パッチ作成時にはrev1779で作業したけどコード修正後のバイナリで多少確認したぐらいで、rev1779の状態では、ほとんどテストしたことがないです。
    ４月（プラグインのオプション画面を作った後）ぐらいの話です。
    その後はプラグインの追加時には必ず、再起動しています、ので現象は見ていません。
    プラグインの設定時の読み込みを行えば、OKまたはそのときに原因究明しようということで（回避方法もはっきりしているので）、後回しにしていました。
    再度確認してみます。
    記憶に残っているのは、MSのエラー画面も残さず、何もなかったように落ちました。
    
    再度確認してみます。
[1330] Re: プラグインコマンドの問題点もか 2010年07月16日 02:09

Pluginのm_sIdをiniに書き込むなら m_sId自体の問題も解決しないといけないので、その問題のまとめです。
かなり前に元の原稿は書いたまま放置してました。

>>unicode:1136
と、Uchiさんのパッチを評価するときに、m_sId周りについて調べてわかったこと。
Pluginの識別方法が4種類ある。
フォルダ名、CPlugin#m_sId、CPlugin#m_id、DLLSHAREDATAのID(m_szId)
フォルダ名==DLLSHAREDATA(DLLSHARE)のPluginRec#m_szName==saura.iniだとName
Pluginは、フォルダ名ベースで読みこみ
CPlugin#m_sIdは、plugin.defの値。プラグイン更新などでplugin.defが変更されるとDLLSHAREと不一致になる
DLLSHAREのm_szIdは設定画面でのプラグインインストール時に一意性を確認。m_szIdは更新処理されないので最初のときの値のまま。Pluginの設定ファイルはフォルダ名ベースなので同一m_sIdの影響を受けない
これらの作用で更新後にplugin.defのIDが変わったプラグインをコピーしても「別のプラグイン」として問題なく動いてしまう

現時点でユニークであることを保証できるのは、PluginRec#m_szName(フォルダ名)かCPlugin#m_Id
ただしNameもsakuraw.ini を直接書き換えることにより重複できるので、完全にユニークなのはCPlugin#m_idのみ
　Uchiさんの新パッチでは旧パッチでCPlugin#m_sIdだったものがDLLSHAREのm_szIdになったので、その辺の矛盾の影響は、正規ルートでは問題なくなりました。

設定画面のときに、既存のプラグインのDLLSHAREのm_szIdを更新確認するようにして、
プラグイン読み込み時に、CPlugin#m_sIdとDLLSHAREのm_szIdが違ったら無効にしてしまえば、より安全かなと。
でも更新してしまうと、既存プロセスのIdが一致しなくなる。

▼ env/CommonSetting.h PluginRec
>m_szName[MAX_PLUGIN_NAME]; //!< プラグイン和名
コメントがなんかおかしいような。
PluginRec#m_szName/フォルダ名と、CPlugin#m_sName/plugin.defのName=和名が混ざってます。

プラグインのコマンド番号が、「プラグインの更新」を考慮してくれない。という問題もあります。
コマンド番号は維持しないと[名前/番号]で保持しようが、各種設定がずれてしまいます。
・プラグイン更新時に3番目のコマンドを削除するとかができない
・並び替えたいときに、コマンド番号をただ並び替えると困る
プラグ番号とコマンド用番号を2重管理できるような項目を追加すれば解決できるかもしれない。
- [1337] Re2: プラグインコマンドの問題点 syat 2010年07月18日 12:35
  
  ▼ もかさん
  > 設定画面のときに、既存のプラグインのDLLSHAREのm_szIdを更新確認するようにして、
  > プラグイン読み込み時に、CPlugin#m_sIdとDLLSHAREのm_szIdが違ったら無効にしてしまえば、より安全かなと。
  そう思います。
  > でも更新してしまうと、既存プロセスのIdが一致しなくなる。
  今のところ起動時にしかId見てないので既存プロセスの不一致は無視できるとおもいます。
  
  > ▼ env/CommonSetting.h PluginRec
  > >m_szName[MAX_PLUGIN_NAME]; //!< プラグイン和名
  > コメントがなんかおかしいような。
  はい。現状フォルダ名以外のなにものでもありません。
  
  > プラグインのコマンド番号が、「プラグインの更新」を考慮してくれない。という問題もあります。
  > コマンド番号は維持しないと[名前/番号]で保持しようが、各種設定がずれてしまいます。
  > ・プラグイン更新時に3番目のコマンドを削除するとかができない
  > ・並び替えたいときに、コマンド番号をただ並び替えると困る
  > プラグ番号とコマンド用番号を2重管理できるような項目を追加すれば解決できるかもしれない。
  コマンド番号はプラグイン作者側で維持して欲しかった…。C[n].Idとかつけますか。
  たしかに3番目のコマンドを単純に削除すると2番目までしか読み込まない動きなので、抜けがあっても最後まで読み込む改造は必要かも。
  （あれ、何でプラグはvectorにしたんだっけ？）
  - [1345] Re3: プラグインコマンドの問題点 syat 2010年07月23日 07:05
    
    ▼ もかさん
    > プラグインのコマンド番号が、「プラグインの更新」を考慮してくれない。という問題もあります。
    > コマンド番号は維持しないと[名前/番号]で保持しようが、各種設定がずれてしまいます。
    確かにそうなのですが、それはサクラ本体も同じで今の方式でうまくいっているのはコマンド番号が途中で変わったりしないからです。プラグインも同様に開発者側で番号を変えないよう努力してもらうべきと思います。
    C[n].Idのような文字列IDをくっつけても、その文字列を変えたくなるのが人情ですし、あんまり汎用的にせずシンプルがよいのでは。
    
    > ・プラグイン更新時に3番目のコマンドを削除するとかができない
    コマンド番号死守で行くなら、途中のコマンドを削除したいときのために抜けがあっても最期まで（n=1～99）見るよう改造がいります。
    
    > ・並び替えたいときに、コマンド番号をただ並び替えると困る
    並び替えないでください。となります。(plugins.def内の位置を入れ替えるのは自由ですが)
    
    > プラグ番号とコマンド用番号を2重管理できるような項目を追加すれば解決できるかもしれない。
    どういうものかはわからないですが、さらに複雑になる気がします。
    
    コマンド番号の話がこれでよければ、Uchiさんの文字列化パッチ3020889でOKかと思っています。
    
    ＃プラグイン毎のコマンド数を減らして使えるプラグインを増やすという話は個人的に賛成なのであとでパッチあげるかもしれません。
    - [1348] Re4: プラグインコマンドの問題点もか 2010年07月24日 03:13
      
      (前後ひっくり返します)
      >コマンド番号の話がこれでよければ、Uchiさんの文字列化パッチ3020889でOKかと思っています。
      コマンド番号の上位の部分は、文字列化でOKです。
      文字列化パッチ3020889 での外部仕様で、私も問題ないと思います。
      アイコン番号なのか、ボタン番号なのかという話はありますけど、はるか昔の記事でげんたさんもアイコン番号と発言してますし。
      個人的には、myButtonのindexとiBitmapとは、特にUchiさんのパッチ後では、+1の関係が崩れてくるので、
      ボタン番号に統一したいところだけど、動作上は違わないので、後で気が向いたときに考えます。
      static類と、DLLSHAREで保持するのが若干引っかかるけど、それは内部仕様なので修正可能です。
      
      >> プラグ番号とコマンド用番号を2重管理できるような項目を追加すれば解決できるかもしれない。
      >どういうものかはわからないですが、さらに複雑になる気がします。
      ちょっと、テストパッチをこさえてみます。しかしご指摘の通り複雑になりそうです。作ってから考えます。
      こんな感じのものです。
      [Command]
      C[1].Order=1
      C[2].Label=追加
      C[2].Order=3
      C[2].Label=複製
      C[3].Deleted=true
      C[3].Label=削除済みコマンド
      C[4].Order=2
      C[4].Label=更新
      それかあきらめて最大のID番号を書いておくとか。
      MaxCount=4
      ついでに、Disableフラグを検討中です。ビューモードではグレーダウンとかです。

[1295] プラグインコマンドの問題点 syat 2010年06月30日 07:47

[1298] Re:プラグインコマンドの問題点 Uchi 2010年07月01日 00:37

[1300] Re2:プラグインコマンドの問題点 もか 2010年07月01日 02:39

[1301] Re3:プラグインコマンドの問題点 Uchi 2010年07月01日 21:39

[1330] Re: プラグインコマンドの問題点 もか 2010年07月16日 02:09

[1337] Re2: プラグインコマンドの問題点 syat 2010年07月18日 12:35

[1345] Re3: プラグインコマンドの問題点 syat 2010年07月23日 07:05

[1348] Re4: プラグインコマンドの問題点 もか 2010年07月24日 03:13

[1300] Re2:プラグインコマンドの問題点もか 2010年07月01日 02:39

[1330] Re: プラグインコマンドの問題点もか 2010年07月16日 02:09

[1348] Re4: プラグインコマンドの問題点もか 2010年07月24日 03:13