none
CRichEditCtrl(RICHEDIT50W)で フォントをMS UI Gothicに設定すると2行目以降が違うフォントになる問題を回避したい RRS feed

  • 質問

  • VS2010 MFCを使用しています。

    表題通りなんですが、RICHEDIT50W にフォントを MS UI Gothicに設定して複数行文字を入力すると、
    2行目以降が違うフォントで表示されます。

    MS UI Gothic以外の MS ゴシック/メイリオ/MS 明朝などのWindows標準日本語フォントではこの現象は起きなくて問題無かったです。
    また、RICHEDIT50W以前のCRichEditCtrlでも問題ありません。


    サンプルを載せてますが、CreateFontの出力品質をいろいろ変えても同じでした。

    RICHEDIT50WでMS UI Gothicを使った場合だけの問題と思われますが、
    これを回避する方法がありましたらご教授お願いします。

    	// サンプル
    
    	LoadLibrary(TEXT("msftedit.dll"));
    
    	CRichEditCtrl *pEditCtrl = new CRichEditCtrl;
    	pEditCtrl->CWnd::CreateEx(
    		0					,			// 拡張スタイル
    		L"RICHEDIT50W"		,					// ウインドウクラス名称
    		L"縦書RichEditCtrl"			,			// キャプション
    		WS_BORDER | WS_CHILD | WS_VISIBLE | ES_MULTILINE , 		// スタイル
    		CRect( 0, 0, 800, 800),						// 位置とサイズ
    		this,								// this=DLG
    		UINT( 2000),							// ID
    		NULL
    		);
    
    	// 縦書きじゃなくても、この問題は発生する
    	//pEditCtrl->SendMessage( EM_SETOPTIONS, ECOOP_OR, ECO_VERTICAL);
    
    
    	int nFontSize = 24;
    
    	// Windows標準日本語フォント
    	//CString strFontName = _T("MS ゴシック");		〇
    	//CString strFontName = _T("メイリオ");			〇
    	//CString strFontName = _T("MS Pゴシック");		〇
    	//CString strFontName = _T("MS 明朝");		〇
    	//CString strFontName = _T("MS P明朝");		〇
    	CString strFontName = _T("MS UI Gothic");		X
    	CFont _Font;
    	_Font.DeleteObject();
    	_Font.CreateFont(
    		(int)( nFontSize ),	
    		0,			
    		0,						
    		0,		
    		FW_DONTCARE,	
    		FALSE,		
    		FALSE,		
    		FALSE,		
    		DEFAULT_CHARSET,
    		OUT_DEFAULT_PRECIS,
    		CLIP_DEFAULT_PRECIS,
    		OUT_DEFAULT_PRECIS,
    		PROOF_QUALITY,	
    		strFontName
        );
    
    	pEditCtrl->SetFont( CFont::FromHandle( _Font ) );
    	pEditCtrl->SetWindowTextW( _T("\r\n123456789012345678901234567890\r\n\r\n1234567890123456789012345") );
    	pEditCtrl->SetFocus();
    	pEditCtrl->Invalidate();

    この問題はWindows7では起きなくて、 Windows8以降で発生するようでした。

    その後
    Windows7のSystem32/msftedit.dllを Windows8.1/10のexeが入っているフォルダに持ってきたらこの問題は起きないのを確認しました。。
    ただ、msftedit.dllも新しいOS用に改修されていると思われますので、できればプログラムで回避したいと思います



    2017年10月21日 6:44

回答

すべての返信