2012年2月18日土曜日

Windows7 ネットワークの高速化

Windows7 64bitのネットワークアクセスが異常に遅い。

インターネットでは気がつかなかったが、ネットワーク先にあるドライブ、WindowsHomeServer(WHS)やネットワーク共有ドライブへのアクセスが今までより10倍どころかもっともっと落ちている感じ。

調べてみると情報あり。Mac mini 2011/2014にWindows7を入れている場合、以下の通りに設定する。
  1. コントロールパネル~ネットワークと共有センター~(左側から)アダプターの設定の変更
  2. ローカルエリア接続の右クリックメニュー~プロパティ
  3. 構成~詳細設定
  4. TCP/UDP Checksum Offload(IPv6)をDisable
  5. Large Send Offload v2(IPv6)をDisable
  6. [OK]
EpsonDirect NP25Sの場合
  4. TCPチェックサムオフロード(IPv6)を無効
  5. 一括送信オフロードv2(IPv6)を無効
 
これで速度がほぼ戻った感じ。IPv6プロトコル自体は外してない。
本来はこれらの機能はEnableにするとネットワークカード上で処理されるようになるのでCPU処理が減って速くなるはずなんだがなぁ。

さらに調べると、ネットワークのTCPウィンドウサイズの自動調整機能を高速回線用にするとよいという情報もあり。
コマンドプロンプトを管理者権限で起動してから、下記コマンドを実行する。
(「プログラムとファイルの検索」に次のコマンドを入れて実行した場合、管理者権限で弾かれる。)

netsh interface tcp set global autotuninglevel=highlyrestricted

元に戻す場合は最後をnormalにする。(上記設定を変更するときは、基本的にネットワーク越しのファイルアクセスをしていない状態で行うこと。していると、そのアクセスに失敗することがある。特にVNCでの遠隔設定時に注意。)

さらに速くなったような感じ。特にインターネット接続が劇的に速くなった。
他にもいろんな設定を変えている人が見受けられるが、うちの場合はこれでOKとしておく。


2012/04/11追記
ファイルコピーを高速化するフリーウエア「TeraCopy」は、ネットワーク越しコピーでは無効どころか、場合によってはかえって遅くなるようである。あまりに遅い場合は、それを一時的に無効にするか、他のファイルコピープログラムを試してみると良いかもしれない。
「SotaさんのBackupが意外に早い」とも書いておこう。

2013/02/10変更
WindowsHomeServer相手のコピーならBackupが結構早い。
Macをサーバーにしている場合はTeraCopyの方が速い。
Backupは、Mac相手のコピー時に限り、ファイル名の扱いに問題があるらしく、コピーに失敗することが多い。日本語を含むフォルダおよびファイル名が怪しい(でも全てではない)。
なので、Mac相手は基本TeraCopy。
ただし、TeraCopyでのコピー中にMacとの接続が切れることが多い。コピー動作が止まったらほぼ確実。その場合、一旦中止して、再度やり直し。
2以上のコピーを同時に走らせると切れる確率が上昇するのでやらないこと。
なぜだろう?

2013/3/23変更
Backupはネットワーク越しだと異常に遅くなると判明。

→遅くなるのはどうやらWindows7側の問題のような感じ。他のコピーツールでも同様な現象が発生する。
→2つ(以上)の別ネットワークドライブに同時にコピーするとものすごく高速化されるという変な現象も起きる(Backupは多重起動可能)。でも、Mac相手ではコピーに失敗しまくるようになるのでやってはいけない。

2012年2月14日火曜日

Windows7 32ビット版で不具合を起こすソフト

ついでなので、Windows7の32ビット版で不具合を起こすソフトについても少し。
XPでは動いてたけど、というもの。

・Zwei!!(Falcom)
全くだめ。ついでに言えば、仮想XPモードでも完全ではない。
Zwei2は全く問題ない。

・PanoramaMaker4
写真をつなぎ合わせてパノラマ写真にする物。
対応版は出ているが有償だし、MicrosoftのICEという無料アプリでも同じことが出来るので、今はそちらを使っている。
→最近はPhotoShopElementsに移行。

・Logicoolウェッブカムソフトウエア
USBカメラの制御ソフト。カメラ自身が認識されない。
USBカメラデバイスの仕様が策定される以前に発売された古いUSBカメラは軒並みアウトかもしれない。

・inksaver2
インクジェットプリンターのインク量を削減してコストダウンを計るツール。
対応版はinksaver4(以降)。

・MFC-6490CN付属CDのドライバー
ブラザーの複合機。メーカーサイトに有る最新版は対応されている。


最初はもっとたくさん動かなくなる物が出ると思ったけど、純然たるソフト物もデバイス関係も意外に動く物が多くて驚いた。
というか、まともな会社の製品は全て対応版ドライバーが出ている。

ただ、My Documentをはじめ主要ディレクトリの位置(名前?)が変わったことには大弱りで、その対応にどえらく時間がかかった。
うちではMSが用意してた移行ツールではうまく移行できなくて、自前でファイルコピーをしたから。
というか、MSの移行ツールは、よほど単純な環境以外では成功しないと思うので、使わないほうがいいと思う。
時間の無駄。

あと、先にアンインストールしてライセンスなどを解放しないといけないアプリをしてなくて困った。今からXP→7移行する人は要注意。

・AdobeAcrobat9(readerではない)
・LookFONT ver2
・らくらくファイリング9
・ウイルスセキュリティーZERO
・iTunes(PCの承認解除と共有解除。意外に盲点)

1台のPC上でXP→7移行は絶対に「やめた方がいい」と思う。ものごっつう苦労するから。
うちはWindowsHomeServerがあるから、失敗したと思ったら復旧させてやり直しを何度もやったけど、普通は無理だから。

経験者からの忠告。

Bluetoothファイル共有 on Fusion

Fusion上のWindowsでBluetoothを使ったファイルの送受信する場合の問題点。

Fusion上Windows(送信)→別Windows(受信)の転送は問題ない。

ところが、逆は出来ない。

MacOSが先に受信してしまうからである。
(Macでファイルを受信するには「共有」でBluetoothの共有をONにしておく必要がある。)
Macで受信して共有フォルダ経由でWindowsに渡してもいいけど、一手間増える。

DVDドライブのように、Fusion起動中はWindowsに制御権を渡せばいいのに。
(Windows起動中はMacからはDVDドライブがアクセスできなくなっている。)

これが出来れば、LAN接続なしでもファイルの送受信が楽に出来ると思ったんだがなぁ。

遅いけど。

2012年2月11日土曜日

Windows7 BootCampとFusion4の違い

で、多大な苦労の結果BootCampによるWindows7環境も構築できたわけだが、
Fusion4上との違いが気になるかもしれない。

