[備忘録]ListViewCtrlでLVIS_SELECTEDなアイテムの色を変える方法

ListViewCtrlのアイテムの色を変える方法自体は、カスタムドロー（NM_CUSTOMDRAW）でできることは知っていて実際に使っていました。しかし、LVIS_SELECTEDで選択されたアイテムの色を変える方法、そして、そのListViewCtrlがフォーカスを外れても、同じ選択状態の色で表示する方法がどうしても分からなかったのですが、ようやくその方法が分かりました。それは、、、

カスタムドローのハンドラ内で、CDDS_ITEMPREPAINTイベントが来た時、

  lpCustomDraw->clrTextBk = RGB(x,y,z);

  lpCustomDraw->nmcd.uItemState = CDIS_DEFAULT;

とuItemStateの値を変更しておく、というものです。

この値を変更せずにそのままにしておくと、以降のカスタムドローイベントでデフォルト処理が走ってしまい、LVIS_SELECTEDなアイテム（ハイライトされたアイテム）はデフォルトのハイライト色で描画されてしまっていました。特に、フォーカスを失った時は選択表示でなくなってしまうか、LVS_SHOWSELALWAYSスタイルを付けていても薄いグレー表示になるので見にくかったですが、この方法で完全に選択された表示を維持できるようになりました。

[備忘録]64bit版Cygwin上で、32bitアプリを実行する

昔Cygwin上で使っていたsh-elf向けGCCを動かす必要が出てきたので、再度Cygwinをインストールして動かしてみたところ、エラーで動かない。

sh-elf-gcc.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory

原因：64bit版Cygwinで32bit版実行ファイルを動かそうとしても、必要な32bit版共有ライブラリが見つからない。

対処：Develカテゴリのcygwin32パッケージをインストールすると動くようになるらしいが、今回のケースでは動かなかった。sh-elf-gccがcygintl-2.dllを要求しているが、どうやってもこのファイルをインストールすることができなかった。

回避策：たまたま見つけたcygintl-3.dllをcygintl-2.dllにリネームして使う。推測だが、これらの共有ライブラリは目的とする機能は同じでバージョンのみ違うと思われるので、使える可能性大。もちろん、このdllも32bit版である必要がある。

Cygwinには依存ライブラリを調べられるcygcheckがあるが、64bit版cygcheckは32bitバイナリの依存ライブラリを調べられない。代わりに、Dependency Walkerで調べるとcygintl-2.dllのほか、cygiconv-2.dllとcygwin1.dllを要求していることが判明。これらの32bit版ライブラリは比較的すぐに見つかった。

これらの共有DLLを適当なディレクトリにまとめて置いておく。そして、sh-elf-gccを実行するときには、

PATH=(32bit用DLLを置いたディレクトリ):$PATH sh-elf-gcc

とすることで、sh-elf-gccを使うときだけそのディレクトリにパスを通す。

これで、64bit用Cygwinでも、32bit用sh-elf-gccが動くようになった。

パサートヴァリアント2019年年間燃費

2019年の１年間で合計45252km走り、年間の平均燃費は19.74kmでした。

DSGの不安も完全に払拭されたので、アクセルは結構踏んでます。加速が必要なときはSモードを使う方が、ダウンサイジングターボ＋DCTの組み合わせには合っていると感じます。と言っても、先行車が居ることがほとんどなので、Dモードでゆっくり加速になることが多いです。
高速道路では走行車線で85km/hの巡航速度を保って大型車と同じくらいのスピードで走ることが多いので、燃費を稼ぐのは容易ですね。巡航速度をできるだけ長く保つことと、巡航速度まで如何に効率的に加速するかが重要と思われます。個人的にはふんわり加速すれば燃費に良いとは思えないです。アクセルをグイグイ踏んでも平均燃費への影響は小さいようです。「高速道路or郊外道路中心の乗り方で」という条件付きですが。

[備忘録]GitBacketのバージョンアップ顛末

GitBucketのバージョンアップに苦労した（というか、やり方が分からなかった）ので、その記録。

