設定 - みる会図書館


検索対象: Inside Visual C++
275件見つかりました。

1. Inside Visual C++

1. 2. 3. 4. 26 章ダイナミックリンクライプラリ (DLL) VisuaI Workbench の < プロジェクトの設定 > ダイアログ中で CMicrosoft Foundation Class を使用 ] チェックポックスのチェックをはすす。 < C/C 十十コンパイラオプション > ダイアログ中で、 [ 共通 ] ラジオボタンを押してから以下の [ ビルドオプション ] を変更する。 〇 [ メモリモデル ] : [ モデル ] を [ ラージ ] に設定する。 〇 [ プリプロセッサ ] : [ シンポルとマクロの定義 ] に「 _AFXDLL 」を追加する。 〇 CWindows の起動と終了 ] : [far 関数として生成する ] チェックポックスをチェックする。 プロジェクトのくリンカオプション > ダイアログ中で、 [ ビルドオプション ] を [ リリース用 ] に 設定し、 [ インブット ] の [ ライプラリ ] リストの先頭に MFC200 を追加する。 プロジェクトの < リンカオプション > ダイアログ中で、 [ ビルドオプション ] を [ デバッグ用 ] に 設定し、 [ インブット ] の [ ライプラリ ] リストの先頭に MFC200. 〃を追加する。 クライアントの EXE ファイルのサイズを減らしたい場合は、リソーススクリプトの冗長なリソー スを除去する。これを行なうには App Studio を起動し、 [ ファイル ] メニューから [ インクルード ファイルの設定 ] を選択する。表示された < インクルードファイルの設定 > ダイアログボックス中の [ コンパイル時に追加するファイル ] リストボックスから、標準 AFX リソースへの参照を削除し、 次に COK] をクリックする。アプリケーションフレームワークは、 MFC200. DLL リソースを検索す る前にクライアントリソースを検索するので、必要な場合は標準 AFX リソースをオーバーライド することができるということを覚えておくこと。 以上に示された変更を行なった後、 VisuaIWorkbench の [ プロジェクト ] メニューから [ リビル ド ] を選択しなければならない。 ■クラスライプラリ拡張 DLL クラスライプラリ DLL に新しいクラスを追加したい場合には、醯FC200. DLL をリビルドするの ではなく、 MFC200. DLL と共にロード可能な、独自のクラスライプラリ拡張 DLL をクライアント プログラム用に書くことになる。拡張 DLL を書く場合、明確に定義されたいくつかの規則に従わ なければならない。これは本章の最初の例中で、強調していることである。 警告 MFC200. DLL を変更すると、 Microsoft 版の DLL に依存するアプリケーションで 問題を起こすことがある。 0 クラスライプラリ DLL のメモリ使用法 クラスライプラリ拡張 DLL では、メモリはクライアントアプリケーションにより管理される。ク ラスライプラリ DLL 中で怩肥演算子を使った場合朝砒とんは DLL 用に特別にオーバーロー ドされている ) 、クライアントアプリケーションのメモリが割り当てられるということである。ク 555

2. Inside Visual C++

