◀ANSI版開発トップへ
  • 2554 GetSelectedString
    • 2556 RE: GetSelectedString
      • 2557 Re2: GetSelectedString
        • 2582 Re3: GetSelectedString
          • 2585 Re4: GetSelectedString
      • 2586 マクロ関数の共通処理
        • 2587 Re:マクロ関数の共通処理
          • 2592 Re2:マクロ関数の共通処理
            • 2593 Re3:マクロ関数の共通処理
            • 2607 Re3:マクロ関数の共通処理
              • 2614 いいわけ
        • 2588 Re: マクロ関数の共通処理
          • 2589 Re2: マクロ関数の共通処理
  • [2554] GetSelectedString おに 2003年02月03日 00:14

    一般のほうでGetSelectedStringについて尋ねたのですが、いただいた返答によりますと「SelectedString」なのに「検索ダイアログに取り込まれる文字列」を返すようなので、複数行選択されていても二行目以降の取得ができない様子。
    なので、「選択文字列」を返すように書き換えてみました。

    //CWSH.cppの"case F_GETSELECTED:"以下の部分を修正

    if(Result != NULL)
    {
    if(View->IsTextSelected())
    {
    CMemory cMem;
    if(!View->GetSelectedData(cMem, FALSE, NULL, FALSE, FALSE)) break; //??
    int Length = cMem.GetLength();
    wchar_t *buf = new wchar_t[Length + 1];
    buf[MultiByteToWideChar(CP_ACP, 0, cMem.GetPtr(), Length, buf, Length)] = 0;
    Result->vt = VT_BSTR;
    Result->bstrVal = SysAllocString(buf);
    delete[] buf;
    }
    else
    {
    Result->vt = VT_BSTR;
    Result->bstrVal = SysAllocString(L"");
    }
    }
    break;

    //テスト

    var s = Editor.GetSelectedString(0);
    Editor.InsText("<code>" + s + "</code>");

    …何も考えずにごそっと入れ換えてますが、「検索ダイアログに取り込まれる文字列」に理由があったらどうしよう(-_-;
    • [2556] RE: GetSelectedString もか 2003年02月06日 18:57

      ▼ おにさん
      CPPA.cpp のほうはこんな感じでしょうか?
      case F_GETSELECTED:
      cMem.SetDataSz( "" );
      *ResultValue = cMem.GetPtr();
      if( View->IsTextSelected() ){
      if( View->GetSelectedData(cMem, FALSE, NULL, FALSE, FALSE) )
      *ResultValue = cMem.GetPtr();
      }
      break;

      #選択中のデータにNULが含まれていたら仕様上、NULより後ろは切り捨てられます。

      CMacro::HandleCommand()のように、値を返す関数も共通部分をまとめられると
      関数の追加・保守が楽になるかも。


      >「検索ダイアログに取り込まれる文字列」に理由があったらどうしよう(-_-;
      MACRO掲示板のほうに書いたExpandParameter(仮名)を追加すれば
      Editor.ExpandParameter( "$s" );
      で、代用可能なのでばっさり書き換えてもいいと思います。
      • [2557] Re2: GetSelectedString おに 2003年02月06日 21:25

        ▼ もかさん
        > #選択中のデータにNULが含まれていたら仕様上、NULより後ろは切り捨てられます。
        あーっ、そうですよねえ。
        [2554]で僕が書いたコードでもSysAllocStringの仕様上そうなりますね。
        SysAllocStringLenで割り当てて自前でコピー、かな?

        > Editor.ExpandParameter( "$s" );
        > で、代用可能なのでばっさり書き換えてもいいと思います。
        よかった。
        それでは、GetSelectedStringの引数もう要りませんよね、とか言ってみたりして^^
        • [2582] Re3: GetSelectedString げんた 2003年02月18日 02:42

          >> Editor.ExpandParameter( "$s" );
          >> で、代用可能なのでばっさり書き換えてもいいと思います。
          >よかった。
          ってまだ実装されてませんってば。気が早いなぁ。

          >それでは、GetSelectedStringの引数もう要りませんよね、とか言ってみたりして^^
          今のやつは明示的に選択しなくてもキャレット位置の単語を取り込んでくれるからそれなりに使えそうかな~なんて。
          引数どうしましょうか。置き換えた方がいいのか、引数が1のとき複数行対応とすべきか。
          • [2585] Re4: GetSelectedString おに 2003年02月19日 07:16

            ExpandParameterを実装するに一票。
            他の情報も取得できますし。
            GetSelectedStringは名前の通り純粋に選択文字列だけを返す単純な関数でいいと思います。引数も要らないんじゃないかな。
            (マクロから使うときは、選択が無い場合は空文字列が返ってくる方が便利なので)

            えーと、CEditDoc.ExpandParameterを呼ぶだけでいいから…
            (↑はい、気が早いです^^)
      • [2586] マクロ関数の共通処理 おに 2003年02月21日 07:26

        ExpandParameterを実装するより先に、
        ▼もかさん
        >CMacro::HandleCommand()のように、値を返す関数も共通部分をまとめられると関数の追加・保守が楽になるかも。
        をやってしまったほうが楽かなあ、と思いまして、CMacro.hにHandleCommandと並べて、次の関数を追加したいのですが、仕様はよろしいでしょうか?

        static bool HandleFunction(CEditView* View, int Index, VARIANT* Arguments, int ArgSize, VARIANT &Result);

        成功時Resultに中身を詰めてtrueを返し(Resultの中身の破棄は呼び出し側)、失敗時はfalseを返しResultは無変化。
        VARIANTは、複数の型を詰められる構造体なら何でもいいのですが、折角CSMacroMgr.cppのテーブルをVT_...にしていただいたので、これならCWSH.cppからは無変換でいける、という手抜きを考えております。
        実はPPAを知らないので、PPAに都合のいい形式があるならそれに合わせた方がいいかも知れません。

        ところで、CSMacroMgr.h/cppの、Sには意味があるのでしょうか?
        CMacro*から見て、関連するファイル名が並んで無いと不便だなと思っただけなのですけど。
        • [2587] Re:マクロ関数の共通処理 おに 2003年02月21日 10:25

          考えれば考えるほど書いてしまいたくなったので実装。
          http://www.egroups.co.jp/files/sakura-editor/Developer/Source/macro_handlefunction.zip

          WSHからはHandleFunctionを呼ぶようにしています。
          PPAは、申し訳ありませんがわかる人よろしくです。
          ExpandParameterは、HandleFunction中では書いてますが、機能テーブルへは追加していない状態です。
          //追加の仕方が、全部で何箇所を弄ればいいか把握できなかった…これもわかる人よろしくです。

          OleTypes.hは、VARIANTを簡単に使うためのラッパーです。
          なんか無駄なMBCS←→Wide変換だらけですが、内部がUnicode化されれば無駄な変換も無くなるということでお許しをm(_ _
          • [2592] Re2:マクロ関数の共通処理 もか 2003年02月24日 23:25

            ▼おにさん
            >//追加の仕方が、全部で何箇所を弄ればいいか
            あとは、機能テーブルへ追加するだけだと思います。
            >OleTypes.hは、VARIANTを簡単に使うためのラッパーです。
            #ifディレクティブで、sizeof演算子は使えないためエラーになってしまいます。
            何とかして、構造体とラッパー用クラスの変換(reinterpret_cast)が可能かチェックしたいけれど、いい方法が分かりません。
            sizeof演算子でWrap実行時にチェックというのはどうかと思うしなぁ。

            >PPAは、申し訳ありませんがわかる人よろしくです。
            よくはわかっていないのですが、PPA付属のソースを参考に、ためしに実装してみました。
            現時点の実装ではエラーの内容が分かりません。
            引数リストの過不足はPPA.dllが判断してエラーを返すはずです。

            macro_handlefunction.zipにPPAの処理を追加し、コンパイルエラーの修正をしたものです。
            テストの都合上、機能テーブルへ追加してしまいました。
            1.3.7.0(ssrc_2003-02-18)からの差分になっています。
            http://www.egroups.co.jp/files/sakura-editor/Developer/Source/
            変更されたファイル一式:macFuncPPA.zip
            上のDIFF版:macFuncPPA_diff.lzh

            *その他
            MacroFuncInfo.m_pszDataの用途がわかりません。
            CPPA.cppでデータを格納していますが、このデータも利用してはいません。
            削除しても問題ないでしょうか?

            #CSMacroMgrのSは昔マクロがShareDataに保存されていた(らしい)ときの名残のSかも
            • [2593] Re3:マクロ関数の共通処理 おに 2003年02月25日 11:24

              ▼ もかさん
              > #ifディレクティブで、sizeof演算子は使えないためエラーになってしまいます。
              あれ、bccではできましたよ。
              (でも#ifdefで__BORLANDC__の時だけチェックするのは??)

              「エラー」というのは、型が違った時などにユーザーに通知する情報って事…ですよね。

              //case文見てると、OleTypes.hにVariant.AsInteger()等も追加した方が良さそうに思えてきました。
              //なおローカル変数ではラッパークラスVariantを使えばInit/Clearの手間は無い筈です。
              //それ以前にAnsi/Wide変換をどうにかした方がいいかも…。

              > テストの都合上、機能テーブルへ追加してしまいました。
              ありがとうございます。
              丸投げにして申し訳ないです(汗
              ExpandParameterが動くのを確認しました。

              > #CSMacroMgrのSは昔マクロがShareDataに保存されていた(らしい)ときの名残のSかも
              なるほど
            • [2607] Re3:マクロ関数の共通処理 げんた 2003年03月08日 21:30

              超久しぶりにソースをチェックしています。
              寒い上に平日は疲れて頭がウニになっていた日が多かったのですが、だんだん暖かくなってやりやすくなってきました。

              手始めにおにさん、Mocaさんの提供してくださったマクロ関数を見ています。

              * OleTypes.h
              引数で参照型を使っているところはすべてconstをつけた方がよいかと思って試したら、VARIANTはコピー元がconstだとダメなんですね。う~む。SysStringの方も::SysStringLen()がconst BSTRじゃなくてBSTRを引数にとるので、thisがconstだとエラーになってしまう。単にconst_cast<>で逃げても問題ないのだろうか。それともconstではまずい理由があるのだろうか。(とAPIの文句を言ってもしょうがないかもしれませんが)。COM/OLE周りはあまり詳しくないので、だれか教えてくださいまし。

              char/wcharからの変換で、const char*ではなくchar const*としてあるのは何か理由があるのでしょうか。

              SysString::Get()で得られる文字列をパラメータSで受け取るようになっていますが、戻り値で返した方がstd::auto_ptr<>に直接入れたりできて便利じゃないでしょうか。

              operator=(SysString&)があるけど operator=(BSTR&)が無いので、BSTRが与えられたときはSysStringの一時オブジェクトを経由することになってコピーが2回発生することになるのでは?というのは考え過ぎかな。

              *CPPA.cpp
              329行目で CMemory::SetDataに文字列長としてlen+1を渡していますが、最後の\0を含めない長さを与えることになっているので+1は不要だと思います。
              • [2614] いいわけ おに 2003年03月10日 08:47

                ▼ げんたさん
                > * OleTypes.h
                > char/wcharからの変換で、const char*ではなくchar const*としてあるのは何か理由があるのでしょうか。
                僕は(あくまで最近ですが)「constは左にかかる」という単純なルールでもってコーディングしてるので、そう書いただけです。(^^
                (意味は変わらないはず)

                > SysString::Get()で得られる文字列をパラメータSで受け取るようになっていますが、戻り値で返した方がstd::auto_ptr<>に直接入れたりできて便利じゃないでしょうか。
                えーと…「文字列」と「長さ」というふたつの結果を返すのに、どちらかだけ戻り値でどちらかだけ引数というのも…と思ったので。
                (実はstd::stringで返すのが一番よかったかも)

                > operator=(SysString&)があるけど operator=(BSTR&)が無いので、BSTRが与えられたときはSysStringの一時オブジェクトを経由することになってコピーが2回発生することになるのでは?というのは考え過ぎかな。
                デフォルトの代入演算子だとまずいなー書いとかないと、程度で、その辺何も考えてませんでした。
                コンストラクタのBSTR版に、explicit付けた方が確実かも知れませんね。

                constは…。
                ごめんなさい、わかりません。
        • [2588] Re: マクロ関数の共通処理 げんた 2003年02月22日 03:25

          >ところで、CSMacroMgr.h/cppの、Sには意味があるのでしょうか?
          >CMacro*から見て、関連するファイル名が並んで無いと不便だなと思っただけなのですけど。
          ごめんなさい。私も思い出せません。
          確実に言えることは、深い意味はないってことだけです。

          でも、ソース管理の都合上ファイル名変更は行わないでくださいね。
          • [2589] Re2: マクロ関数の共通処理 おに 2003年02月22日 09:56

            ▼ げんたさん
            > でも、ソース管理の都合上ファイル名変更は行わないでくださいね。
            はい、わかってます。

            …でも、my*とか見てると、etc_utyと併せて機能別に整理したくなったり…いえいえ、やりませんから。思うだけ(w