◀Unicode版開発トップへ
  • 1182 CWSH.hのこと
    • 1183 Re:CWSH.hのこと
      • 1184 Re2:CWSH.hのこと
    • 1186 Re:CWSH.hのこと
      • 1187 Re2:CWSH.hのこと
      • 1189 Re2:CWSH.hのこと
    • 1193 Commit報告(Keep) マクロ関連コードと IDispatch実装を分離
      • 1196 Re:Commit報告(Keep) マクロ関連コードと IDispatch実装を分離
    • 1488 KqblABPELmcGoIT

  • [1182] CWSH.hのこと ds14050 2010年04月28日 09:46

    Emacsでもできるらしいのですが、例えば「Chapter (\d+)」を検索し、それを
    「js: "Chapter " + (+$1+1)」に置換することで、章番号を 1ずつ増加させる
    ようなことができたらいいなと思って WSH関連のコードを眺めていました。

    その過程で、IUnknownと IDispatchを実装した CWSHIfObj(旧CInterfaceObject)
    が、マクロと一体になっていて再利用しにくいことに気付きました。これでは
    ちょっとしたスクリプトを実行するために、(無視することも含めて)マクロに対
    応するか、IDispatchを再実装するかしなければいけない気がします。

    r1715<http://sakura-editor.svn.sourceforge.net/viewvc/sakura-editor?view=rev&revision=1715>
    以前はそうではなかったことを知って、気付かなかったことを後悔しています。

    また、ReadyCommands()と MacroCommand()が CWSHMacroManagerの配下から
    CWSHIfObj(旧CInterfaceObject)配下に移動していますが、これは危険では
    ないでしょうか。MacroCommand()の1行目の reinterpret_castは
    CWSHClientが CEditView* を伴って作成されたことを前提にしていますが、
    それを保証していたのは CWSHMacroManager::ExecKeyMacro()に思えます。

    # 自分がやりたいことは CInterfaceObject::AddProperty()を追加するだけで
    # 済みそうに思えてきたところなのですが、今は手を付けることが難しいです。

    • [1183] Re:CWSH.hのこと otomo 2010年04月28日 13:21

      JScriptですと、

      "1234".replace( /(\d+)/, function ($1) { return( "" + ( parseInt($1) + 1 ) ) } )

      みたいにすると検索した数値を計算した後で置換することができますよ。
      （置換語に、Stringを返す関数を使用できます。
      　その関数の引数は、後方参照の$1,$2,$3 ... です）

      • [1184] Re2:CWSH.hのこと ds14050 2010年04月28日 21:46

        ▼ otomoさん

        それだとたぶんマクロにしてみても検索条件や置換条件を入力できなくて、
        WSHで Scripting.FileSystemObjectを使った処理になると思うんです。
        エディタで検索や置換をするような手軽さでサクッと処理する方法が欲しかったんです。

        # エディタの外にでるなら Rubyで String#gsubという手もありますね。

    • [1186] Re:CWSH.hのこと syat 2010年04月29日 19:43

      ▼ ds14050さん
      > IUnknownと IDispatchを実装した CWSHIfObj(旧CInterfaceObject)
      > が、マクロと一体になっていて再利用しにくいことに気付きました。
      私の考えになりますが、サクラエディタでWSHスクリプトを扱いたい場合はCWSHMacroManagerを通してほしいです。
      CWSHIfObjは、マクロに渡すオブジェクトの基底クラスです。
      独自のマクロ関数が必要な時は、２つ方法があって、CSMacroMgrを修正してEditorオブジェクトに追加するか、またはCWSHIfObjを継承したC???IfObjを定義してCWSHMacroManagerにAddParamしてやります。
      r1715でWSH部分を修正した目的は、WSHでEditor以外のオブジェクトを扱うことで、それ以前はEditorオブジェクトがもっと深くWSHに食い込んでいました。

      ds14050さんが指摘されているのは、ManagerからExecKeyMacro()を呼ぶと必ずEditorオブジェクトが追加されてしまうのが邪魔、ということでしょうか？
      その意味なら、それはその通りです。Editorは共通的に参照できたほうが良いと思っておせっかいしてるだけなので、ManagerとEditorオブジェクトを分離するのはありだと思います。

      > また、ReadyCommands()と MacroCommand()が CWSHMacroManagerの配下から
      > CWSHIfObj(旧CInterfaceObject)配下に移動していますが、これは危険では
      > ないでしょうか。
      危険なのかはよくわかりません。
      CEditView*以外を渡したいときは別のManagerを作って、それにIfObjを追加するときに注意すればよいことだと思いますけれど。

      的はずれな回答だったらすみません。

      • [1187] Re2:CWSH.hのこと ds14050 2010年04月30日 11:55

        > サクラエディタでWSHスクリプトを扱いたい場合はCWSHMacroManagerを通してほしいです。
        CWSHMacroManagerを通しても自分のやりたいことはできそうですが、大げさだとも思います。
        CWSHMacroManagerを通した方がいい理由はなんでしょうか。CWSHMacroManagerはマクロファイル
        の読み込みや Editorオブジェクトの提供などマクロの実行に特化しすぎている気がします。
        旧CWSH.hを再利用可能な低レベルコンポーネントとして残したまま、CWSHMacroManagerと
        その配下(CEditorIfObjとCWSHIfObjをまとめたもの)が CWSH.hのいち利用者として実装されて
        いれば良かったのにな、という思いは変わりません。以下はその立場からの意見です。

        > それ以前はEditorオブジェクトがもっと深くWSHに食い込んでいました。
        とのことですが、それは WScriptや windowといったグローバルオブジェクト
        の名前が Editorであっただけなのではないでしょうか。自分の用途では
        * グローバルオブジェクトの名前はなんでもよい。
        * マクロを呼べる必要はない。(むしろ呼ばれると結果が予想できない)
        ので、CWSHIfObjを継承してマクロに関係した純粋仮想関数を定義することが
        余計な作業に思えます。virtual関数なのにマクロに特化している、実質
        CEditorIfObj向けの仕様だということも疑問です。

        > Editorは共通的に参照できたほうが良いと思っておせっかいしてるだけなので、
        > ManagerとEditorオブジェクトを分離するのはありだと思います。

        MacroManagerが Editorオブジェクトを追加するのは役割から考えて当然だと思います。
        自分は CWSHMacroManagerを作成したり ExecKeyMacro()を呼んだりするつもりはなく、
        直接 CWSHClientと CWSHIfObjを作成してスクリプトを実行しようとしています。

        > CEditView*以外を渡したいときは
        CWSHClientに CEditView*以外を渡したときは
        * CWSHIfObj::MacroCommand()
        * CWSHIfObj::ReadyCommands()
        * CWSHIfObj::HandleFunction()
        * CWSHIfObj::HandleCommand()
        * CWSHIfObj::GetMacroCommandInfo()
        * CWSHIfObj::GetMacroFuncInfo()
        これらが全て使えなくなります。こういうものはスクリプトに公開するオブジェクトの
        共通の基底クラスに、protectedや virtualとして提供されるよりも、その派生クラス
        の CEditorIfObjが備えているべきものではないでしょうか。

        > CEditView*以外を渡したいときは別のManagerを作って、それにIfObjを
        > 追加するときに注意すればよいことだと思いますけれど。

        注意すればいい、というのはよくない考えだと思います。syatさんや自分はもう
        注意することができますが、他の人はどうでしょうか。あるいは未来の自分は。
        問題に対して、注意します、もっと注意します、目を皿のようにして注意します、
        なんて対応をしないためにも、以前のように依存関係を一つの場所に閉じ込めて
        おく(※)か、危険な操作ができないように CWSHClientのコンストラクタを隠したり
        コンストラクタの最後のパラメータを void*から CEditView*にするなどの処置が
        あっていいと思いました。
        (後者の対処はさらに不自由になるので、例として挙げただけで望んではいません)

        ※ CEditorIfObjと、CWSHIfObjの protected/virtual部分を CMacroManager.cppへ。

        # 終始えらそうですいません。ディベートのようなものだと思って
        # 間違っていると思った部分は遠慮なく指摘してください。

      • [1189] Re2:CWSH.hのこと ds14050 2010年05月01日 03:05

        机上の空論でないことを示すためにパッチを置いておきました。
        ちらっとでも見てやってください。

        http://sourceforge.net/tracker/?func=detail&aid=2994883&group_id=12488&atid=1013762

    • [1193] Commit報告(Keep) マクロ関連コードと IDispatch実装を分離 ds14050 2010年05月09日 16:19

      リビジョン：
      　1757

      変更種別：
      　保守

      内容：
      Keep: CWSHIfObjから CIfObj(旧CInterfaceObject相当)を切り出して
      マクロ関連コードと IDispatch実装を分離。
      PatchUnicode#2994883, unicode:1182

      • [1196] Re:Commit報告(Keep) マクロ関連コードと IDispatch実装を分離 Uchi 2010年05月09日 21:50

        現在(リビジョン1759で確認)でビルドできないようです。
        ファイルのcommit忘れが有りませんか？

    • [1488] KqblABPELmcGoIT Canadian Pharmacy 2011年02月13日 02:42

      Very nice post, good luck! ;-)