もとのバージョンはGitBucket 3.7、これを4.32.0に上げようと思いました。理由は、最近「git cloneが猛烈に遅い病」にかかっていることが判明して色々と調べたところ、どうもGitBucket自体が怪しいということになり、アップデートする決意をしました。
git cloneが遅くなる現象は、ネットでいくつか質問サイトに上がっていました。大体の回答は、大きなファイルをpushしたんだろう、とか、git fsck/git gcしたりしてリポジトリを整理したらというアドバイスが多かったように思いますが、スッキリそれで直ったという回答はあまり無かったように思います。実際、fsck/gcで改善しなかったし、大きなファイルもpushしていない、リポジトリサイズもそんなに大きくないので、当てはまる感じはしなかったです。

結局、

• どのクライアントからgit cloneしても猛烈に遅いこと
• GitBucketがホストしているすべてのリポジトリで同様であること
• GitBucketを通さずにgitサーバPC上のベアリポジトリを直接ファイルシステムからcloneすると問題ないこと

など総合的に考えて、リポジトリの破損が原因ではなく、GitBucketがトラブっているものと推測しました。


で、アップデートの方法ですが、GitBucketを停止して、gitbucket.warファイルを入れ替えれば済むものと思っていたけれど甘かった。3.x系から4.x系に上げるには、3.x系の最終版である3.14へのバージョンアップを経由してから、4.0に上げないといけないらしいということは検索で早めに調べがついていました。


3.7→3.14への移行方法：

ここでは、かなりの試行錯誤が必要でした。結果的にうまく言った方法は次のようなものでした。

1. 使っていた3.7のデータベースを、H2にてSQLファイルにエクスポート（バックアップ）
2. まっさらの状態でGitBucket 3.14を起動して、H2 ConsoleからエクスポートしたSQLファイルを実行して読み込み。
3. 上記２で生成されたdata.mv.dbファイルに入れ替えてから、再度3.14を起動。

これで、3.7のときのユーザー設定やリポジトリ設定が3.14に移行できました。

1.のエクスポートは、GitBucket 3.7のWEB-UIが起動しなかったので、たけぞうさんの指示通り、直接データベースから引き抜きました。

java -cp h2-1.4.190.jar org.h2.tools.Script -url jdbc:h2:~/.gitbucket/data -user sa -password sa -script backup.sql

なお、h2-1.4.xxxx.jarファイルは、tmpディレクトリにあるものを使いました。tmpディレクトリは c:\Users\(ユーザー名)\.gitbucket\ にあるもので、gitbucket.warを起動したときに展開される中身（jarライブラリ）のようです。

また、2.のSQLファイル実行は、GitBucket内のH2 Consoleから、次のように入力しました。

RUNSCRIPT FROM 'backup.sql'

SQLの結果は、デフォルトの接続先DBである、~/test.mv.dbに出力されていました。

3.14→4.0への移行方法：

これは、単純にgitbucket.warファイルの入れ替えだけで、データベースをうまくアップグレードしてくれました。要は、GitBucketを停止させてから、gitbucket.warファイルを更新し、再起動するだけです。

4.0→4.32への移行方法：

上と同じように、gitbucket.warファイルを入れ替えるだけで良かったのですが、いきなりバージョンを上げるとエラーが出ることが多かったです。4.0→4.1→4.2→・・・とチマチマ上げていかないと、起動時にエラーが出ました。そして、エラーが出るとデータベース

ファイルが更新されているのか、元のバージョンに戻してもエラーが出続けることがありました。つまり、うまくいったらデータベースのバックアップを取っておかないと、最初からやり直しになることがありました。

とはいえ、すべてのリリースバージョンを１つ１つ実行しないといけないわけでも無いようです。２～３つ飛ばしても、エラーは出ずにうまくデータベースを更新する時もありました。

ここまで細かくきざむ必要はなかったかも知れませんが、覚えている範囲では次のようなバージョンステップを踏みました。

4.0→4.1→4.2.1→4.3→4.5→4.6→4.7.1→4.8→4.9→4.10→4.11→4.12.1→4.13→4.14.1→4.15.0→4.19.3→4.20.0→4.25.0→4.26.0→4.27.0→4.28.0→4.29.0→4.30.0→4.31.0→4.32.0

これで、3.7のときの各種設定のまま、4.32.0に移行できました。ここまで約１日半くらいかかっていました。

ようやく、元の問題である「git clone超スロー病」が解決したかどうか試すことができる段階になったのですが、時間切れとなりましたので、それはまた別の日に。

パサートヴァリアントのDSGリコール来た！