1 章 Microsoft Windows と Visual C 十十 ることができる ! 試してみるといい ( その場合 App Studi0 を別のファイルとしてコピーし、その コピーをロードしないといけない ) 。 AC / C 十十コンノヾイラ VisuaI C 十十コンパイラは、 C ソースコードと C 十十ソースコードの両方を処理することができ る。コンパイラはソースコードファイル名の拡張子を調べて言語を決定する。 C という拡張子は C ソースコードを示し、 CPP 、あるいは CXX は C 十十ソースコードを示す。コンパイラは ANSI ノ ジョン 2.1 に準拠し、さらに Microsoft の付加的な拡張がある。ただし VisuaIC 十十バージョン 1.0 では、テンプレートと例外処理の文法はサポートされていない。 VisuaI Workbench の CMicrosoft Foundation Class を使用 ] オプション ( [ オプション ] の < プロジェクトの設定 > ダイアログボック ス中 ) は、コンパイラが Microsoft 基本クラスライプラリのインクルードファイルを使用するかど うかを決定する。 0 リンカ VisuaI C 十十リンカは、 EXE ファイルを生成するために、コンパイラが生成した OBJ ファイル を処理する。 VisuaI Workbench の CMicrosoft Foundation CIass を使用 ] オプションを指定する と、リンカは適切なメモリモデル用の Microsoft 基本クラスライプラリを使用する。 0 リソースコンノヾイラ VisuaI C 十十リソースコンパイラは、コンパイルモード、あるいはバインドモードのどちらかで 動作する。コンパイルモードでは、 AppStudio で生成した ASCII のリソース ( RC ) ファイルをバ イナリの RES ファイルにコンパイルする。バインドモードでは、 RES ファイルが実行 (EXE) ファ イルにマージされる。 RES ファイルを更新したときは、再リンクすることなしに、 RES ファイル を EXE ファイルに再バインドすることができる。 0 テパッガ プログラムが最初から動作すれば、デバッガは必要ない。そうでないなら、デバッガが必要なこと がある。 VisuaI C 十十デバッガは、 Windows 上で動作する初めての C 十十のデバッグ環境である。 デバッガはプレークポイントをディスク上に確実に保存するために、 VisuaIWorkbench と共に緊 密に動作する。ツールバーのボタンでプレークポイントをオン / オフし、シングルステップ実行を 制御する。 Figure 1 ー 2 は動作中の C 十十デバッガを示したものである。派生クラスとべースクラス のすべてのデータメンバを表示するために、く口一カル > ウインドウ中で、どのようにオプジェク トボインタが展開されているかに注目すること。プログラムをデバッグするためには、コンパイラ とリンカのオプションをデバッグ情報を生成するように設定して、プログラムをビルドしなければ ならない。 35

3. Inside Visual C++

PART 2 クラスライプラリピュークラス 〇 CSS ナンバ ] (social security number : 社会保証番号 ) 工ディットコントロール。 APP Studi0 に関する限り、このコントロールは [ 名前 ] のエディットコントロールとまったく同じである。 単にその ID を / DC. ー SS に変更する。あとで ClassWizard を使ってこれを数値フィールド にする。 〇 [ 略歴 ] 工ディットコントロール。これは複数行のエディットコントロールである。この ID を / DC. ー召 / 0 に変更し、次にそのプロバティを以下のように設定する。 国第第ドロ書き込み禁止但 ) 図複数行 ( 墅区垂直第トスクルに ) 図境界⑧ ロ垂直懃ル ロ水平たトス川矼 ) ロ 0 [ M 変 ( 0 湃ストの配置囚 : ロ水平期ルに ) @)i 宿御 : 日対アロハ。ティ 〇 [ 分類 ] グループポックス。このコントロールはふたつのラジオボタンを視覚的にグループ化 ロ大文字 ( 旦 ) ロ小文字 0 図リタうの挿入⑩ ロ常に選択を表示 ( 9 ・ スタイル [ 時給 ] ボタンの ID を / 〃 C. ー C. T に設定し、それ以外のプロバティを次に示すように設定 〇 [ 時給 ] 、 [ 月給 ] ラジオボタン。これらのラジオボタンを [ 分類 ] グループポックス内に置く。 するのに使用される。キャプションに分類とタイプする。デフォルト ID のままとする。 する。 国コ D 00 : Radio 8 リ加フ「 凶可視凹図のア ( 印 = 図たト CAT ロ無効@ 図タアル口左躪えラキスト 凶可視Ⅳ ) ロの止ア ( 0 い凶オ - ト 国』 D 00 : R 記 0 朝州 on アロハ。元 一般 一般 ロ無効⑨図タアルア ( 工 ) ロ左揃えラキスト ) 両方のボタンに [ オート ] プロバティが設定されていること ( デフォルト ) 、そして [ 時給 ] ポ タンのみ [ グループ ] プロバティが設定されていることを確認する。これらのプロバティが正 しく設定されている場合、 Windows はふたつのボタンのうち、同時にひとつだけが選択さ れることを保証する。 [ 分類 ] グループポックスはボタンの動作に何の影響も与えない。 〇 [ 保証 ] グループポックス。このコントロールは 3 つのチェックポックスを収める。キャプショ ンに保証とタイプする。 〇 [ 生命保険 ] 、 [ 無資格 ] 、 [ 医療保険 ] チェックポックス。これらのコントロールを [ 保証 ] グ ループポックスの内部に置く。デフォルトプロバティのままとするが、 ID を IDC-LIFE 、 130

4. Inside Visual C++

PART 2 クラスライプラリピュークラス 3. 4. 70 成 > ダイアログボックスを使ってサプディレクトリを選択し、次にメイクファイルの名前をタイ プする。選択されたサプディレクトリ中にすでに存在する任意の CPP と C ファイルのリストが 表示される。 必要なソースファイルを追加する。 [ すべてを追加 ] ボタンをクリックする ( あるいは個々のファ イルをダブルクリックする ) 。これを行なうと、ファイルがプロジェクトに追加される。 DEF ファイル ( これは書かなければならない ) と RC ファイルも同様に追加する。 手動プリコンパイル済みへッダを設定する。プロジェクトが STDAFX ℃ PP と STDAFX. H を 持っていると仮定すると、 < C/C 十十コンパイラオプション > ダイアログボックスの [ プリコン パイル済みへッダー ] カテゴリを、次に示すように埋める。 をコ ) リに 第ア KS ) : ・「「用叫 0 呼調 0 共通喞 工間 : 礦オア溏 7 1 ア溏フ (C++) 「呂 - ヴ T 1 ア溏 ) ーィ第方 化 pa:cde 生成 叮名 ? 礙 : アイヤ ロア第ををそ使用する ) C 方層 をにア町する ( の : 、 S Ⅱ X. こがはで戸算ナる働 : STIAF*-H この、でア屮北する ) : の起動と了

