オーナードローでサブメニューの▶を描画する方法

メニューのオーナードローをした時、どうしても制御できないのがメニューのボーダ部分とサブメニューの▶の部分
いろいろ調べて▶の部分が制御ができるようになった。

オーナードローをしても、枠の灰色の線とSubの隣の▶の色が環境依存で、指定が出来ない。
▶については、通常黒で、選択すると反転して白になる。
左図のような黒背景だと▶が見えない。
DrawItemイベントでは描画しておらず、その後に勝手に描画されるからSetTextColorとか適用されないかな？と思ったけど無視される。

やり方は、ExcludeClipRectでメニュー項目全体をクリップすると、勝手に描画されるのを抑制できるので、あとは自分で描画するだけ。

通常状態でも白で表示出来るようになった。

VS2017のAllocConsoleでUnicode(UTF-16)出力

std::wcout.imbue(std::locale("Japanese")) ;
AllocConsole() ;
FILE * pF = _wfdopen( h, L"w" ) ;
fclose( stdout ) ;
*stdout = *pF;
setvbuf( stdout, NULL, _IONBF, 0 ) ;

VS2010では上記のコードで、wcout、wprintfを使ってコンソール出力が出来た。

VS2017でコンパイルすると、コンパイルは通るが実行すると落ちる。
いろいろ調べてみた結果、_wfreopen(freopen)でstdoutを"CONOUT$"で開き直すとコンソールと紐付けは出来るようだ。

でも、printfすると落ちる。
wprintfすると表示されなかったり、表示されるが16進文字だったり、文字化けしていたり。
wcoutは日本語は表示されるが、"\n"、endlの部分で落ちる。
coutはやってない。
唯一、表示されるのがWriteConsole関数。

試してみたのは下記のキーワード
wcout.imbue
_wsetlocale(setlocale)
setvbuf
_setmode
wcout.rdbuf
SetConsoleOutputCP
sync_with_stdio

どうやってもまともに表示されない。

色々やっているとwcoutで落ちるのは、rdbufが準備できていない？感じで、rdbufを入れ替える方法を見つけたのでwcout以外は全部捨てて対応したコードが下記。

class Out {
private :
class Buf : public std::wstreambuf {
private :
HANDLE h ;
public :
virtual int_type overflow( int_type c = EOF ) override {
if( c == EOF ) return c ;
wchar_t sBuf[] = { c, '\0' } ;
DWORD nW ;
WriteConsole( this->h, sBuf, 1, &nW, NULL ) ;
return c ;
}
Buf( void ) {
this->h = GetStdHandle( STD_OUTPUT_HANDLE ) ;
}
} oBuf ;
std::wstreambuf * pOld ;
public:
Out( void ) { this->pOld = std::wcout.rdbuf( &oBuf ) ; }
~Out( void ) { std::wcout.rdbuf( this->pOld ) ; }
} ;

AllocConsoleした後に、Outクラスのインスタンスを作ると、wcoutのバッファがoverflow関数に１文字ずつ渡ってくるらしい。内部では唯一まともに動くWriteConsoleを呼び出す。

Chrome Secure Shellでペーストの方法

Ctrl+VとかAlt+Vとか試してみるもペーストできない。

スクリーン上の文字列を選択すると、画面の真ん中に
Selection Copied
と表示される。

これが表示されるということはクリップボードの値を貼り付けることが出来るはず。

マニュアルを調べてみたら
Ctrl+Shift+V
だって。

Zlib 1.2.8

zlibのバージョンを1.2.8に上げた所、プログラムが動かなくなった。
デバッグすると、初期化(deflateInit)でエラーが返ってきている。
エラーはZ_STREAM_ERROR。

ネットで検索すると、引数の圧縮レベルが間違っているという。
指定している値はZ_DEFAULT_COMPRESSION(-1)で問題ないはず。
試しに0とか6とか試してみてもダメ。

