2012年7月30日月曜日

Windows8 Metroで起こったこと

仕事でWindows8RPを使ってて起こったこと.

まず一つ.
Windows Metro画面からMetro用IEが消えた問題.
原因は簡単.規定ブラウザをIE以外に設定したから.
何も考えずにいつもどおりFireFoxにしてしまっていた.
規定ブラウザはIEにしていないとMetro用IE使わせないぞというMSのお心配り.
イラネーヨ

もう一つ.
Metro用各アプリのテキストボックスで日本語が入力できなくなる問題.
これも原因は同じようなもの.
IMEをMS-IME以外に設定したから.
Google IME使おうとするとMetroでは英字しか入力できん.

これはRTMには本当にどないかしてほしい.
開発者としてでなくユーザーとしての願いだ.

Metroとデスクトップは完全分断するんじゃなかったのかよ.
Metro用ブラウザ(サンドボックス外のアクセス権限)は他のブラウザメーカにも明け渡すとは聞いたけど
IMEはこのままじゃダメでしょ.ATOKとか使ってる人多いでしょうに.
少なくともMetroの時は勝手にMS-IMEに切り替わるとか(理想は設定IMEをフルで利用できることだけどね)
そういうことしないと自らMetroを否定することになるよ.

Macみたいなガラパゴスと違ってWindowsはサードパーティあってこそなんだから.
自社囲い込みは自殺行為.

2012年7月25日水曜日

【Windows Metro プログラミング】ページ遷移で例外落ち(ヌルポ)

Windows Metro Styleのプログラミングを勉強していて
激しく躓いたところが一点あったので情報共有.
ちなみに環境はWindows8RPとVisualStudio Professional2012RC.
というかWPF勉強済みなら常識なのかもしれないけれど.
初めてのWPFなので勘弁して下さい.

今Metro Styleアプリの勉強で数少ない情報源である
Microsoft公式のデベロッパーセンター
そこのサンプルで勉強をしていたのだけど,
パート3 ブログリーダーを作成する
http://msdn.microsoft.com/ja-jp/library/windows/apps/br211380.aspx
ここで躓いた.

具体的には
ページとナビゲーションの追加
にあるページ遷移なんだけど,
ページ遷移は

this.Frame.Navigate(typeof(SplitPage), e.ClickedItem);
でできるそうな.
ふむふむなーる
と思いながらタイピング,言われたとおりに実行を行い,
ページ遷移させようとすると
LayoutAwarePage.csという自動生成コードにある
onNavigatedFromメソッド中の
frameState[_pageKey] = pageState; ここから
ArgumentNullExceptionという例外が帰ってくる.
どうやら配列のキー_pageKeyがnullらしい.
どこがおかしいのかとそのページをさんざっぱら読みまくっても答えは落ちてなかった.
ググってみるとMSDNのフォーラムで同様の質問があった.
http://social.msdn.microsoft.com/Forums/en/winappswithcsharp/thread/a2611a92-4d2e-4186-9118-cde94346c756
なんかCP版まではうまく動いてたのにRP版でページ切り替えができなくなったとか書いてある.

解決法
遷移元のページ(このサンプルだとItemsPage.xaml.cs)
のOnNavigatedToメソッドの一番最初に
base.OnNavigatedTo (e);
を追加してやる.それだけ.
明示的にスーパークラスのメソッドを呼び出さないといけないようだ.
デベロッパーセンターに書いてないぞ…
どうやらスーパークラスであるLayoutAwarePage.csに遷移元を教えておかないと遷移行為自体ができないようになってるらしい.

つまり
ItemsPage.xaml.cs の OnNavigatedToメソッドはこうなる

        protected override async void OnNavigatedTo (NavigationEventArgs e) {
            base.OnNavigatedTo (e);
            FeedDataSource feedDataSource = (FeedDataSource)App.Current.Resources["feedDataSource"];
            if (feedDataSource != null) {
                if (feedDataSource.Feeds.Count == 0) {
                    await feedDataSource.GetFeedsAsync ();
                }
                this.DefaultViewModel["Items"] = feedDataSource.Feeds;
            }
        }