5. Inside Visual C++

23 章 解説 ドキュメント内へのビットマップの格納 DIB とクリップポード ータ ノヾラメ pFiIe 返り値 C んオプジェクトへのポインタ。 DIB は対応するディスクファイルに書き込まれる。 成功すれば TRUE0 ・ Ma B ″襯ゆ この関数は C 〃オプジェクトの内容から GDI オプジェクトを作成する。そし てビットマップはパラメータとして渡されたメモリデバイスコンテキスト中に選択される。 トマップのサイズとカラービット数は DIB の特性に従って設定される。 ビッ / ヾラメータ pDC bmSize 返り値 解説 GDI ピットマップが選択されるメモリデバイスコンテキストへのポインタ。 以前選択されていた GDI ビットマップへのポインタ パラメータの値を設定する。 GDI ピットマップのサイズを保持する C & 託オプジェクトへの参照。盟〃 B ″川ゆ関数は一 この関数は中間的な GDI ビットマップを作成せすに、 C 〃オプジェクトをディスプ レイ ( あるいはプリンタ ) に送る。関数はいかなる状況であってもスケーリングを行なわない。 バラメータ pDC orlgrn 返り値 ・ S わ℃なん 解説 DIB イメージを受け取るディスプレイ、あるいはプリンタのデバイスコンテキストへのポインタ。 DIB が表示される論理座標位置を保持する CPo / 厩オプジェクト。 成功すれは TRUE0 この関数は中間的な GDI ビットマップを作成せすに、 C. 〃オプジェクトをディスプ レイ ( あるいはプリンタ ) に出力する。ビットマップは指定された矩形に収まるように、必要に応 して伸縮される。 / ヾラメータ pDC orlgrn S1ze 返り値 ・ G Co / 召″ s 解説 DIB イメージを受け取るディスプレイ、あるいはプリンタのデバイスコンテキストへのポインタ。 DIB が表示される論理座標位置を保持する C 尸 0 / 厩オプジェクト。 表示矩形の幅と高さを論理単位で表現する C & 託オプジェクト。 成功すれば T 6 毋。 この関数は CDib オプジェクトの、ピクセルあたりのカラービット数を返す。 DIB が空の場合は 0 が返される。 ・ G 召既の tg この関数は C. 〃データバッフア中の総バイト数を返す。これは対応する BMP ファイルの長さである。 DIB が空の場合は 0 が返される。 461 カラーとバックグラウンドカラーの値を収めている。この情報は GDI ビットマップ構造体の一部 ・ S の i0Co / 0 バ、 G 財 0 〃 0C0 / 0 バーーモノクローム DIB は、ビットマップのフォアグラウンド