と思ったら、対象外だった。前期モデルのB7が対象のようで、B8はもうリコール来ないのかな。不具合や故障が無いのはいい事なのだけど、13万kmくらい走ったので、そろそろリコールで新品の交換されたら嬉しいかなとちょっと思ってしまった。どちらにしろ、リコールが出ている燃料ポンプはいずれ新品交換の予定。

ところで、先日バッテリーが突然死しました。過去に乗っていた車でも突然死は経験しているので、十分に注意していたはずだけれど、全く前兆がありませんでした。

まず、始動時のクランキングですが、前日まで特に変化は感じませんでした。かかりにくいということは一度もなかったです。前日帰宅したときのバッテリー電圧は12.0Vくらいだったと記憶しています（電源ソケットで常時モニターしている）。また、パサートはアイドリングストップ付きなので、アイストが利きにくくなったら弱っているサインなんだろうなと考えていたのですが、前日もアイストは動作していました。なのでまだ大丈夫なんだろうと思っていましたが、アイストの具合は当てにならないということですね。
また、電圧モニターでエンジン動作時は13.5～14.5Vくらいありましたし（＝オルタネータは大丈夫そう）、アイスト時も何とか12V台をキープしていたので、まだ行けるだろうと。アイスト時やエンジンオフ時に12.0Vを大きく割り込んできたら、交換するつもりでした。しかし、、、、

翌朝、エンジンスタートボタンを押したつもりが何も起きませんでした。押しそこねた？と思ってやり直すと、スタータが回るものの明らかに弱いし苦しそうな回り方です。何度かがやり直してエンジンは掛かり、そのあとはとりあえず普通に走っていました。エンジン始動後はモニター電圧も13.5Vくらいで問題なしでした。
その後、GSでガソリンを入れてからエンジンをかけ直すと、やはりスターターはかなり苦しそうに回るのみ。ガソリンスタンドなので万一かからなくても何とかしてもらえると思っていましたが、ここでも何とかかかり帰宅できました。その後、家事を少ししてから出勤するのにエンジンスタートさせたところ、今回は一発でかかりました。なので、少し不安でしたが、そのまま出勤することしました。もちろん、アイストは使いません。

仕事を終えて夕方、もしエンジンがかからなければ最悪同僚の車に繋がせてもらってエンジンだけはかけられるつもりでいました。エンジンをかける前にまずはACCだけオンにしてみました。電圧モニターは11.3Vくらいでした、昨晩まで12.0Vあったのに、ものすごい電圧の降下です。ここまで、急に電圧が下がるなんて・・・。スタータは今朝より更に弱々しいものの何とかエンジンは始動しましたので、このままエンジンを切らずに帰ることにしました。アイストはOFFにしてエンジンさえかかっていれば、大丈夫でした。

で、翌日。朝、もう一度チェックしてみようとロックを解除するも、リレーの音自体弱かったです。「カチャ」ではなく、「カッ、、、、チャ、、、、」みたいな感じで。しかもなんと、ドアミラーすら開きません。エンジンをかけずにACCオンにして電圧を確認してみると、あれまぁ8.7Vしかありません。さすがに、この状態ではナビが起動しませんし、MFIにもエラーが連発。さすがに電装品も動かないレベルでした。しかし、電圧降下の速度がすごいですね、最近のバッテリーは。ギリギリまで使えるように設計されているのでしょうか。

もうダメですね、これは。気がかりなのは、こんなに急に電圧が低下するのは、もしかして電装品のどれかの故障で電流リークしている可能性があることです。そうであれば、バッテリーを交換したところでまた起きたでしょうね。
とりあえず、前日に注文しておいたBLE-70-L3が届く予定だったので、その日会社は休みにしました。到着後、すぐに交換、元のように一発でかかりました。やはり、バッテリー自体の寿命だったんでしょう。もう３年半くらい経っていますし。

事前に調べていたとおり、バッテリー交換後はいろいろとエラーが報告されましたが、２～３００メートル走って一度エンジンを掛け直したら、エラーは全部消えました。ラジオのプリセットも残っていました。消えたのはトリップメータだけです。これくらいなら、敢えてバッテリーバックアップする必要はありませんね。
エンジンや変速機の学習データが消えるなんて話も耳にしますが、都市伝説かな？と。そんな学習データがあるかどうかは疑問だし、正直なところ、あったとしても大事なデータならすぐに消える揮発性メモリに置くはずがありません。実際、交換後のフィーリングは特に変わりありませんでした。