まず速度差。
ほぼ同一のCPU/グラフィック性能を持つと思うiMac(Mid2011)上のFusion4とMac mini(Mid2011)上のBootCampでの対比。
Windows7のパフォーマンス評価の結果は以下の通り。

コンポーネントBootCamp Fusion4 
プロセッサ7.04.7
メモリ(RAM)7.45.5
グラフィックス5.76.0
ゲーム用グラフィックス6.56.0
プライマリハードディスク 5.76.6

CPUとRAMの速度には当然大きな開きがあるが、他は同等もしくはFusion4の方が上回っている。
HDDの差はiMacとMac miniのハード差が出ている。
iMacは3.5インチHDD、Mac miniは2.5インチHDDで、そもそも速度差がかなりある。

Mac mini上のWindowsは、電源ONからの起動も、プログラムの起動もかなり遅い。
HDDの遅さが直撃している感じ。
速度をできるだけカバーするため、RAMDISKやディスクキャッシュソフト(うちで使っているのはIO-DATAのマッハドライブ)を入れた。特にディスクキャッシュはけちらず出来るだけ大きく確保した方が良い。2回目以降のアクセス速度がRAMDISKに近い速度まで劇的に上がる。
ここで8GBにしたメモリが活きている。

ただ、再起動時の速度差は圧倒的で、Fusion4はWindowsを再起動しても
本当に一瞬で立ち上がってくるが、BootCampでは数分かかる。
FusionではMacOSのメモリ上にWindowsがキャッシュされているためである。
SSDとはこういう物だろうか、と一瞬思ったが、まだ高くて今の私には手が出ない。
(誰かください^_^;。)

起動してしまえば、やはりBootCampでの方が速い。
ハード性能をフルに活かせる。
2画面構成なども楽に出来る。

でも、WindowsとMac間のデータのやりとりがあるならFusion4の方が楽なのは言うまでもない。
画面以外のハードウエアも多くはそのまま使うことが出来る。
Mac上からWindowsのアプリを、見かけ上とはいえそのまま起動できるのも便利だ。
従って、双方を有効に使い分ければいいと思う。

・・・

FusionではBootCamp下にあるWindowsをMac上から起動できるようにすることも出来る。
Fusion上に別に仮想Windows環境を作るには、Windowsがもう1ライセンス別に必要となるが、BootCamp環境を起動する分にはそれは必要ない。

が、これはあまりおすすめできない。
簡単に言えば、BootCamp Windowsでフル性能を活かす設定にしていると、Fusion上では不具合が出るからである。

それは単に速度差だけではなく、以下のような問題を起こす。
  • メモリ不足になることがある。特にキャッシュディスクやRAMディスクを設定していると出やすい。そうなるとスワップが起こりまくって、ほとんど実用にならない速度にまで落ちる。
  • 画面解像度が変わるし2画面にも出来ない。1画面に納めようとするのでデスクトップがおかしくなる。
  • さらに悪いことに、Fusion上で設定を変えてしまうとBootCamp上にも影響してしまう。Fusion上で起動したそれは、BootCamp上のWindowsそのものだからである(ややこしい)。
このほか、BootCamp WindowsをFusion上で実行したときはリジューム機能が使えないという制約もある。
これは取説に書いてある。

ということで、BootCampとFusionのどちらを選ぶかは、Windowsに求めることによって決まると言うことである。
両立はあまり考えない方がいい。
私の場合は、「安価なWindows機」ということで今回選んだので、FusionではなくBootCampを選んだのである。


・・・2012/03/29、04/12追記

一部ソフトはFusion上Windowsでは正常動作しないことが判明。
手元にある物で確認したのは以下の通り。

COREL WinDVD7/9/11仮想PC上での動作を禁止している。これが動けばMac上でCPRMのかかったDVD-RAMが再生できるのに。
一太郎2011上の詠太行最後の1文字の発声が途中で切れてしまう

なお、完全なWindows機になるBootCamp上ではどちらも正常動作する。

Windows7 64ビット版で不具合を起こすソフト(一部解決策あり)

今回導入したのはWindows7 Proの64bit版であるが、やはりというか想像通り、一部に
不具合を起こすソフトがあった。うちでわかったものを列記しておく。
すべて元はXP対応の物で、32bitのWindows7では問題なかった物である。

  • B's FileGuard/DiskGuard(v1.06)
    これが一番やっかいだった。Windowsの起動すら出来なくなる(2つのうちどちらがぶつかっているかまでは未確認)。
    対応版も発売されてない。フリーでファイルの暗号化ツールはあるので、それを使うことになる。
    アタッシェケース」がおすすめ。
  • IO-DATA USB2-NFC
    nanacoやICOCCAカードを読むためのカードリーダー。インストールできない。
    当然、これの動作を前提としているアプリは動かすことが出来なくなる。
    EdyViewer v2.1(v3.0はこのカードリーダー非対応)とか精算快速とか。
  • ROXIO EASY CREATOR7
    インストール不可。CD/DVD作成系アプリが動かないのはちょいとつらい。
    最新版は出てるけどちょいと高い(1.5万)。
  • Core Temp v0.99.8
    起動せず。最新版(v1.0 RC3以降)にすることでOK。
  • あふw x64 v1.53
設定でフォントサイズ変更が効かない。.iniを直接書き換えて対応。
64bit対応不足と言うより、単にバグな気もする。