6. Inside Visual C++

PART 2 クラスライプラリピュークラス をディスクから読み込んだとき、普通は GDI ビットマップに変換されるが、必要な場合には、プロ グラムは直接 DIB フォーマットで作業することができる。 GD にツトマップの使用 190 App Studio でリソーススクリプトをオープンすると、ビットマップリソースのリストが現われる。 ビットマップを使うためのもっとも簡単な方法は、それをリソースからロードすることである。 リソースからの GD にツトマップのロード 色は両方とも Windows の G 召マクロにより指定できる。 数はディスプレイの「オン」状態の色、そして & ん Co / は「オフ」状態の色を設定する。これらの つのプレーンを持つ。各ピクセルはオンかオフの 1 ビットで表現される。 CDC の S 砒℃ 0 / 0 % 関 モノクロームビットマップでは、さらに自由度が上がる。モノクロームビットマップはただひと ラーの使用を許している。 使えない。 GDI は、色のピクセルバターンが十分単純なときは、ディサー化されたビットマップカ 、 4 ビットのカラー値が設定される。標準 VGA ポードでは、表示される色を制御するパレットは ン」を持ち、各プレーンの対応する 1 ビットがピクセルを表現する。ビットマップが作成されたとき ほとんどのカラービットマップは 16 色である。標準 VGA ポードは隣接する 4 枚の「カラープレー カラービットマップの扱いが、プラシの色の扱いと少し異なっていることを見る。 第 5 章の「 Windows のカラーマッピング」の節を読み返すのも悪くない。こでは Windows の カラービットマップとモノクロビットマップ ならない。 る。もちろん、完了した後にメモリデバイスコンテキストをクリーンアップするのを忘れては 一般的にいってこれらの「ビットプリット」関数群はビュークラスの 0 D 耀関数から呼び出され バイスコンテキストから「実際の」デバイスコンテキストにビット群をコピーしなければならない。 ストを作成しなければならない。次に CDC のメンバ関数 & なん召〃か召″召〃を使って、メモリデ C 尾厩 eCo 襯カ〃励 DC 関数を使って、それぞれのビットマップ用に特別なメモリデバイスコンテキ キスト、あるいはプリンタデバイスコンテキストにビットマップを選択することはできない。まず は、画面上、あるいは印刷ページ上でのみ意味を持つ。それゆえ、ディスプレイデバイスコンテ し力しここに落とし穴がある。ディスプレイ、あるいはプリンタデバイス上の「ビットマップ」 なわなければならない。読者はこの練習をしてきた。 択しなければならない。このオプジェクトに関して作業を終えたときには、選択の解除、削除も行 る。プログラムは何らかの方法でビットマップを作成し、そしてそれをデバイスコンテキストに選 GDI ビットマップは、ペンやフォントといったほかの GDI オプジェクトと同しようなものであ

7. Inside Visual C++