今回の教訓。

• アイストが機能する・しないは、バッテリー寿命の指標にならない。
• バッテリー電圧12.0Vは安心できない。これは危険水域と思え。

ちなみに、交換したバッテリーのアイスト時／エンジンOFF時の電圧は12.4Vくらいでした。ただし、これはACC＝ON時に電源ソケット部分で測った電圧です。ACC=OFFでバッテリー端子を直接テスターで測ると12.8Vくらいはありました。

パサートヴァリアント(B8)の年間燃費記録

昨年もパサート君はよく働いてくれました。2018年の１年間（正確には、2017年12月26日～2018年12月28日）での総走行距離は、46911.8kmでした。
この間の総給油量は2458.0Lだったので、年平均では19.09Km/Lでした。車検中の代車での走行分・給油分は引いてあります。純粋にパサートで走った分だけの集計です。

月別では次のようになりました。

９月、10月くらいに燃費が高めになっているのは、気温が下がってエアコンを使わなくなったことと、高速道路でのACCの設定を80Km/hと低めに設定したことが影響していると思います。ACC=90Km/hとは明らかに燃費差を感じます。しかし、80Km/L設定では走行車線を走っていても大型車がどんどん迫ってきて、すごい近距離から煽り気味に抜かしていくのでちょっと怖いです。やはり、流れに乗って運転した方が良さそうです。

総走行距離も10万kmを超えてきて、さすがに経年変化を感じます。例えば、アイドリングですが、乗り始めの頃はほとんどエンジン音や振動を感じず、「本当にエンジンがかかっているの？」とタコメータを目で確認することがありました（アイドリングストップは好きではないので、基本的に切っています）。しかし、最近ではアイドリング中でもエンジン音は聞こえますし、小さな振動も感じます。もっとも、ラジオでもつけているとエンジン音は聞こえませんし、ごく小さい音＆振動なのでうるさいというほどではありませんが、10万km走行後ならこの程度の劣化は仕方ありませんね。

そして、購入当初最も懸念していたDSGの設計不良（？）問題ですが、個人的にはもう完全に改善されたと感じています。発進や変速時のフィーリングの変化は不安感はまったくなく、これからも故障なく頑張ってくれそうです。ただ、正直なところ、DSGのフィーリングより、CVTのフィーリングの方が好きですね。最近のCVTはラバーバンド感を抑えているそうなので、そういうクルマも試してみたいところです。が、次回クルマを買い換える頃にはモーター駆動車（完全なEVか、シリーズハイブリッド）になるだろうなと思います。

CooCa（クーカ）使えない

すき家でポイント９倍の19日に限って、通信障害のためCooCaが使えないってのは、意図的ではないだろうか？
最近はクーポンもしょぼいし、他の店の乗り換えようかなあ。

Windows 10が"BAD_SYSTEM_CONFIG_INFO"で起動しなくなった

ネットで調べると・・・

• このBSODコード(0x74)は、主にレジストリの破損が原因らしい
• [システムドライブ]:\Windows\System32\config\にあるDEFAULT/SAM/SECURITY/SOFTWARE/SYSTEMファイルを修復すれば良いらしい
• Windows7までは、[システムドライブ]:\Windows\System32\config\RegBack\ディレクトリに正常なときのこれらのファイルのコピーがおいてあったらしいが、Windows10ではファイルこそ存在すれどすべてのファイルサイズが０であった
• 以前のWindowsでは、ブートメニューから「前回正常起動時の構成」で起動するようにすれば、とりあえず起動できるようになるらしい。

ということが分かった。ということは、Windows10ではこれらのファイルが正常な状態であったときのコピーは存在しないということなのか・・・。

そういえば、つい先日ベアメタル回復用にシステムバックアップを採っていたのでした。そこから、これらのファイルを取り出してコピーすればいい。

ということで、まずは回復環境で起動する。幸い、Windows自動修復が勝手に働いてくれて（しかし、自動修復自体は実際には何も解決してくれないのだが）、その後詳細修復のメニューが出たので、コマンドプロンプトを起動。もし、F8連打をしても回復環境のコマンドプロンプトが出せない場合は、起動ディスクやインストールディスクから起動するのも手だろう。