→仕様通りだそうですm(_ _)m。
64ビット版ではアーカイブ関係のDLLも64ビット版を入れないと展開できないのかも知れず。
うちでは↓理由によりExplzhは32ビット版なのでLZHが展開できない状態。
ということで、現在は32ビット版を利用中。機能差なしなので問題なし。


  • ExpLzh 64ビット版
    別途7-ZIP64/TAR64.DLLを入れろと言ってくるが、指定されたwindows\system32にコピーしても、なぜかsyswow64に入ってしまう。OSが勝手に入れ替えているらしい。回避策が見つけられなかったので、32bit版を入れた。機能差なしなので問題なし。
    →エクスプローラーなどによるファイルのコピーではうまくいかず、ファイルをいったんクリップボードにコピーしてペーストするとうまくいくらしい。(情報感謝!)
  • JustSystem 三四郎2009
    ウインドウサイズを変更すると、広がった部分が再描画されない。

    →治ったみたい。が、三四郎2009は日本語入力システムとしてATOKしか受け付けない問題がある。可能なら、早いうちにLibreOfficeやMS-Officeなどに移行したほうが良い。
  • Ztop v1.72
    マウスカーソルが飛んだり、ホイールスクロールで変にスクロールしたりする。
    V1.73にして、これをうまく使う情報がここにあった。
    一応不具合は出なくなった模様。
  • コントロールパネル~管理ツール~サービス
    ウインドウを右側広げると描画されない。標準同梱ツールがバグっててどうするよ。→治ったみたい。
  • WindowsXP/7-32bitまでで動いていたスクリーンセーバープログラムは、軒並みアウト。
    画面復帰時にタスクバーが消えてしまう。パスワードをかけていれば大丈夫らしいが、基本的に64bit 7対応とうたっている物以外は使わない方がよさそう。
    32ビット 7では問題なかったので、64ビット 7のバグのような気もする。
  • e-TAXで使うカードリーダーSHARP RW5100
    ドライバーが64ビットに対応してない。
    SHARPのサイトでは未対応と書いてあったが、OEMのサンワサプライの製品では「対応」となっていた。
    実際、オンラインでドライバを探すとインストールできた。
    e-TAXのソフト自体は64ビットでも動く。
  • IO-DATA USBGPS2
    メーカーではWindows7は32bit版も含め一切サポートしていない。
    FT232R USB UARTというドライバが×と出る。 このドライバは、その大本のメーカーFTDI社のサポートページから64ビット対応版がダウンロードできる。
    executable版を選んだ方が楽だと思ったが、困ったことにこれを実行してもドライバは正常にインストールされない。
    仕方ないので、zip版を適当な場所(デスクトップとか)に展開する。デバイスマネージャーからFT232R USB UARTを選択してプロパティ~ドライバーの更新~コンピューターを参照してドライバーソフトウエアを検索します~場所はc:\からで、サブフォルダも検索させる。すると「証明書がない」とか言ってくるが一応見つかるので、インストール。
    これでFTR232Rは動くようになるが、まだ「USB Serial Port」が動かないと言ってくる。
    もう一度同じようにUSB Serial Portでも検索してインストール。
    これで必要なドライバがすべてインストールされ、COMポートも確定するのでUSBGPS2 Utilityを起動、 COMポートを指定して動作確認する(最初は初期化した方がいいと思う)。初期測位までに5分くらいかかる。
    他のポータブルGPS(2台)では速攻なので、このIOのが性能が低いと思われる。
    なお、付属のSuperMapple8は問題なく動作する。が、GPS機種設定は「IO-DATA社製GPS」ではなく、「NMEA TOKYO Datum出力タイプ」に設定しなければならない。なお、このGPSはカシミール3Dでは対応されていない。
  • Unlocker v1.9.1
    32ビット版ではシェル拡張でunlockが出てこないので、64ビット版を入れること。
  • 確実にWindows7をBootCampで導入する方法;Mac mini 2011および2014、MoutainLion/Yosemite版(Mac mini 2014では注意点あり)

    Windows7をMac mini2011および2014にBootCampで導入した。
    BootCamp上でインストールするのは、ハードの性能を最大限引き出すWindows環境がほしかったからである。Fusion上との差などは後述。

    Fusion4上に導入したときはキーボード以外では苦労しなかったが、このBootCampでは非常に苦労したので記録しておく。

    細かい経緯は省略するとして、まず1つ言えるのは「AppleのBootCampに関する説明は重要な点が抜けてる」ということである。あの説明書通りにやってうまくいくのはまぐれだと思う(2014/11/15追記;今上がっているのは良くなっている)。

    で、まずはわかったことのまとめ。
    1. インストールに必要な物。Mac mini2011では8GB以上のUSBメモリと2GB以上のUSBメモリ。Mac mini2014では8GBメモリ1本だけで良い。USB-DVDドライブまたは、DVDドライブを持ったMac(Windows機でも出来るとは思う)。
      Windows7のインストールディスクは当然。
    2. Mac mini2011のBootデバイス順序は、USB1→内蔵HDDである。
      また、MacにはこのBoot順を変える手段がない(少なくとも公開されていない)。
    3. USBは、本体裏面左(中央側)から1~4になっている。
      2011では2~4はBoot対象にはなっていない様子。2014では他のポートからもBoot可能になっている(でもこれが悪さをする原因になっている)。
    4. Option(またはAlt)キーを押しているとHDDから強制起動してMacOS/Windows/ネットワークからの起動選択は出来るが、USB1とHDDの起動順を入れ替えられない。
    5. そのため、USB1にUSBメモリが刺さっていると、必ずそこから起動しようとし、起動できない場合はエラーを表示する。
      「Non-system disk press any key」と表示する割に、キーボードが効かないのでどうしようもなくなる。
    6. USB1にUSB接続のDVDドライブを接続している場合も起動できない。
      DVDの内容が、Windows7のインストールディスクであっても(起動できるはずなのに)。
      「no bootable device -- insert boot disk and press any key」と表示する割に、やはりキーボードが効かないのでどうしようもない。2014では起動はできるが、その後キーボードもマウスも一切効かず操作できない。
    (余談。Macは、一旦ブート元を設定すると、そこから起動できない場合でも他からブートするということはしない。Windowsから起動するにして、実際にはWindowsから起動できなかった場合にもOS Xで起動したりしない。 優先順位という考え方がないからだが、実にお馬鹿さんといえよう。この辺りはWindows機の方が圧倒的に優れている。)

    ということを前提に、実際にWindows7を「確実に」インストールする手順は以下のようになる。
    1. MacをTimeMachineでバックアップしておく。BOOTCAMP導入中に失敗するとMacOS側もパーになることがあるので、その時もすぐに復旧できるようにするため。自信があれば取らなくてもいいが、私は一度失敗したので、2回目以降は必ず取るようにしている。
    2. USBメモリにWindows7のディスクイメージを入れ込む。以下MacOS上での作業方法。
      1. DVDドライブにWinows7のインストールディスクを挿入
      2. ディスクユーティリティを起動
      3. Windows7のディスクを選択状態にして、ファイル~新規~(Win7の名前)からディスクイメージを選択。
        名前そのまま
        場所適当(デスクトップなど)
        イメージフォーマット~DVD/CDマスター
        暗号化なし
        で保存する。
      4. *.cdrというファイルが出来るので、拡張子を.isoに変更
      5. BootCampアシスタントを起動。「Windows7のインストールディスクを作成」のみを選択。「続ける」でISOイメージに今作ったファイルを指定・・・と言うか、勝手に指定されてる。
        このファイル指定を自動化するため実機上での作成が望ましいが、別の機械で作って実機へコピーしても良い。ちなみに、iMacで作ったら非常に遅かった。MacはDVDドライブの性能が低いからである。USBで接続するDVDドライブのほうが圧倒的に速い。
      6. 内容がすべて入る容量のUSBメモリをUSB1に接続する。Windows7Pro64bitは4GBもあれば入る。さらに、YosemiteのBootCampではこの中にドライバも一緒にコピーするので、+2GBくらいあったほうが良い。8〜16GBあれば問題ない。
        メモリは自動フォーマットにより内容が消去されたあとコピーが始まる。時間は結構かかる(ISOイメージを作る以上に)。
      このUSBメモリが(インストール用)ブートデバイスになる。
    3. 2011ではBOOTCAMPでWindows用ドライバをダウンロードして、別のUSBメモリに保存する。同じメモリだとブートできなくなる。2014/Yosemiteでは(選択する必要はなく)自動的に同じメモリにドライバも入れる。故に、Marvericksまでで作ったisoイメージUSBメモリはYosemiteでは使えない。作りなおす必要がある。BootCampのメニュー上には別USBメモリにドライバを入れる選択項目があるが、それを使って別メモリにドライバを入れ、それをUSBのほかポートに指しているとWindowsのインストールが出来ないという罠である。
    4. BOOTCAMPで「Windows7をインストール」を選択する。これもYosemiteでは不要で、自動的に起動される。
    5. 最新版のBootCamp(5.1.5759)はWindows7に対応できていないので、Windows起動後の初期設定中に「Windows\system32\drivers\AppleSSD.sys このファイルのデジタル署名を検証できません」と出て先に進まない。なので、以下の対策が必要。
      (5-1)1つ前のバージョン(5.1.5640)のBootCampをここからダウンロードしてくる。
      (5-2)USBメモリをFilderで開き、$WinPEDriver$フォルダを削除する。
      (5-3)ダウロードしてきたBootCampを展開する
      (5-4)その中の$WinPEDriver$をUSBメモリにコピーする
      ここで、BootCampフォルダはコピーしない。5640はMacMini2014に対応してないから。2011ならBootCampフォルダも置き換えたほうが良いのかもしれないが、未検証。
    6. Windows用パーティションサイズを設定し、「インストール」を押す
    7. (パーティション設定が終わったら)自動的に再起動がかかる
      このとき、キーボードを差し込んでおかないとWindowsインストーラーが起動しないかもしれない(うちではそうだった)。
    USBからWindowsのインストーラーが起動して、無事インストール画面になる。


    とにかく、2011ではUSBに起動順があることを知ってないとはまる。
    USB-DVDからでも起動できないのが事態をさらにややこしくしている。
    (USB-DVDドライブの中にはMacのUSBバスパワーでは動かずインストールには使えない物があるらしいが、今回の件にはそれは関係ない。ACコンセント付きの物で試したから。)
    2014では、2011までと同じやり方でやると失敗するので要注意。これがわかるのに2週間も無駄にしてしまった。
    さらに、最新版のBootCampではWindows7対応にバグがあるというお粗末さ。Appleは検証が絶対的に甘すぎる。

    ・・・
    この先はWindows7のインストール。
    基本的には普通通りなのだが、Macで作業する上で注意する点がある。
    1. 2014ではキーボードとマウスは有線の物が必須。BluetoothはWindows側でドライバがインストールされるまで使えなくなるから。マウスはなくてもキーボードで操作できるが(それがWindowsの良い所)、キーボードが効かないとどうしようもなくなる。
    2. Windowsの入ったUSBメモリはポート1に指す。2011でも、Windowsドライバの入ったUSBメモリはこの時点ではどのポートにも刺していてはいけない。HDDや光学ドライブも同様。要するに、この時点でUSBポートに指していいのは、1にWindowsの入ったメモリ、他はキーボードとマウスのみとなる。
    3. Windows上で新規インストールをすると、まずは「どこのパーティションに入れるか」聞いてくるので、「ディスク0:パーティション4:BootCamp」を選ぶ。すると、「ここにはインストール出来ない」と言ってくるので、「ドライブオプション(詳細)」からフォーマットを選択する。このパーティションを再フォーマットしてインストール可能にする。
    4. フォーマットはすぐ終了するので「次へ」を押す。この時点で「新しいシステムパーティションを作成できなかったか、既存のシステムパーティションが見つかりませんでした」エラーが出るときは、USBにドライバの入ったメモリやHDDなどが刺さってないか確認する。Windowsは、インストール時に(物理的な)複数ドライブを発見するとこのエラーを発生させる。なので、インストール時には絶対に1ドライブしか接続していてはいけない(インストールディスクの入ったドライブは除く)。Mac mini 2011ではこんなことなかった気がするのだが、2014では発生するので要注意。
    5. インストールが終わり、Windowsが正常起動したら初期設定を行う。此処から先、Windowsが起動してドライバの設定が終わるまではBluetooth機器が使えない。ドライバが入ってないからである。Bluetoothマウスやキーボードが使えない理由はこれ。
    6. 2014(というかYosemiteで作ったメモリ)では初期設定が終わると自動的にBootCampインストーラーが起動しドライバ群がインストールされ、その後再起動する。2011ではドライバをSETUPする。終わったら、USBメモリを外し、再起動する。
      これをしないとディスプレイドライバが標準のままなので、画面の解像度変更とか2画面とかが出来ないし、 ネットワークも繋がらない。このあたりがWindows純正メーカー品との違い。こういう作業に慣れてないと出来ないと思う。
      Bluetooth機器はペアリングが切れるので、コントロールパネルから再ペアリングが必要(2014ではそうだった)。
    7. ここでも注意すべきは、2011では、USB1にはUSBメモリ/DVDドライブ/HDDをつながないことである。起動しなくなる。USB2~4につないでいる状態では起動するので、基本的に、USB1にはキーボードやマウスなど、起動に関係ないデバイスをつなぎ、USB2~4にHDDや光学ドライブを接続することになる。当然、Windows上でReadyBoostをUSBメモリに作る場合もUSB1に接続してはいけない。なお、HUBをつないでいても状況は同じである。2014では問題ない。
    なお、インストールを途中で中断すると、以後Macが全く起動できなくなる。Command+Rでの復元起動も効かない。この場合は、Option+Command+P+RでNVRAMクリアすれば起動できるようになる。ただし、MacOS部分が破壊されている場合はやはり起動に失敗するので、Command+Rで復元する。このとき、TimeMachineバックアップがあれば、復元がとても楽になる。

    ・・・

    以上のことを知っていれば、Mac mini 2011でも2014でもBootCampによるWindows7環境を作成できる。なんにしても、Appleの説明は情報が足りない。

    ここで言えることは、「MacをWindows機にして使おうなんて、普通の人は思わないほうがいい」である。 価格対性能比(およびデザイン)では決して悪くないが、やはりWindows機とは異なるので壁が高い。
    この最初のWindows環境の構築だけでなく、他にもいろいろと問題がある。それについては別の記事にする。「労多くして益少なし」まさにこのことを言う。反省。
    Appleにしてみれば、BootCampはおまけであって、完全ではなくても文句は言わないで、というところだろう。

    以下は2011での話。
    ・・・2013/02/16
    MountainLion用に更新Mac mini(mid2011) EFIファーム v1.6のアップデートで、「USB記憶装置がホットプラグされている時の起動装置の選択の問題が解決される」は、本当に解決されたようである。

    コメントにも頂いたとおり、Option(Windowsキーボードの場合はAlt)を押したまま再起動すると、起動メディア選択ができる(事を確認した)。たぶんファームアップデートで改善されたというのがこれのことだと思う。この時はUSB-DVDドライブに入っているWindowsインストールディスクからの起動もできた。USB1でなくてもOKだった(USB1以外につないでいる場合)。

    ただし、 USB-DVDにWindowsディスク、USBメモリにWindowsを入れたものを挿していると、どちらかを起動選択しても、なぜか両方とも起動できないので注意。

    2012年2月5日日曜日

    Windows7 on VMware Fusion4

    VMware Fusion4には「キーボードの認識が常にUSになる」というバグがいる。
    このため、Fusion4上でWindows7を動かす場合も、日本語キーボードだと配置が合わないという問題が発生する。

    それを解消する方法。
    1. VMwareを完全に終了しておく
    2. SpotLightで「仮想マシン」で検索
    3. Windows 7 x64.vmwarevmというファイルで右クリック、パッケージの内容を表示(32bit版の時はx64は「ない」)
    4. Windows 7 x64.vmxでこのアプリケーションで開く~適当なテキストエディタで開く
    5. 一番最後の行にkeyboard.vusb.idProduct = "0x222"と追加し、改行、ファイルを保存
    6. VMWare~Windows7を再起動
    7. Windows上で、コントロールパネル~キーボード~ハードウエア~プロパティ~ドライバー~ドライバーの更新
    8. コンピューターを参照してドライバーソフトウエアを検索します~コンピューター上のデバイスドライバー一覧から選択します
    9. 「互換性のあるハードウエアを表示」のチェックを外す
    10. (標準キーボード)の中から「日本語PS/2キーボード 106/109 Ctrl+英数」を選択、次へ
    11. 警告メッセージが出るが「はい」でインストール続行
    12. Windowsを再起動

    これで日本語キーとして正しく認識されるようになる。Lionと違い「|\」と「_ろ」も正しく入力できる。

    ・・・

    さて、うちではMacにもWindowsのキーボードをつなぎ、Mac上ではCommandとControlの位置をKeyRemap4で入れ替えている。また、Windows上ではCapsLockとCtrlを入れ替えている。
    CommandとControlの位置入れ替えだけなら、キーボード~修飾キーの設定で入れ替えられるが、他のキーも変更しようと思うとKeyRemap4が必須であり、またKeyRemap4を入れているとこの修飾キーの設定は無視される。

    こういうことをしていると、Windows上でCtrlとWinのキーが入れ替わってしまう問題が発生する。
    調べてみると、CTRL+←/→を押すと正しくCTRL+←/→と返すのに、CTRL+アルファベットを押すとWin+アルファベットと返してくるという変な現象が発生している。

    これを回避するには、KeyRemap4で、Fusionには入れ替えてない状態のキーを渡すようにすればよい。

    private.xmlに次の内容相当を追記してReloadする。
    <?xml version="1.0"?>
    <root>
      <appdef>
        <appname>VMware</appname>
        <equal>com.vmware.fusion</equal>
      </appdef>
      <item>
        <name>Control_R to Command_R (except VMware)</name>
        <identifier>private.app_vmware_control_r_to_command_r</identifier>
        <not>VMware</not>
        <autogen>--KeyToKey-- KeyCode::CONTROL_R, KeyCode::COMMAND_R</autogen>
      </item>
      <item>
        <name>Control_L to Command_L (except VMware)</name>
        <identifier>private.app_vmware_control_l_to_command_l</identifier>
        <not>VMware</not>
        <autogen>--KeyToKey-- KeyCode::CONTROL_L, KeyCode::COMMAND_L</autogen>
      </item>
      <item>
        <name>Command_L to Control_L(except VMware)</name>
        <identifier>private.app_vmware_command_l_to_control_l</identifier>
        <not>VMware</not>
        <autogen>--KeyToKey-- KeyCode::COMMAND_L, KeyCode::CONTROL_L</autogen>
      </item>
    </root>
    

    これで、思惑通りのキー操作ができるようになる。
    なお、Fusion上に複数のWindows環境を入れている場合、これ1つですべてに有効である。

    Command-L/Control-Lに関してはKeyRemap4に元からexcept Virtual Machineという似たような設定があるが、それを設定してもうまく動かなかった。Fusion4には対応していないのかもしれない。

    実はこの状態でも「全角/半角」を押しても日本語入力できないという問題が残る。
    これに関しては、Windows上のキー配置変更ツール(chgkeyなど)で、「カタカナ・ひらがな→全角/半角」(逆ではないので注意)の変更を入れる。

    ただし、この変更をしても、Mac側が日本語入力モードになっているとWindowsで「全角/半角」が効かない。
    キーが効かないときは、Macの日本語入力モードを確認のこと。

    これで、WindowsとMacでほぼ同じキー操作ができるようになった。

    「そもそもWindows上でキーCtrlとWinを入れ替えればいいんじゃないか」と思われるかもしれないが、先に書いたとおり、返されてくるCtrlとWinのキーコードが場合によって異なるのでうまくいかない。
    だからホストとなるMac側で変更しなければならない。このあたりはさんざんやったから間違いなし。

    CTRL+←/→や一部ファンクションキーはデフォルトではMac側にとられる場合があり、Windowsに渡すことができない。
    この場合、環境設定~キーボード~キーボードショートカットを変更する。
    private.xmlにさらに書き加えれば両立出来るかもしれないが、そこまでは必要を感じてないので省略。

    いや、KeyRemap4MacBookは本当によく出来ている。
    英語だけなのでちょっとわかりにくいけど。











    Lion on VMware Fusion4

    VMware Fusion4には「キーボードの認識が常にUSになる」というバグがいる。
    このため、Fusion4上でLionを動かす場合、日本語キーボードだと配置が合わないという問題が発生する。

    それを改善する方法。

    1. VMwareを完全に終了しておく
    2. SpotLightで「仮想マシン」で検索
    3. OS X 10.7(64ビット).vmwarevmというファイルで右クリック、パッケージの内容を表示
    4. OS X 10.7(64ビット).vmxでこのアプリケーションで開く~適当なテキストエディタで開く
    5. 一番最後の行にkeyboard.vusb.idProduct = "0x222"と追加し、改行、ファイルを保存
    6. Lion Xを再起動

    これで、「|\」と「_ろ」以外のキーは全て正しい配置になる。
    しかし、この2つだけは入力が出来ない。
    KeyRemap4MacBookを使ってこれを強引に入力できるようにする。

    private.xmlに次の内容相当を追記してReloadする。
    <?xml version="1.0"?>
    <root>
     <item>
        <name>Swap F14 and BackSlash</name>
        <identifier>private.swap_F14_and_BackSlash</identifier>
        <autogen>--KeyToKey-- KeyCode::F14, KeyCode::VK_JIS_BACKSLASH</autogen>
     </item>
     <item>
        <name>Shift(L)+0=Underscore</name>
        <identifier>private.shift0L_to_Underscore</identifier>
        <autogen>--KeyToKey--
      KeyCode::KEY_0, ModifierFlag::SHIFT_R,
      KeyCode::JIS_UNDERSCORE
        </autogen>
     </item>
     <item>
        <name>Shift(R)+0=Underscore</name>
        <identifier>private.shift0R_to_Underscore</identifier>
        <autogen>--KeyToKey--
      KeyCode::KEY_0, ModifierFlag::SHIFT_L,
      KeyCode::JIS_UNDERSCORE
        </autogen>
     </item>
    </root>
    

    これを読み込ませてチェックすることにより、「\」でバックスラッシュ、SHIFT+0で「_」を入力できるようにする。
    バックスラッシュでなく「\」そのものを入力したいときは、VK_JIS_YENにすればよい。
    これで、Lion上でのプログラム開発も「できなくはない」状態になる。

    しかしまだ、Lion上ではファンクションキーの設定ができない。
    キーボードショートカット設定でファンクションキーに設定しても一切効いてない。
    KeyRemap4でもキーを認識してくれないので再設定しようがない。
    VMware Fusion~環境設定~キーボードとマウス~キーマッピングでも設定できない。

    あとはVMWareFusion側で正式に対応されるのを待つしかない。
    が、私も前にサポートに連絡を入れたが、いっこうに改善される気配がない。
    開発元はUSなので、気がつかないのかもしれない。
    (ひょっとしたらBluetoothキーボードでは大丈夫?)
    だったら日本の窓口act2が何とかしろ!と思うのだが。

    Fusion4によって、Lion対応というのは表面上の宣伝文句に過ぎず、現状では使い物にならない。
    と、言われても仕方ないと思うのだが。








    2012年1月31日火曜日

    別スレッドを使うときの注意

    performSelectorInBackground:等で別スレッドを造り処理を並行動作させるとき、
    「スレッドではautorelease poolを別途作らなければならない。」
    と、仕様書に書いてある。

    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];


    [pool release];



    別スレッドでは常にそれを作るように書いておけばいいが、
    処理時間を少しでも短くしたいなら、autoreleaseを使わないのなら、その確保も省略したい。

    ユーザーが直接autoreleaseを使わないならそれでもいい、と思いがちだが、
    実は暗黙に使われる場合があるので要注意である。
     そのあたりは仕様書をよく読まないといけない。

    たとえば、 UIGraphicsGetImageFromCurrentImageContext()は仕様書(UIKit Function Reference)にて「An autolereased object」と書いてある。
    だから、これを別スレッドないで使うなら、autorelease poolの生成は必須となる。
    これを忘れると、実行時にメモリリークが出る。

    ・・・

    iOS4.xではこの通り。
    ところが、iOS5ではそれが出ない。autorelease poolを自動生成してくれるようになったのか、単にエラーが出てないだけなのかわからない。いずれにしても、ちゃんと書いておくのが吉である。

    2012年1月26日木曜日

    タッチイベントの発生仕方

    UIView上、正確にはUIResponderでは、画面をタッチするとtouchesBegan/Moved/Ended/Cancelledイベントが発生する=メソッドが呼び出されるが、どういう状態のときにどう送られてくるかは資料がなかった。

    とりあえず解ったのは以下の通り。

    -(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event

    (1)基本はBegan(押したとき)->Moved(移動中)->Ended(指を離した)の順で呼び出される
    ただし、移動が少ないときは Movedは来ない場合もある。
    また、複数タッチしたときは、その都度Beganが発生する。

    (2)同点タッチではタッチイベントは発生し続けない
    逆に言えば、イベントは座標もしくは押下状態が変化したときのみ発生する。
    タッチ中かどうかは上記イベントの発生状況によって判定するしかない。

    (3)タッチが何本指なのかは[touches count]で取得出来る
    iOS5ではGestureRecogniserでシングル/マルチ他の判定を行ってくれるようだが、iOS4までは処理内でこれを数えて処理を分けるしかない。

    (4)マルチタッチは[touches count]==2だけで処理するとたぶん半分は抜けてしまう
    実は人間の指の動作はそんなに厳密ではないので、Began*2という押され方をすることもある。それもマルチタッチと見なす方が「親切」だと思う。
    私の作ったアプリはそうしている。
    began(cnt=1)->moved(cnt=1)->began(cnt=1)->moved(cnt=2)なんてパターンもあるので注意。

    (5)マルチタッチの場合、touchesで返ってくる座標情報の順番は不定
    押下順ではない。従って、スライドの移動方向を得ようとするときには、全ての座標を読み取って、正しい組み合わせで算出する必要がある。
     (6)ストロークしたまま画面外に出る・中に入るときのbegin/endedの状態
        シミュレーター上
            外に出る    マウスクリックを離した時点でEnded(画面外座標を返している)
            中に入る    全て無視される(中に入っても検出されない)
        実機上
            外に出る    物理画面内なら、タッチを離した時点でEnded(画面外座標を返している)
            中に入る    全て無視される(中に入っても検出されない)
            iOS5では、スータスバーの位置から下ドラッグすると、Nortify画面が出てくる

    まあ、他にもいろいろあるが、プログラムを組む上で最低限必要なのはこれくらいかと。
    マルチタッチ時の座標の処理は結構面倒で、頭の体操になる。


    「長押しはどう処理すんねん」とかあるかもしれないけど、それはいずれまた。

    2012年1月23日月曜日

    第7弾アプリ「手習い君」発売開始

    第7弾「手習い君」を発売開始

    AIG-Soft 第7弾アプリ「手習い君」が発売になりました。

    般若心経を始め、小学生漢字やかな文字などを手書き感覚でなぞって練習するアプリです。
    やっぱり、主な目的は写経です(^_^;)。
    写経アプリは既存のものもありますが、全てが文字送りのボタンを押す必要があるなど
    コンピューター的操作が必要で、およそ本当の写経とは違います。

    「手習い君」は紙に字を書く感覚の再現を重視しました。 
    自動スクロール機能などにより、ユーザーが写経に集中出来る状態を演出します。 

    出来上った書面は、メールで送信したり、AirPrintで印刷したり出来ます。

    よろしくお願いします。 

    2012/02/05追記
    V1.1にバージョンアップしました。細かいバグが修正されています。

    ここの維持のためにも、ご購入いただけるとありがたいかとm(_ _)m。

    2012年1月22日日曜日

    列挙子の使い方と注意


    配列要素にアクセスするとき、Cでは要素数を自分で管理する必要があった。
    要素数を超えてアクセスしても言語側は知らんぷりなので、暴走の原因になることもしばしばである。
    (高速化などトリックにも使えるのだが、それは上級者のみに許された究極の技。)
    そもそも、要素数をユーザーが管理する必要がある。

    しかし、Cocoaのクラスでは要素数をシステムが管理してくれるので、範囲を超えて越えてアクセスすると
    例外がかかり止まる。また、要素数は[count]メッセージで取得出来る。
    そのため、安全(要素個数を超えることなく)にループを回すことが出来る。

    要素番号が必要な場合はこのループを使う。
    NSUInteger i; // 要素番号
    NSArray *array = [NSArray arrayWithObjects:@"abc", @"def", @"ghi", @"jkl", nil];
    for (i = 0; i < [array count]; i++) {
        NSLog(@"index: %d, value: %@\n", i, [array objectAtIndex:i]);
    }
    

    Objective-Cでは「列挙子」というものを使ってループを構築することも出来る。
    これは要素の終端を判定してループを構築するもので、要素番号を保持しておく必要がなくなる
    (逆に言えば、ループ内では要素番号を参照することはそのままでは出来ない)。
    これにはNSEnumeratorとwhileループを使う。
    NSArray *array = [NSArray arrayWithObjects:@"abc", @"def", @"ghi", @"jkl", nil];
    NSEnumerator *enumerator = [array objectEnumerator];
    id obj;
    while (obj = [enumerator nextObject]) { // nilで終了
        NSLog(@"value: %@\n", obj);
    }
    // enumeratorは解放の必要がない(というかしたら駄目)
    
    objectEnumeratorの部分をreverseObjectEnumeratorにすると、配列の終端から先頭=0に向けての逆順になる。
    例はNSArrayに対するものであるが、NSDictionaryでも同様な処理がかける。

    Objective-C 2.0ではさらにfor文が拡張され、配列・辞書の内容が高速かつ安全に「参照」出来る様になっている。
    高速列挙子である。ここで言う「高速」はコンパイラが最適化したコードを発生するという意味であり、
    「安全」は終了判定を記述する必要がないことを意味する。
    NSArray *array = [NSArray arrayWithObjects:@"abc", @"def", @"ghi", @"jkl", nil];
    for (id obj in array) { // 新しいクラス変数を作り、上記arrayの内容を参照する(最後まで)
        NSLog(@"value: %@\n", obj);
    }
    

    (高速)列挙子を使ったループをMutableで構築する場合、1つ注意がある。
    それは、ループ内で要素の更新をしてはいけないことである。
    NSMutaleArray *marray = [NSMutableArray arrayWithObjects:@"abc", @"def", @"ghi", @"jkl", nil];
    NSEnumerator *enumerator = [marray objectEnumerator];
    id obj;
    NSInterger i=0;
    while (obj = [enumerator nextObject]) { // nilで終了
        NSLog(@"value: %@\n", obj);
        ~
        [marray replaceObjectAtIndex:i withObject:obj];
        i++;
    }
    
    とすると、例外が発生する。replaceObjectAtIndexのように、配列要素数が変化しない場合でも
    同様である。要素を変更する場合は、素直に要素番号を持ってループを回すしかない。






    2012年1月18日水曜日

    ソース部分をSyntaxHighlighterで表示する

    このブログに載せる記事の中で、プログラム部分をわかりやすくしたいと考えていた所、「SyntaxHighlighter」という物があることを知った。
    javascriptを使って整形するらしい。

    SyntaxHighlighter

    これを使うと以下のように出来る。

    「例」
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad) {
        // iPad
    } else {
        // それ以外
    }
    

    「出来る」と書いたが、実際にはSyntaxHighlighterのHPのinstllationに書かれている方法は
    Bloggerではそのまま使えない。
    Bloggerにはjavascriptファイルを中に置くことが出来ないので、外部サーバーのどこかに置くか、
    記事の中に全てを埋め込む必要がある。

    最初は、script実体をファイルから本文内に展開していた。
    scriptなので表示されないが、結構な行数である。
    しかも、再編集をかけるとなぜか無効になってしまう問題があった
    (スクリプティング部分が勝手に書き換えられてしまう感じ。再貼り付けすると直る)。

    そのため、別の場所に置いたファイルを読み込ませるようにした。
    これなら再編集してもおかしくならないし、比較的簡単。

    ただし、SyntaxHighlighterからダウンロードしたファイルをそのまま展開したディレクトリ構造と、
    installationに書かれているサンプルに書かれているディレクトリ構造は異なるので、
    書き換えが必要である。
    また、リストに入れる言語別に使用するスクリプトファイルも変更しなければならない。

    また、Objective-CではC用のスクリプトを使うのだが、これにはバグがあって、
    プロトコル宣言である<プロトコル名>を1行で書くと、リストの最後というか
    <pre>の直前にそのプロトコル行が再表示されてしまう。
    これを回避するには<とプロトコル名と>を改行で分けて記述すれば良い。
    スクリプトを書き換えれば直るのかもしれないが、解らなかった。

    HTMLモードで記述し直す必要があるので、過去にさかのぼっての適応は
    「気が向いたら」することにした。

    Bloggerが標準でサポートしてくれれば良いのだが。
    それとも、私が知らないだけで方法はあるのだろうか?







    2012年1月14日土曜日

    plistからプログラム名とバージョンを得る方法

    plistからプログラム名とバージョンを得る方法は以下の通り。

    NSString *programName=[[[NSBundle mainBundle]infoDictionary]objectForKey:(NSString *)kCFBundleNameKey];
    NSLog(@"programName=%@",programName);
    NSString *programVersion=[[[NSBundle mainBundle]infoDictionary]objectForKey:(NSString *)kCFBundleVersionKey];
    NSLog(@"programVersion=%@",programVersion);
    

    defaultデータベースに書きこむ;これにより、iOS内設定でもこれらの値が読めるようになる。

    Root.plistに書くkey名(Identifier)はdefault内のキー名またはRoot.strings内のキー名である。

    NSUserDefaults *defaults=[NSUserDefaults standardUserDefaults];
    [defaults setObject:programName       forKey:keyProgramName];
    [defaults setObject:programVersion forKey:keyProgramVersion];
    







    2012年1月12日木曜日

    iOSシミュレーターの限界

    iOSシミュレーターはiOSアプリ開発に欠かせないものではあるが、
    残念ながら、実機の全てを正確にシミュレート出来るわけではない。

    以下の項目はiOSシミュレーターでは解らない。

    ・シミュレーター上ではメモリリークは発生してない(検出されない)のに、実機だと発生する。
    実機をつないでProfileのLeakをするとそうなることがある。
    シミュレーター(86)と実機(ARM)でライブラリの出来が違うのだろうか?
    当然実機で直すのが筋なのではあるが、全く原因がわからない物も多くて、小規模な物なら放置しているのが現状。


    ・固有デバイスの動作
    カメラ、ジャイロ、デバイスモーションなど。
    GPSは「デバッグ~位置」から仮想的にデータを与えることは出来るが、
    やはり実機で確認した方が良い。
    BluetoothはOK、AirPrintもシミュレーターで印刷出来る。

    ・実速度
    特にグラフィック周りの速度差が大きい。
    実機でも、iPad2とiPod touch4は差が大きい(グラフィック割りのハードの差がはっきり出る)。

    ・メモリ容量
    シミュレーター上は事実上無制限なので、その上で動いたからといって、実機で動くとは限らない。メモリもしくはUI要素をたくさん使うアプリでは特に注意。

    ・画面回転の中間状態(unknown)と上下向き(Faceup/down)
    実機では正立と逆が一瞬で切り替わることがあるが、シミュレーターではそれが出来ない。

    ・電池残量
    それに関わるNotificationも同様。

    ・メール実送信
    Xcode3まではメーラーそのものも立ち上がらなかった。
    Xcode4では立ち上がるが、実送信はされない。
    FrontierMailでは送信出来る。

    ・imageの透過状態
    実機では256色でしか透過しないが、シミュレーター上はフルカラーでも透過する。
    これは単なるシミュレーターのバグだと思う。
    iOS4/5/6用全てで発生する。

    ・3本以上指のマルチタッチ
    ダブルまではシミュレーター上でもピンチ/スライドともに可能。

    ・スリープ
    連続稼働させる必要があるアプリではこの確認が必須。
    (自作の物では、ZeroRec/Komadori/ChariRecoがこれに当たる)

    ・CPU固有の挙動
    シミュレーターは86のコードでコンパイルされ、実機はARMでコンパイルされる。
    この違いは、メモリアクセスへの制約の違いとして現れる。
    大雑把に言えば、86はメモリアクセスに対して制約がないが、ARMは
    アクセスサイズとバイト境界の関係に制約があり、違えるとトラップを発生して落ちる。
    ワークエリアに対しバイトではないサイズでデータを読み書きするプログラムは、
    シミュレーター上では動作しても実機では動かないことがある。
    X−BASIC for iOSではこれで大いに苦労した。

    とにかくシミュレーターと実機は似て非なる物なので、アプリは必ず実機での動作確認が必要である。

    特にメモリ容量の違いは大きい。シミュレーター上では動くのに実機では起動すら出来ないアプリはほぼ間違いなく「絶対に実機での動作確認をしてない」と思われる。有名どころでも多々存在する。

    気をつけよう。

    2012年1月11日水曜日

    iOSシミュレーター上のアルバムに画像を入れる方法

    iOSシミュレーター上のアルバムに画像を入れる方法。

    1. iOSシミュレーターを起動し、その上にFiderから画像をドラッグ
    2. iOS内のSafariが立ち上がり、画像を表示する
    3. 画像上でマウス左クリックを続ける
    4. 「画像を保存」「コピー」が出るので、保存を選択 
    アルバム上に画像がないとデバッグ出来ないときはこの方法で入れ込む。

    2012/12/07追記
    iOS6上では上記の他に、Safariに直接画像をドラッグし、
    アクションからアルバムに保存ができる。

    2012年1月10日火曜日

    Xcode起動時のプロジェクトの選択

    Xcodeを起動した時、プロジェクトを選択するダイアログが出るが、
    ここは、そのままにしていると、テストで開いたようなすでに存在しないプロジェクトまで
    残り続けてしまう。


    これを整理するには、
        Xcode-organaizer-projects

    でプロジェクト履歴一覧を開き、Not Foundになっている、もしくは存在してもリストには出したくないプロジェクトを選択、BackSpaceキーを押して削除する。

    プロジェクトの実体が消されるわけではないので、間違ったのなら、また開けば良いだけ。

    2012/01/19追記
    どうもこれでは消えない場合もあるようで。困ったなぁ。

    2012年1月9日月曜日

    Localize.stringsの中で#ifは使えるのか?

    Localize.stringsの中では#ifは使えない。
    これは、 Localize.stringsはプリプロセッサは通らない事を意味する。
    故に、全てのプリプロセッサ命令も同様に使えない。

    同一ソースからコンパイル条件によって複数のアプリを生成する場合、
    Localize.strings内には常に、無駄になっても全てのアプリで使う分の文字列を
    入れる必要があるということになる。


    #ifが使えれば便利なのだが、将来のXcodeバージョンアップで何とかしてくれないものだろうか。

    2012年1月8日日曜日

    UIImagePickerControllerの使い方(4)

    書くのをすっかり忘れてたので間が空いたけど、次は画像選択。

    iPadでは、UIPopoverController内で表示させる必要がある。
    iPod/iPhoneではNavigation配下のビューでOK。

    @interface SetupTableViewController : UITableViewController
    <
    // デリゲートが必要
    UIPopoverControllerDelegate,
    UINavigationControllerDelegate,
    UIImagePickerControllerDelegate
    >
    {
        UIPopoverController *imagePopoverController;    // imagePicker用
        IBOutlet    UIImagePickerController *imagePicker;
    }
    

    nib上でUIImagePickerControllerを配置、接続しておく。
    imagePopoverController=[[UIPopoverController alloc]initWithContentViewController:imagePicker];
    imagePicker.delegate=self;
    imagePopoverController.delegate=self;
    [imagePopoverController presentPopoverFromBarButtonItem:parentSender permittedArrowDirections:UIPopoverArrowDirectionAny animated:YES];
    

    画像を選択すると、デリゲートが呼び出される。

    - (void)imagePickerController:(UIImagePickerController *)picker didFinishPickingMediaWithInfo:(NSDictionary *)info
    

    画像そのものは、UIImage *で
        [info objectForKey:UIImagePickerControllerOriginalImage]
    
    で得られる。

    iPadではPopover内でimagePickerControllerを開くので、閉じるのもそれが行わなければならない。このあたり、iPhoneとは異なるので注意(ちまたの書籍では有名本を含めほとんどこの点については記載されていない。)
        [imagePopoverController dismissPopoverAnimated:YES];
    









    Supported interface orientationの意味

    info.plistのSupported interface orientationは、そのアプリのサポートする画面回転方向を設定するが、もう1つ「起動時の画面方向を指定する」意味も持つ。

    特に重要なのがitem0で、これで設定した方向で起動しようとする。


    横画面で起動するアプリでない場合、基本的にはここはPortraitのbutton home buttonにする。
    top homeにすると、ホームボタンが上にある状態で起動した様になる。
    シミュレーターで実行するとよく分かる。

    起動画面の向きがおかしい場合、ここも確認するといいかもしれない。