索引 ・・ 34 , 54 複数のドキュメントオプジェクト・ 複数のドキュメントタイプ・ 複数のビュー 複数ビューのアプリケーション・ 複数プラットフォーム開発・ 複数文書インターフェイス・ 複数ベージの印刷・ ブッシュボタン・ フッタ・ 物理座標・・ プライベ ~ ヘッダファイノレ・ ~ メンバ関数・ プライマリ Verb ・ プラウザ・・ ~ ウインドウ・ ・・ 35 , 579 ~ データベース・ プラシ・ 指向の描画関数・ フリーフローティング・・ プリコンパイル済みへッダ・・ プリンタ・ ・・ 344 ・・ 289 ・・ 617 ・・ 374 ・・ 106 ・・ 577 ・・ 65 ・・ 114 ・・ 517 , 535 ・・ 366 , 374 ・・ 132 , 243 ・・ 41 , 52 , 437 ・・ 323 , 381 ・・ 323 , 344 ・・ 366 ・・ 363 ・・ 109 ・・ 93 , 98 ・・ 65 , 438 ・・ 234 ・・ 101 ・・ 95 , 96 , 100 ・・ 69 ・・ 55 ・・ 37 , 69 ~ デバイスコンテキスト・ 設定・・ 固有のフォントを画面に反映させる場合・ 、ディスプレイ両用の同じ描画コード・ ~ デバイスコンテキストと CView の OnDraw 関 ~ ファイノレ・・ プロテクトされた仮想関数・ プロテクトモードアドレシング・・ プロノヾティ ~ を介して通信・・ ~ インデックス・ 対データメンパ・ ~ は App Studio で設定できる・ 名文字列・ プロファイラブログラム・ プロフェッショナノレエディション・ プロンプト ID ・ プロンプト文字列・ へ 文・ ~ と派生クラスの間での作業の分割・ ~ と仮想関数・ 中で呼び出される仮想関数・・ ヘースクラス・ ~ の OnPrepareDC 関数をフラグの設定前に呼び 出しておかなければならない ~ の Serialize ・ ~ のオプジェクトの生成を抑止する・ ヘルプ機構・ ヘルバー関数 ヘルバー演算子・ ヘッダ・ ベジェ曲線・ ・・ 309 ・・ 179 ・・ 221 ・・ 176 ・・ 176 ・・ 162 ・・ 166 ・・ 176 ・・ 38 ・・ 33 ・・ 400 ・・ 483 ・・ 221 , 229 ・・ 399 ・・ 393 ・・ 406 ・・ 404 ・・ 391 ・・ 578 ・・ 602 ・・ 614 ・・ 580 ・・ 315 ・・ 367 ・・ 500 ・・ 579 ・・ 582 ・・ 366 , 374 数・ ~ とディスプレイが MM-TEXT モード・ ~ のサポート・ ~ の設定・・ ~ の設定ダイアログ・ フノレサー ~ とミニサーバー ・・ 515 , 536 , 538 , 539 プレークポイントをディスク上に確実に保存・・ フレームからビューへのメッセージのル一丁イング フレームサイズの制御・・ フレームのツールバーを取得する・ ・・ 366 ・・ 109 ・・ 41 ・・ 155 ・・ 364 ・・ 515 ・・ 35 ・・ 219 ・・ 260 ・・ 245 ヘルプコマンド処理・ ヘルプ固有の識別子・・ ヘルプコンテキスト ID ・ ~ のプレフィックス・ ヘルプコンテキストを WinHelp のパラメータにマップ するコマンドハンドラ・ ヘルプコンテキストの工イリアス・ ヘルプコンテキストの決定・ の、ノレフ。コンノヾイラ・ ヘルプ処理・ ヘルプトヒ。ック・ ヘルプのためのメニューアクセス・ へノレプファイノレ・ プレゼンテーションフォーマット・ フレンド関係・ フレンド関数・ フレンドクラス・ プログラム登録・ プログラムの起動パラメータ・ プログラム名・ プロジェクト・ ~ サプディレクトリ・ 設計・ ・・ 519 ・・ 415 ・・ 595 ・・ 348 ・・ 350 ・・ 33 ・・ 34 ・・ 412 ・・ 578 , 595 ・・ 399 ・・ 398 ・・ 399 ・・ 406 ・・ 397 ・・ 399 ・・ 392 ・・ 397 ・・ 391 , 397 , 404 ~ の名前はアプリケーションの名前と同じ・ ヘルププロジェクトファイル・・ ~ コンピューティング・ ・・ 394 , 398 , 404 変換演算子・ 変数の編集・ ・・ 95 , 96 ・・ 616 ・・ 601 ・・ 150 , 170 , 215 , 285 , 308 641

8. Inside Visual C++