コマンドプロンプトが起動したら、diskpartでWindowsImageBackupディレクトリにあるシステムドライブのVHDファイルをアタッチする。できるだけ直近のバックアップイメージを選ぶ。

select vdisk file="VHDファイルのフルパス"
attach vdisk

アタッチしたVHDディスクイメージからWindowsシステムが入ったパーティションを探してselect。

select partition パーティション番号

更に、そのパーティションにドライブ名を割り当てる。

assign letter=任意のドライブレター

これで、正常時のWindowsシステムにアクセスできるようになったので、前述の５つのファイルを破損しているであろうWindowsシステムの所定のディレクトリにコピーする。

そして、コマンドプロンプトを閉じて再起動。これで、Windowsが起動するようになった。

すき家の割引がショボいことに気づいた件

すき家のクーポンなどでの割引が、他のファストフード系外食店に比べてショボいことに今ごろ気付きました。

以前から知っていたのですが、最近讃岐製麺のアプリを入れました。すると、クーポンがじゃんじゃん届くではないですか！しかも、入会直後ということもあってか、釜揚げうどん150円引きとか鶏天サービスとか、特典が凄いので、ついつい行ってしまいます。

一方、すき家。メールマガジンのクーポンで50円引き。これだけ。最近出たsukipassもセコい感じが否めない。牛丼が毎回70円引きになるのはいいとして、まずsukipassを200円で買わないといけない。更にクーポンとの併用は不可なのです。
ということは、消費者側の勘定では-200円の損をしてから始まることになる。sukipassを使えば、クーポンで食べるよりも20円得するのだけれど、結局最初の-200円の損金があるので、10回牛丼を食べてやっとクーポンを使ったのと同じで、それ以降やっとクーポンよりも20円ずつ得する計算になります。しかも、sukipassの有効期間は最大でも１ヶ月しか無い。１ヶ月で10回も食べに行きますか？牛丼。
しかも、sukipassの販売開始～利用可能期間が決まっているので、気がつくと販売開始から１週間過ぎてる！ということもあります。その場合残りの３週間で10回食べないとクーポンと比べて、元が取れない計算になります。できれば有効期間は３ヶ月、最低でも２ヶ月くらい欲しいところです。

別に、すき家自体をディスりたい訳ではありません。個人的には牛丼店の中では一番美味しいと思うし好きですから、むしろ頑張ってもらいたい。クーポンあるからもう一回行こうかな、クーポン使わないともったいない、そう思わせるようなサービスに期待したいところです。

パナソニックのエアコンで、またまたエラー発生！

こちらでパナソニックのエアコンのエラーH51の件を書きましたが、今年はエラーH56が出ました。

またもや、web検索という便利なもので調べてみますと出るわ出るわ。H56はルーバーの動作異常のようですね。確かに、エアコンを停止してもルーバーが閉まらないですし、上下に向きを変えようとしても動かないですね。左右は動いているようですが。

ダメ元で、エラーH51のときのように本体リセットと電源プラグの抜き差しをしてみました。すると、、、、、、「ダメ元」の意味どおり、ダメでした。
さて、ルーバーが動かない原因は、機械的な損傷なのか、電気的な不具合なのか。ネットでは機種が少し違いますが、ルーバーを動かすモーターの駆動力を伝える部分のプラスチックが破損するケースが多少起きているようですね。いずれにせよ、分解して異常箇所を特定しなければと考えていました。どこのネジを外せば正面のカバーが取れるのかと・・・。

ルーバーの動作不良は２週間ほど続いていたのですが、先日家に帰ってみるとルーバーが閉じていました。家族はルーバーの故障など気にせず使っていたようですが、そのうち勝手に直ったようです。そんなバカな・・・。

そろそろ10年選手ですから、潮時なのかと思っていました。同時に、10数万円も出して買ったのに10年くらいで買い替えとは納得できないなとも思っていました。
なので、エアコンが冷えないという故障なら仕方ないですが、ルーバーが上下に動かないくらいなら直さずとも使えるだろうということで、吹き出し方向は固定でもいいので使い続けるつもりでいました。もし直せそうであれば、エアコンをあまり使わない時期に自力で直そうと。それこそ直そうとして余計に壊れたとしてもダメ元のつもりだったのですが。

10年とは言わず、せめて15年くらいは頑張ってもらいたいです。