WM_REMOTE_EXECMACRO_MEMORY が wstringにNo.09702
vscode-life さん 18/04/18 14:04
 
結構古い話題で恐縮なのですが、今日別件の投稿で調べていて気づいたので
投稿となります。

「新たなマクロを文字列で実行する」がらみの機能で

「WM_REMOTE_EXECMACRO_MEMORY」を利用した「SendMessage」を利用して
マクロを文字列で新たに実行する、といったものがありますが、

(特殊な範囲は置いておくとしても)常識的な範囲の文字に対応出来ていないのではな
いかと思います。
(恐らくマルチバイトの範囲しか対応できていない)

以下実験のソース

//----------------------------------------------------------------
// Project1.dllのProject.cpp
//----------------------------------------------------------------

#include <windows.h>
#include <string>
#include <process.h>

using namespace std;

#define WM_REMOTE_EXECMACRO_MEMORY (WM_USER + 272)

#define MACRO_DLL extern "C" __declspec(dllexport)
using PFNGetCurrentWindowHandle = HWND(WINAPI *)(void);


unsigned __stdcall mythread(void *lpx)
{
 int i;
 for (i = 0; i < 10; i++) {

  Sleep(2000);
  HMODULE hHideExeHandle = NULL;
  hHideExeHandle = LoadLibrary(L"hidemaru.exe");
  PFNGetCurrentWindowHandle Hidemaru_GetCurrentWindowHandle = NULL;
  HWND hwndHidemaru = NULL;
  if (hHideExeHandle) {
   Hidemaru_GetCurrentWindowHandle = (PFNGetCurrentWindowHandle)GetProcAddre
ss(hHideExeHandle, "Hidemaru_GetCurrentWindowHandle");
   hwndHidemaru = Hidemaru_GetCurrentWindowHandle();
   if (hwndHidemaru) {
    OutputDebugString(L"OK");
   }
  }
  else {
   OutputDebugString(L"NO");
  }

  WCHAR wszReturn[255];
  *(WORD*)wszReturn = _countof(wszReturn);
  LRESULT lRet = SendMessageW(hwndHidemaru, WM_REMOTE_EXECMACRO_MEMORY, (WPA
RAM)wszReturn, (LPARAM)LR"(insert "&#9836;";)");
  OutputDebugString(L"NO");

 }
 return 0;
}

HANDLE hTh;
MACRO_DLL intptr_t abc(wchar_t *sz) {

 UINT thID;
 int i;

 hTh = (HANDLE)_beginthreadex(NULL, 0, mythread, NULL, 0, &thID);

 return 0;
}


//----------------------------------------------------------------
// 呼び出す側のマクロ a.mac
//----------------------------------------------------------------
#DLL = loaddll( currentmacrodirectory + @"\Project1.dll" );
 
#r = dllfuncw( #DLL, "abc");




[ ]
RE:09702 WM_REMOTE_EXECMACRO_MEMORY が No.09703
vscode-life さん 18/04/18 14:08
 
「&#9836」となっているところは、Unicode範囲で使える音符一文字です。
(「♪」ではないやつ)

掲示板の機能で自動的に変換されてしまっているようです。


[ ]
RE:09703 WM_REMOTE_EXECMACRO_MEMORY が No.09704
秀丸担当 さん 18/04/18 17:01
 

サンプルの該当の文字はU+266Cの文字(10進数で9836)を直接入力して、ソースをUT
F-16で保存して、Visual C++ 2013で試してみました。
2秒おきに秀丸エディタ上で音符が2つ連なった文字が入力され、問題はなさそうでし
た。

ソースがもしUTF-8だとしたら文字化けすると思うので、UTF-16のほうが確実だと思
います。
該当の文字はフォントによってグリフが存在しない場合があるようなので、MS ゴ
シックにすると確実だと思います。

[ ]
RE:09704 WM_REMOTE_EXECMACRO_MEMORY が No.09705
vscode-life さん 18/04/18 21:25
 
>該当の文字はフォントによってグリフが存在しない場合があるようなので、MS ゴ
>シックにすると確実だと思います。
フォントでした… スミマセン。

[ ]
RE:09703 WM_REMOTE_EXECMACRO_MEMORY が No.09706
でるもんたいいじま さん 18/04/19 07:19
 
でるもんた・いいじまです。細かい話です。

> 「&#9836」となっているところは、Unicode範囲で使える音符一文字です。
> (「♪」ではないやつ)

「16分音符の2連符」ですね。
手元のcharmap.exeでは U+266C: Beamed Sixteenth Notes と出ます。

この文字、最近、Twitterとかでよく使われていますね。
私自身もそれなりに使いますw

> 掲示板の機能で自動的に変換されてしまっているようです。

この投稿、メールで送信されました?
それともWebのフォームから投稿されました?

前者ならおっしゃる通りコミュニテックスの仕様ですが、後者なら
Shift_JIS(やJIS、EUC)のWebページ上の入力フォームでCP932外の
文字を送信しようとしたときの一般的なブラウザの仕様ですよね。

それにしても、メールで受け付ける場合にこのへんを考慮しなきゃ
いけないというのは個人的にも盲点でした。
もちろん、今からスクラッチで掲示板を作り直すとしたら、
UTF-8が第一選択になるでしょうけど。

[ ]
RE:09705 WM_REMOTE_EXECMACRO_MEMORY が No.09707
でるもんたいいじま さん 18/04/19 07:27
 
でるもんた・いいじまです。

> > 該当の文字はフォントによってグリフが存在しない場合が
> > あるようなので、MS ゴシックにすると確実だと思います。
> フォントでした… スミマセン。

すでにご承知かと思いますが、秀丸のステータスバーにはカーソル
位置の文字コードを表示させることができます。そちらの画面
デザインにもよりますが、これをONにしてみてはどうでしょうか?
設定するには、その他(O)→動作環境(E) で、左側のツリーの一番上の
「ウィンドウ」をクリックすると、ステータスバーの項があります。

あるいは、その他(O)→コマンド一覧(O)→その他(O)→文字コード表示
というコマンドもありますので、それを何かのキーに割り当てても
いいと思います。

[ ]
RE:09707 WM_REMOTE_EXECMACRO_MEMORY が No.09708
秀丸担当 さん 18/04/19 16:25
 

最初やってみてconsolasで[?]のようになったので単なるグリフの問題と思ったので
すが、「&#9836;♪」とか、行内にShift-JISの全角文字が1つでも含まれている場合
は大丈夫で、描画上の問題でした。

この問題はずっと以前からあって、Widows2000頃からWindowsによって自動的に別の
フォントでグリフを代替するようになってきて、Windowsのバージョンが進むにつれ
ていままでだめだった文字も大丈夫になったりしてきていました。
しかしまだだめなものがあるようで、たびたび問題になるので、標準の状態でも回避
できる方法を検討します。
ちなみにWin32APIのExtTextOut()だとだめで、TabbedTextOut()だと大丈夫という、
規則性がよくわからない問題です。
現状では、[その他]→[動作環境]→[表示/操作]→[文字の描画]→[3Dグラフィックス
…]をONにしてDirectWriteを使うと回避できます。

[ ]