5. 6. 3 章 AppWizard で始める「 He110 world! 」 いくっかのプロジェクトで同時に作業をする場合、同し STDAFX. PCH ファイルを共有するこ とができる。なぜなら、このファイルはアプリケーションに依存しないからである。巨大な PCH ファイルの重複するコピーを除去することで、時間だけでなくディスク容量も節約することがで きる。 注意 STDAFX. H の内容が同じときのみ、プロジェクト間でプリコンパイル済みへッダ ファイルを共有することができる。たとえば OLE を使うプロジェクトは、 OLE を使わない プロジェクトの PCH ファイルを使用できない。詳しい情報は C 十十のマニュアルを参照。 注意コンピュータをリプート、あるいは電源を切ったときに、 PCH ファイルが RAM ド ライプ中に存在しないことは明らかである。このファイルをディスクにセープ / リストア するバッチファイルを用意してもいいし、 [ プロジェクト ] メニューから [ リビルド ] を選択 して、 VisuaI Workbench で強制的にリビルドしてもよい。 ライプラリファイルを RAM ドライプに格納する。ライプラリファイルを RAM ドライプに置け ば、リンク時間を約 25 % 削減できる。コンピュータのプート時に適切な LIB ファイルを RAM ドライプにコピーするバッチファイルを使う ( ミディアムモデルのデバッグライプラリを使う 場合であれば、 MLIBCEW. LIB と MAFXCWD. LIB を RAM ドライプにコピーすることにな る ) 。最後に、 Visual C 十十にライプラリファイルを RAM ドライプから探すように指示する。 このためには、 [ オプション ] メニューから [ ディレクトリ ] を選択する。表示された < ディレク トリの設定 > 夕、、イアログボックス中で [ ライプラリファイル ] テキストボックスが RAM ドライ プを示すように設定する ( 非常に大きな RAM ドライプを持っていない限り、恐らくクラスライ プラリファイルはハードディスク上に残した方がいいだろう。くディレクトリの設定 > ダイアロ グボックス中で CMFC ファイル ] テキストボックスがハードディスク上のクラスライプラリのサ プディレクトリを指したままであることを確認しておく ) 。 デバッガを使わないのであれば、デバッグ情報を除去する。 TRACE 、レ E. / F 必、 ASSERT マ クロの利点は、デバッガを使わなくても得ることができる。 AppWizard はコンパイラとリンカ のデバッグ情報用のスイッチが設定されたプロジェクトファイルを生成する。以下のようにこれ らのスイッチをオフにすれば、ビルド時間を節約することができる。 〇 [ オプション ] メニューから [ プロジェクト ] を選択する。 < プロジェクトの設定 > ダイアログ ボックスが表示されるので、 [ コンパイラ ] ボタンをクリックする。 < C/C 十十コンパイラオ プション > ダイアログボックスが現われ、そこで [ デバッグオプション ] カテゴリをクリック し、次に [ なし ] ラジオボタンをクリックする。画面は次のようになる。 67

9. Inside Visual C++

PART 1 Windows 、 VisuaIC 十十、アプリケーションフレームワークの基本 コマンド行を使う環境では、プログラマはメイクファイルを自分で書かなければならない。 Visual Workbench は、「プロジェクトファイル」として知られているメイクファイルを自動生成する。多く の場合、すべてのソースファイルをプロジェクトサプディレクトリにまとめるのが一般的だが、ファ イルをそこに収めす、ほかのサプディレクトリのファイルを使用することもできる。またプロジェ クトを作成した後、個々の子ウインドウでソースコードファイルを編集することができる。 Visual の [ ビルド ] コマンドを選択すればよい。 できる。実行可能プログラムを生成するには、単に Visual Workbench の [ プロジェクト ] メニ して、一連のダイアログボックスで指定したコンパイラやリンカのスイッチ設定を保存することが て、もっとも最近使用されたプロジェクトのリストを管理している。さらにプロジェクトの一部と Workbench は、ユーザーがどのソースコードファイルで作業していたかを「記憶」しており、 そし 34 がこの開発環境の能力を示すいい例である。 App Studio は、自分自身のリソースでさえも編集す AppStudio は VisuaIC 十十ツールとクラスライプラリを使用して書かれているため、これ自身 スを、クリップポード経由で「取ってくる」ことができる。 ることができるので、ほかの Windows アプリケーションからビットマップ、アイコンなどのリソー ファイルを編集することは薦められない。 App Studio は EXE ファイル、 DLL ファイルも処理す リソースを取り込む # びを虎文を持っ RC ファイルをひとつ持っている。 AppStudio の外で RC (RC) ファイルフォーマットである。そして各プロジェクトは通常、ほかのサプディレクトリから App Studio のネーテイプファイルフォーマットは、 ASCII テキストによる Windows リソース できる。 Basic のコントロールを挿入することができる。その後それを C 十十のコードに結合させることが プログラミング用に App Studio を使用すれば、ダイアログボックスに対話的に Microsoft Visual SDK スタイルのプログラミング用のリソースエデイタとしても使用できるが、クラスライプラリ ログラムよりはるかに強力なダイアログボックスエデイタを収めている。 AppStudio は Windows ジを参照 ) 。 App Studio は、 wysiwyg メニューエデイタと、 Windows SDK の古い DIALOG プ を使用できる。第 3 章では、いくつかの AppStudio のウインドウを示している ( 59 ページ、 60 ペー 別々のツールを用意していた。 VisualC 十十ではほとんどのリソースを編集するのに、 AppStudio オリジナルの Windows SDK は、ダイアログボックス、ビットマップ、フォントを編集するのに ßApp Studi0 リソースエテイタ し、そしてデバッグ用のプレークポイントを設定することができる。 をビルドしたとき、 Visual Workbench はソースコードファイル中のエラー行をハイライトで表示 を使用する場合は、統合開発環境が提供する快適な環境を失うことになる。たとえばプロジェクト スタマイズしたり、あるいは独自のエデイタをインストールすることはできない。独自のエデイタ の文法を強調する、便利なテキストエデイタを含んでいる。残念ながら、このエデイタをフルにカ VisuaI Workbench は、 Windows の標準インターフェイスに従い、さらに色を使用して C 十十