これでItemView_ItemClickメソッドで呼び出している
SplitPageへ遷移することができるようになった.
遷移で失敗しているからこのItemView_ItemClickメソッドに何かが足りないのかと思っていた…

レイアウト済みページを追加した場合に起こりうるので注意.

どうでもいいけどC#のスーパークラス呼び出しってbaseなんだね.
superじゃないんだ.Javaに毒されすぎかな.

2012年7月8日日曜日

次世代GK妄想

と思う

なるほど,GK-3は確かに使いやすい.
GKシリーズ最新のピックアップである.

だが,今考えると目的の割に回路が古過ぎやしないか.
回路はピックアップ⇒バッファー(OPアンプ)⇒アウトプット
回路がアナログであるが故に多大な不便を感じる部分がある.

無線化できねえ

GK-3の発売が2004年2月らしい.
もう8年GK-3で戦っているようだ.
もはや技術が流行に対してアウトオブデートである.

バンドマンじゃないから言うのもためらわれるが
ふにゃふにゃした公式ケーブルしかろくに手に入らないんだから
これを現場で使うのは厳しいと思う.
ケーブルに縛られるし断線が怖い.

アウトプットが全ての音楽の世界とはいえ,
構成要因がディジタルである以上ムーアの法則が成り立つわけで
8年も進化しないのはどうかと思う.
無線化技術なんて今安いだろ.

サイズにしろ802.11nのUSBドングルだって今や小指の先サイズ.
天下のRolandさんがちょっと発揮すれば実装できるはず.

ただ,問題は後方互換.
あ.俺のGR-55は使えなくなるのねとか
そういうやつ.

うまいことアダプタを作って後方互換に対応できればいいけど,
できなくても俺は問題ですらないと思う.
付け替えたらいいだけだもの.
次世代GK.Rolandルールに従うなら4をとばしてGK-5かな
今みたいにアナログ出力じゃなくて後方互換を切ってディジタルでもいいと思うんだ.
んで,デフォルトはワイヤードだけどオプションでワイヤレスユニットに対応できるようになっていいと思うんだ.

こーんなことを作業しながら思ってた.

GK移植作業のとちゅうですが

ターがぶっ壊れたので

さすがに13pinを空中で配線するのはつらい.
っつーかあの密集した13pinを配線する時点で辛い.
使ってるうちに,ケーブルを抜き差ししているうちに溶接部分が断線してしまう.
というわけで,ギターの修理をしていました.
DIN13ピンと舟形ジャックの処理を
http://noizy-radio.blogspot.jp/2012/04/blog-post.html
こんな風にしていたんだけど
舟形ジャックからコネクタが微妙にずれるわけ.

これじゃいかんということで完全固定の道へ奔走.
具体的には使ったものはセメダインスーパーX2とホットボンド.

舟形ジャックとDINコネクタの接触面にセメダイン塗布して接着.
セメダインの定着には時間が掛かるから仮固定兼務でホットボンド.
2日も置いてると手では動かないぐらい固定できた.

それから,断線対策として
まず13ピン全てをハンダ付けしなおし.
乱視には辛い作業である(´・ω・`)
半田鏝の鏝先ほそいやつが欲しい.

それから,半田後の処理.
これまでは絶縁テープを巻いてたんだけど
あんまり意味が無さそうなので別の方法を考える.

本当は熱収縮チューブで固定したかったんだけど
手元にある熱収縮チューブが複数本まとめる用のやつで
1本だとスカスカで意味を成さないのでこれは諦め.
結果,ホットボンドを垂れ流した.
なんかやってはいけないことをした感が半端無いのだが
トラブルが起こった場合に修復することができなさそうな気もしなくもないのだが
まぁそれでも今は問題ないようなのでよしとしてみる.

これで今は安定期に入った.
問題というとピックアップ部分が両面テープで貼ってるせいで浮いてくる.
螺子で固定はしたくないのだよ.

本当は別のことを書きたくて↑は前置きのつもりだったんだけど
意外に長くなってしまったので分けよう.
一旦ポスト