deflate.cの中までデバッグしてみると、渡している構造体(z_stream)のzallocをチェックしている所でエラーになっている。この値がNULLの場合、Z_SOLOのコンパイルスイッチが定義されていると即エラー。
何らかのアロケート関数を渡す必要があるみたい。
Z_SOLOを定義して無ければzcallocという関数が自動で設定される。

ライブラリのサイズが減ったと思ったら、このへんの関数を削る設定がデフォルトになってたみたい。
元々300KBぐらいで、削減して260KBぐらいになってた。
Windowsデスクトップアプリでは大したサイズではないので、zlibのプロジェクトからZ_SOLOを消してコンパイルし直した所、今までと同じ動作に戻った。

サーバ

さくらのVPSってのがあるらしい。

失敗した。
さっきcoreserver１年更新したばっか。
でも、いまさくらのVPSは1Gと2G大人気過ぎで契約が一時停止中なので、
来年はそっちで更新か。

REGZA 42ZG1でPS3の3D設定

３Ｄテレビを買ってから、まともな３Ｄコンテンツを見たことがなかった。
というより、買おうとしたけど見たいものが売ってなかったので、ＧＴ５で軽く３Ｄ体験をして以来３Ｄの機能は使わずじまい。
３Ｄメガネも電池が切れてるし。（電池なしかUSB充電出来る奴がほしい）

年末から年明けにかけて、長い休みがあるから３Ｄのブルーレイでも買ってみようと思いアマゾンで検索してみる。
前に探した時よりかはラインナップは増えていた。
塔の上のラプンツェルを見つけ、買ってみた。

早速見てみようと、ＰＳ３で再生してみると３Ｄに対応したＴＶと再生機器で再生してくれと、失礼な表示が出る。
うちのテレビは３Ｄ対応してるし、ＰＳ３も対応してるからお前の認識を直せと。

何回か再生しなおしても結果は変わらず。
前にＧＴ５で３Ｄモードには普通になっていたし、ＰＣで３Ｄのコンテンツ試した時も問題なかった。
変なチェック入れずに、再生を始めてくれれば、テレビの３Ｄモードをこっちで切り替えすればなんとかなりそうなのに、始めてくれない。

ネットで調べてみると、どうやらＰＳ３がテレビのことを３Ｄテレビと認識してくれないといけないことが判明。
早速ディスプレイ設定で認識させてみようとしたが、これも失敗。
前からこの設定はしてあるから、変わるはずも無い。

しばらく悩んだあと、ふとREGZAの裏設定を変えていることを思い出す。
ＰＣの調子が悪いから、HDMIモードを１から３に変えていた。
その後バージョンアップを繰り返し、おそらくいつの間にか不具合は解消されていたんだろうけど特に不都合もなかったので、設定はそのままにしていた。

ところがこの設定が今回の不都合だったらしく、設定をモード３から初期の１に戻してＰＳ３に認識させてみたら、無事おまえのＴＶは３Ｄ対応だと認識してもらうことができた。
もちろんブルーレイ３Ｄの再生もチェックを抜けて、先に進んだ。

後はＰＣの表示が問題なければＯＫ。
例の再現性１００％の動画で確認したけど大丈夫になっていた。
これを書いている間も問題なかったんで、解決。

でもこの嵌った時間を返して欲しい。

VCでUTF-8 BOMなしファイル作成方法

UTF-8版のLuaで、読み込みできるファイルを作る場合

FILE pFP = NULL ;
_wfopen_s( &pFP, L"FileName", L"w,ccs=UTF-8" ) ;

これでUTF-8のファイルができるけど、BOM（シグネチャ）ありしか
パラメータでは選択できず、BOM（シグネチャ）なしを指定できない。
VisualStudioのエディタでは指定できるのに・・・・。

どうやっても書かれてしまうのは仕方ないので、そのすぐ後でSeekする。

fseek( pFP, 0, SEEK_SET ) ;

これで読めるようになった。

スマートな方法はないのか？
open時にccsの指定はなしか、バイナリにしてしまって、
文字列を自分でUTF-8に変換して出力すれば大丈夫そうな気もするが。。。