10. Inside Visual C++

4 章基本的なイベントハンドリング m_mousePos テータメンバ CIassWizard の使用 0 盟 0 e 0 怩メンバ関数は、円をどれだけ移動するかを知るために、現在のマウス位置を以前 のマウス位置と比較しなければならない。この CPoint クラスオプジェクトは以前のマウス位置を収 めている。 m-bCaptured テータメンバ この論理値変数はマウスの追従中は TRUE に設定される。 SetCapture と ReleaseCapture メンバ関数 & ℃ゆは C ル〃のメンバ関数で、たとえマウスカーソルがウインドウの外部にあっても、マ ウス移動のメッセージがウインドウに送られてくるようにマウスを「捕捉する」。この関数の不幸な 波及効果として、円はウインドウの外に移動され、「失われてしまう」ということがあるが、後で この問題をどのように解決するかを示す。必要、かっ望まれる効果は、 WM_LBUTTONUP メッ セージを含むすべてのマウスメッセージを継続してウインドウに送ることである。さもなければ失 われてしまう。召ん eC ゆはマウスの捕捉を解除する。 SetCursor と LoadCursor Windows 関数 クラスライプラリはいくつかの Windows 関数を「囲みこんで」いない。そういった Windows 関 数を呼び出すときは、規約により C 十十のスコープ指定演算子 ( : : ) を使用する。今回は、 C 怖召メ ンバ関数との衝突の可能性はないが、クラスメンバ関数の代わりに同じ名前とパラメータの型を持 つ Windows 関数を呼び出すために、慎重に選択した方がいい。この場合 : : 演算子は、グローバル なスコープで Windows 関数を呼び出すことを保証する。 最初のパラメータが NULL の場合、ん 0 〃 C s 関数は、事前に定義されている Windows が用 意したマウスカーソルの中から「カーソルリソース」を指定、作成する。 & ℃ s 関数は指定され たカーソルリソースを有効化する。このカーソル指示はマウスが捕捉されている間、継続する。 ・ C. 召オプジェクトから CPoint オプジェクトを減算 ・ CRect オプジェクトに CPoint オプジェクトを加算 ・ CPoint どうしの減算により、 CSize オプジェクトを生成 ・ CPoint オプジェクトから CSize オプジェクトを減算 ・ CPoint オプジェクトに CSize オプジェクトを加算 の間では、以下のことが実行できる。 ロード演算子 ( オーバーロード演算子は付録 A で説明している ) を持っていることがわかる。これら クラスライプラリリファレンスを見れば、 CRects CPo / 厩、 CSize クラスはたくさんのオー CRect 、 CPoint 、 CSize の算術操作 83 ノヾ