ホーム < ゲームつくろー！ < DirectX技術編 < 高速フォント表示
その５ 高速フォント表示
この章のサンプルプログラムはこちら
Direct3Dはフォントの扱いが苦手です。一応画面に簡単に文字を出すためのID3DXFontインターフェイスがありますが、背後でWindows APIを用いてフォント形状を取得しているので、描画が異常なほど遅いのです。あまりに遅くて、特にノベルス系のように画面にフォント文字が沢山出て来るゲームではまともに使えません。
ID3DXFontを介して描画するのがなぜ遅いのか？それは、1フレームごとにフォントを一から作成して描画しているためです。フォントの情報を得て、それを点の情報に変換して画面に打つ。これでは、どれだけ頑張ったって速度は出ません。ところで、DirectXは「絵」の描画については異常な程高速です（それがDirectX最大の売りですよね）。ということは、フォントを毎回「打つ」のではなく、フォントの絵を「描画」すれば、高速なフォント描画があっさりと実現できるわけです。
2008.05.29
今まで何回も取り上げてきた「マイクロフォーマット」ネタですが、Allsopp本の翻訳が
マイクロフォーマット Webページをより便利にする最新マークアップテクニック
というタイトル（仮題）で毎日コミュニケーションズから出版されるようです。情報元は「Web標準Blog」で、監修の木達一仁氏が関わっている会社です。
ちなみにセミナーも Allsopp 氏来日に合わせてあるようですが、これは満員御礼だそうです....
やはり関心ある人多いでしょうね...本は「買うべし」です（ただしエントリ時点で毎日コミュニケーションズの近刊予告には入っていないようです）
投稿者 : 杉浦 こずえ | 投稿日時 : 2008.05.29 12:33
2008.05.28
前回のエントリ...に限らず、私って平気で「コーラー側」という言い方をしてたのですが、"コーラー側" でググると、あまりコレ引っかからないのですね....
要するに
コーラー(caller) ＝（関数・メソッドの）呼び出し側
コーリー(callee) ＝（関数・メソッドの）呼ばれた側
のことを言います。あれぇ、私はプログラマの日常口語だと思ってたのですが、知らない人が多いみたいなのですね（まあ、「コーラー側」と使うと、「馬から落馬」みたいな冗語っぽいニュアンスがないではないですが）。
とはいえ、caller/callee は（明確な）技術用語で使われている箇所っていうのはあります。皆さんおなじみの JavaScript ですけども（まあ、他のスクリプト言語でも同様な実装があるのでは？）、関数の中で「隠し持っている（実際には関数呼び出し時にセットされる）」arguments というオブジェクトがあります。これは「その関数の呼び出し環境（スタックフレームみたいに考えて良さそうです）」を示し、名前の通り「その関数に渡された引数」を配列として持つのが本来の役割です。しかし、この arguments オブジェクトには、caller と callee という２つの重要なプロパティがあります。
JavaScript の arguments オブジェクトの
callee プロパティ： 現在実行中の関数オブジェクトを示します。
caller プロパティ： この関数を今呼んでいる「呼び元の関数の arguments オブジェクト」を示します。
というように、このargumentsはうまく使うとかなり面白いことができます。arguments オブジェクトはJavaScript 関数の汎用カリー化関数とかで「任意数の引数を再適用する」ところで使ってたおぼえもあります...たとえばですね、JavaScript では「無名の関数」を function() {} などで作ることができますが、この「無名の関数」内で、再帰呼び出しをしたい場合
.....あれ、名前がないから再帰で呼べない...
となりますけども、実はこれ、callee プロパティを呼べばいいのです。
function show(n,m) {
alert( function(x) {
if( x > m ) return x * arguments.callee(x-1);
return 1;
}(n) );
}
n!/m! を再帰的に計算するルーチンならば、こんなところでしょうか。show() の内部で再帰計算をする無名関数を作って、それを引数 n で起動した結果を alert() しています。m の束縛はいわゆるクロージャです。あるいは、caller を使うと、スタックトレースが取れます.....しかし、この caller は JavaScript 1.5 では deprecated の扱いのようですが（がまだIE/FireFox共に動きますね！よかった...）
まあ、この caller/callee というプロパティは「スタックフレームへの参照」ですから、どんなスクリプト言語でも、「言語設計者が実装しようと思えば装備できる」プロパティです（逆に言うとかなり初期からこれを持つ発想のあった JavaScript の設計は評価すべきでしょう。参照方法はともかく、アイデアいいです）。同じようなプロパティが他の言語にもある可能性は高いですね....
そう考えてみたら、プログラマ用語として「コーラー・コーリー」を使う...というのはけして珍しいこと、とまでは言えないのでは？と思います。個人的には時代遅れになってなくって良かった（苦笑）....
投稿者 : 杉浦 こずえ | 投稿日時 : 2008.05.28 12:12
2008.05.27
書き出した時点で、お昼休憩中です。皆さんお昼ご飯はいかがでしたか？お昼ご飯代はおいくらでしたか....という話では、残念ながらないです（ちなみに私は大概会社の近くの自宅に帰ってお昼ご飯です。今日は昨日の残りモノで、鳥ごぼうご飯と、アスパラのおひたし、大福豆、大根おろし＋金山寺味噌というメニューでした）。
お昼ごはんはタダではいけません！ というのは、有名なＳＦネタのジョークです。「ノーフリーランチ定理」と呼ばれる面白い定理があります。それは、
数学的にありうべき全ての問題の集合について、どの探索アルゴリズムも同じ平均性能を示す
と主張します。結構意外じゃないですか？
プログラマ、というと「このアルゴリズムは性能がいい／悪い」というのを肌で知ってる...というのが望ましいですけども、しかし、それは「日常に現れる一般的な問題」の場合に「性能がいい・悪い」という議論をしているだけなのです。プログラマだったら、「いいアルゴリズム」がデータによって「ウラをかかれ」た経験があるんでは..と思います。たとえば、速いアルゴリズムの代表であるクィックソートは、すでに整列したデータを与えた時に、O(n2 ) にまで性能が劣化します。勿論「ホントにいいアルゴリズム」の場合は「最頻のケース」と同様に、「最悪のケース」に対する備えを心がけるべきなのですが....
このノーフリーランチ定理を言い換えると、
あらゆる問題で性能の良い汎用最適化戦略は理論上不可能であり、ある戦略が他の戦略より性能がよいのは、現に解こうとしている特定の問題に対して特殊化（専門化）されている場合のみである
ということになります。「よくある場合に性能がいい」と「ウラをかかれると性能が悪い」とは同じことの両面に過ぎないことをこの定理は示すのです。汎用的であればあるだけ、「最良の場合の性能」は悪化してしまいます....汎用性と特殊性のせめぎあい、というプログラマがいつも頭を悩ます問題というのは、回避不可能な本質的な問題なのです。
これはもっと広く考えて、問題とその解決法、という視点で考えるのも面白いでしょう。問題を「汎用的に解決する」のは非常に難しいわけです。
人生、宇宙、すべての答え
という極めつけの「汎用的な問い」への答えを要求された銀河最高のコンピュータ「ディープ・ソート」は、
42
という極めて「汎用的な答え」を返します（詳しくは「銀河ヒッチハイクガイド」を...）。「42」は答えに違いないのでしょうが、それは人間にとって「利用可能な答え」ではありえないのです....「汎用的」なのがいつもいつも正しいわけではないのです。
投稿者 : 杉浦 こずえ | 投稿日時 : 2008.05.27 13:48
まずはストレートに「オブジェクトとは何か」という問いを発してみましょう。 これは難問です。そして人によって解釈の違う概念でもあり、「これで正解」 というものがないのも実状です。しかし敢えてこの問いに一つの答えを出して みたいと思います。
「オブジェクト」とは日本語で言えば「もの」です。しかし「もの」というだ けではそれこそ何でもオブジェクトになってしまいます。「何でもオブジェク トだ」という見方も一つあるのですが、ここではそれに「アイデンティティー」 という考え方を導入したいと思います。 「アイデンティティー」は日本語では「自己同一性」と訳されますが、「それ がそれであること」です。人間で言えば「自分が他の人とは区別された自分自 身であること」です。そしてアイデンティティーを備えた「もの」こそが「オ ブジェクト」なのです。
例えば薬局に錠剤の入った薬瓶が並んでいる所を想像して下さい。それぞれの 薬瓶には名前の書かれたラベルが貼ってあり、錠剤がたくさん入っています。 これらの薬瓶は取り換えの効かないものです。頭痛薬の入った瓶と胃腸薬の入っ た瓶は混同してはいけないものですし、同じ薬の入った瓶でも中身の多いもの と少ないものではまた違います。こういう、それぞれの瓶が他の瓶と取り換え が効かない固有の特徴を持っているという状態が「アイデンティティー」を持 つということです。それに対してその中身はどうでしょう？瓶の中には同じ 薬の錠剤がたくさん入っていますが、どの錠剤も他の錠剤とまったく同じで取 り換えが効きます。これがアイデンティティーのない状態です。
アイデンティティーのあるなしを見分けるには、「個体が識別できるかどうか」 を考えるとよいでしょう。アルバイト店員が薬剤師に「薬瓶を持ってきて」と 頼まれたとしましょう。アルバイト店員が「どの薬瓶ですか？」と聞くと、薬 剤師は例えば「一番上の棚の右から3番目のところにある『アスピリン』と書 いてある瓶を持ってきて」というように答えるでしょう。薬剤師は指定した場 所にある特定の薬瓶を持ってきてほしいのです。
私は、テストプログラムを作成して、Auxiliary Storage(LocalPageデータセット)を溢れさせてみました。その時の状況をSYSLOGに表示されたメッセージを元に解説します。
まず、Auxiliary Storage Shortageとは、使用率が70%を超えた状態の事を指します。Auxiliary Storageの使用率が70%を超えると、MVSシステムMVSはIRA200Eを出力し、LOGON,MOUNT,STARTコマンドが全て失敗させ、新しいアドレススペースを作成しません。稼動中のタスクも、Swapout中のJOBはSwapinする事が出来ません。一部のJOBは強制的にSwapoutされます。さらにGetmainを要求するJOBのほとんどは停止してしまいます。
| ", r, g, b ); if ( r + g + b > 384 ) printf( "" ); else printf( "" ); printf( "0x%02X%02X%02X", r, g, b ); printf( " |
2006/01/24
■オラクルマスターシルバー SQL/Oracle入門
初めてのベンダー試験。
たぶん大丈夫だろう、と思って試験当日。
何気に難しくないか？SQLが複雑なんですけど・・・。
結果。
14/20
あぶねぇ、ぎりぎりだ。受験料15,000円が吹っ飛ぶところだった。2004/07/10
オラクルマスターシルバー Oracle入門
SQL試験で危機感を感じ、念入りに勉強した。
前回の結果で不安を残しながら受験。
・・・え？こんなんでいいのか？
２０分ちょっとで退場。
20/20
・・・こっちはそれほど難しくないみたい。2004/08/21
hatena1989さん
とりあえずおかしな点を指摘すると、
> 標準モジュール(Uniting)
> Function Uniting(BookNumberb As Integer, BookName As String, Author As String)
モジュール名と関数名に同じ名前は使えません。
モジュール名を Uniting 以外に変更しましょう。
> フォーム
> Public Sub 登録_Click()
>
> Dim BookName As String
> Dim Author As String
> Dim BookNumber As Integer
> Dim BookInfo As String
この BookInfo は 登録_Click内で使用してないので不要です。削除しましょう。
> 標準モジュール(Uniting)
> Option Compare Database
> Option Explicit
> Public BookInfo As String
本パッケージ"RDE-eXtended Archiver"（以下「RDE-XA」という）には、日本オラクル株式会社のプログラム（「OracleDatabase Standard Edition 10gR2」）がバンドルされています。 そのためRDE-XAの使用においては、下記の条件が追加されます。
STLASYK by iijima vf̃\[g(1) sort, stable_sort / list::sort STLł͂‚̃\[g̃ASYD ł́Csort stable_sort Ƃ肠D vg^CvF void sort( RandomAccessIterator beg, RandomAccessIterator end ); void sort( RandomAccessIterator beg, RandomAccessIterator end, BinaryFunc op ); void stable_sort( RandomAccessIterator beg, RandomAccessIterator end ); void stable_sort( RandomAccessIterator beg, RandomAccessIterator end, BinaryFunc op ); [beg, endj͈̗̔͂vfŕԂ悤Ƀ\[gD 1Ԗڂ̌`̃\[g̊'< Zq'łD "< Zq"trueԂꍇ̍Eӂ̊WCӂEӂuvƌȂC\[g͈͂ vfuvɐ̂ƂȂD ̐͌Ƃ͌ȂDC++ł̓NX̃IuWFNgɓKpWZq̏e̓[U[`ł邽߁C "< Zq"KIuWFNǵu召Wv肷̂łƂ͌Ȃ炾D ɂ́C\[g͈͂́C͈͓̔̔Cӂ2vfɂ‚āCV[PXɂ鑊ΓÎ̂ӁC Ô̂EӂƂƂ'< Zq'̉Zʂ false ł悤ȏԂɂȂCƌׂ낤D 2Ԗڂ̌`ł́C3ɓn2qƂă\[gD Ō2qƂ́C1Ƒ2̊W̔茋ʂboollŕԂ܂͊IuWFNĝƁD sortstable_sorẗႢ͎̂ƂD sort ϓIn~log(n)̕GۏD vf̑ΓIۂ邱Ƃ͕ۏȂD stable_sort n~log(n)̕Giɏ\ȋeʂȂꍇn~log(n)~log(n)j vf̑ΓI͕ۂD ȉ̃Tvłsort̂ݗp邪C List 1`4, 6ɂ‚ẮC"sort""stable_sort"ɒuĂʂD yPzftHg̃\[g yQz\[g̐ݒ`O`2q yRz\[g̐ݒ`[U[`2q y zXg̃\[g yPzftHg̃\[g \[g̃ftHg̃\[g'< Zq'łD RNV̗vfgݍ݃f[^^̏ꍇ͏il̏ȏjŃ\[gD // List 1 #include#include #include int main() { std::vector< int > seq; for( int i = 0; i < 10; ++i ){ seq.push_back( i ); } std::random_shuffle( seq.begin(), seq.end() ); std::cout << "\[gOF"; std::copy( seq.begin(), seq.end(), std::ostream_iterator< int >( std::cout, " " ) ); std::cout << std::endl; std::sort( seq.begin(), seq.end() ); std::cout << "\[gF"; std::copy( seq.begin(), seq.end(), std::ostream_iterator< int >( std::cout, " " ) ); std::cout << std::endl; } s()F \[gOF8 1 9 2 0 5 7 3 4 6 \[gF0 1 2 3 4 5 6 7 8 9 RNV̗vf̃f[^^NX̏ꍇCYNX̃IuWFNgԂ̊W肷'< Zq'`ĂC Ƃă\[gD ႦCstd::stringIuWFNg𗼕ӂƂ'< Zq'͎ɂOW̔茋ʂԂ̂ŁC std::stringIuWFNgvfƂRNVsortKpꍇCŃ\[g邱ƂɂȂD // List 2 #include #include #include #include const char* STATIONS[] = { "Ueno", "Nippori", "Kitasenju", "Matsudo", "Kashiwa", "Abiko", "Toride" }; int main() { std::vector< std::string > stations; for( size_t i = 0; i < sizeof( STATIONS ) / sizeof( char* ); ++i ){ stations.push_back( std::string( STATIONS[i] ) ); } std::cout << "\[gOF"; std::copy( stations.begin(), stations.
java.lang.Object java.beans.EventHandler
public class EventHandler
EventHandler クラスは、受信イベントオブジェクトとターゲットオブジェクトを含んだ単純な文を実行するメソッドを持つ、イベントリスナーの動的生成をサポートします。
EventHandler クラスは、開発者が Bean 間の接続を確立するために使用する、アプリケーションビルダのような対話型ツールで使用されます。通常、接続は、ユーザーインタフェース Bean (イベントソース) からアプリケーションロジック Bean (ターゲット) に向けて確立されます。そのなかでも、ユーザーインタフェースからアプリケーションロジックを隔離するような接続は特に効果的です。たとえば、JCheckBoxとブール値を受け付けるメソッドを接続する EventHandler は、チェックボックスの状態を抽出し、これを直接メソッドに渡すことによって、メソッドをユーザーインタフェース層から隔離することができます。
ユーザーインタフェースを使ったイベントの処理方法としてより一般的なのは、内部クラスを使用する方法です。EventHandler クラスで処理できるのは、内部クラスで処理できるイベントのサブセットに過ぎません。しかし、長期持続スキーマでは、内部クラスよりも EventHandler のほうが優れています。また、同じインタフェースを実装している大規模なアプリケーションで EventHandler を繰り返し利用すれば、ディスクやアプリケーションのメモリーフットプリントを削減できます。
EventHandler で作成されたリスナーのフットプリントが小さいのは、このクラスの依存先の Proxy クラスが同じインタフェースの実装を共有しているからです。たとえば、EventHandler create メソッドを使ってアプリケーション内のすべての ActionListener を作成する場合、すべてのアクションリスナーは、単一のクラス (Proxy クラスによって生成されたクラス) のインスタンスになります。通常、Proxy クラスのリスナーを使用する場合は、「リスナー型」(インタフェース) ごとにリスナークラスを 1 つずつ作成する必要があります。しかし、内部クラスを使用する方法では、リスナー (インタフェースを実装するオブジェクト) ごとにクラスを 1 つずつ作成するだけで済みます。
通常、EventHandler のインスタンスを直接扱うことはありません。その代わりに、EventHandler の create メソッドを使って、指定されたリスナーインタフェースを実装するオブジェクトを作成します。このリスナーオブジェクトは、内部で EventHandler オブジェクトを使って、イベントに関する情報、イベント発生時にメッセージを送信されるオブジェクト、送信されるメッセージ (メソッド)、メソッドの引数をカプセル化します。次では、例を使って、create メソッドによるリスナーオブジェクトの作成方法について説明します。
Objective-Cの学習においてメモリ管理はひとつの壁であると言えます。そこでその対応策としてAppleはObjective-C 2.0においてガベージコレクションと呼ばれる「メモリ管理をプログラマが一切しなくて良い機能」を搭載しました。しかし残念なことにiPhoneアプリケーション開発用のObjective-Cではまだガベージコレクションが使えません。これはガベージコレクションがCPUのパワーをある程度必要とするからで携帯電話に搭載されているCPUには少し荷が重たいからです。しかし今後iPhone用アプリケーションの開発を考えておられる方は多いと思います。そこで本書では第12章までは基本的にガベージコレクションを使わずにiPhoneアプリケーション開発にも使える従来のメモリ管理方法のリファレンスカウンタ方式を使って学習を進めていきたいと思います。
なおリファレンスカウンタ方式からガベージコレクション方式に変更することは非常に簡単です。コンパイラの設定をガベージコレクションを使用してビルドするように変更するだけです。設定方法は第2章4節のMyBrowserですでに説明しております。
この節では最初になぜメモリ管理が必要なのかを説明して続いてリファレンスカウンタ方式を中心に説明していきます。一方、ガベージコレクション方式のメモリ管理方法を採用する設定はとても簡単です。この基礎編ではガベージコレクションを採用する方法だけを説明いたします。ガベージコレクションの詳しい仕組みについては実践編で説明しております。
残念ながら、このサイトでは「実践編」は掲載しておりません。ご了承ください。
オブジェクトが登場するまでは変数は大まかにグローバル変数とローカル変数の2種類に分かれていました。そしてグローバル変数はアプリケーションが起動中ずっとメモリを占有し続けます。グローバル変数にとってはそうすることが当然の責務だからです。一方、ローカル変数はメソッド（関数）内で作成されそのメソッドが終了する時に自動的に破棄されます。メソッドは何度も呼び出される可能性がありますがローカル変数はそのたびに作成されそのたびに破棄されます。この状況では特に問題が出ることはなかったわけです。
ところがObjective-CなどのOOPが登場した時に状況は一変します。OOPで新しく登場したオブジェクトはポインタ経由で取り扱うことを前提として設計されました。ポインタというのがそれほど便利であったのとデータの大型化が理由だと思われます。この場合メソッドが呼び出されてローカル変数が作成される時にオブジェクトのローカル変数はポインタとして作成されます。そしてメソッドが終了する時にローカル変数として作成されたポインタは自動的に破棄されます。しかしポインタにアドレスを代入する形で生成されたオブジェクトはメソッドの外側（スコープ外）に作られています。したがってメソッドが終了しても自動的に破棄されることはありません。さらに最悪なことにそのオブジェクトと連絡を取るための唯一の手段であ� �たポインタはメソッド終了と同時になくなっています。このようにしてそのメソッドが呼び出されて終了するたびに使用されることのない無用なオブジェクトがメモリに残っていきます。この状態をメモリリーク（メモリ漏れ）と呼びます。メモリリークはそのままにしておくとそのアプリケーションが使用できるメモリスペースを占有するだけではなく、やがてシステム（OS）が使用するメモリスペースまで占有しシステムエラーを招くこところまで発展する場合があります。
アプリケーションが終了するときは、メモリリークとなったオブジェクトも含めて、そのアプリケーションが使用しているメモリはすべて破棄されます。このことは少し安心できる事実ですが、世の中には1年365日24時間稼働し続けているサーバープログラムも多数存在しています。そのようなプログラムにとってメモリリークは重大な問題となります。
すべてのインスタンスはリテインカウント（retain count）という値を持っています。直訳すれば保持カウントになりますが、日本では「リファレンスカウンタ（reference counter）」「保持カウント」「リテインカウント」など色々な呼び方がされています。これらはすべて同じことを表していますが、ここではリファレンスカウンタという呼び方で統一したいと思います。
例えば数値を 1から 10まで表示させたいとします。もっとも単純な方法は 1から 10まで 10回表示させる命令を書く事ですが、これではあまりにも無駄が多すぎます。 10個程度ならまだましですが 100回や 1000回になってしまったら手におえません。 しかしこんな場合に繰り返し命令を使用するととても簡単な記述で済ませる事が可能になります。
// 繰り返し行われる処理
}
[バックナンバーのトップへ] [Linux システム管理のトップへ]
こんばんは、うすだです。
登録したら、大抵は、そのページの URL を、自分でメモしておきます。
あとで、変更や解除をするときのために記録するわけですが、うっかり、 メモし忘れることが、たまにあります。
そんなところの登録を変更したり解除したくなったとき、 検索で見つかる場合もありますが、発見できないことも、 ごくまれにですが、あります。
登録したときの情報を、どこかで集中管理しておけばいいんだよなぁ…。
と考えていたときに、ふと思いつきました。
登録したら、自分のブログのどこかに(登録サイトが)トラックバックしてくれれば、 そこを参照するだけで済むのではないか、ということに。
ブログなんて、いまどきどこででも無料で作れますので、 あとは非公開のページにトラックバックしてくれれば、 すぐ実現できると思うのですが、いかがでしょうか。
…とまあ、アイデアとしてどうなのかさっぱりわかりませんが、 せっかく思いついたので、ここに記してみました。
書いてすっきりしたので、今週もはりきってまいりたいと思います。
24時間365日戦い続けるシステム管理者にとって、 自動化は永遠のテーマであると言えます。
自動化できる作業を、スクリプトを書いて cron で定期的に実行するようにできれば、 ネコの手も借りたいほどの忙しさが、緩和されます。
しかし、対話型のアプリケーションの場合、 本来人間が入力すべき文字をリダイレクトで渡しても、 うまく動作してくれないことが多々あります。
たとえば、telnet コマンドを使って、SMTP でメールを送りたいとき、
#!/bin/sh telnet localhost smtp << E-O-F HELO localhost MAIL FROM:というスクリプトを作って実行しても、SMTP のコマンドが、 タイミングよく渡されることはなく、満身の力を込めて振ったバットは、 虚しく宙を舞ってしまいます。
しかし、だからといって諦めていてはいけません。
ちゃんと、それを解決するための手段が、世の中にはあるのです。
せっかくあるのだから、それを使わない手はありませんよね。というわけで、今週は、対話型アプリケーションを自動的に実行するための方法を、 ご紹介したいと思います。
カラータグとして使えるRGB16進数とそのカラーサンプルを知ることができます。カラータグをコピーして貼り付けるだけで、さまざまな色をあなたのサイトで再現することができます。
ブラウザで名前が定義された「Color Name」140色とその16進数が記載されています。ネットで使われるポピュラーな色です。「Color Name」はRGB16進数と同じように、カラータグとして扱うことができます。また英語の色名辞典としても便利です。
JIS規格「物体の色名」を中心とした日本の伝統色300色の色辞典です。伝統色名と16進数(近似値)が記載されています。日本の伝統色の色名辞典としても楽しめます。
JIS規格「物体の色名」を中心としたカタカナ表記される慣用色285色の色辞典です。名と16進数(近似値)が記載されています。世界の伝統色の色名辞典としても楽しめます。
たとえばmdl_userの情報を見たければ以下のようにします
コンテナの creationPolicy プロパティを none に設定した場合、コンテナ内で MXML タグとして宣言されているコンポーネントは生成されません。代わりに、これらのコンポーネントを記述したオブジェクトが Array に追加されます。これらのオブジェクトは記述子と呼ばれます。createComponentsFromDescriptors() メソッドを使用すると、これらのコンポーネントを手動でインスタンス化できます。このメソッドは、Container 基本クラスで定義されます。
コンテナの createComponentsFromDescriptors() メソッドを使用して、コンテナのすべての子を同時に生成することができます。
createComponentsFromDescriptors() メソッドのシグネチャは次のとおりです。
container.createComponentsFromDescriptors(recurse:Boolean):Boolean
recurse 引数は、コンポーネントの子を再帰的にインスタンス化するかどうかを指定します。コンポーネントの子をインスタンス化する場合は、このパラメータを true に、子をインスタンス化しない場合は false に設定します。デフォルト値は false です。
単一ビューコンテナで createComponentsFromDescriptors() メソッドを呼び出すと、creationPolicy プロパティの値に関係なく、そのコンテナのすべてのコントロールがインスタンス化されます。
if 文は、「もし・・・なら」という制御を実現します。次の例では、もし a の値が 3 であれば、"a is 3." を表示します。
int a = 3; if (a == 3) { System.out.println("a is 3."); } else は、「さもなくば」を意味します。次の例では、もし a の値が 3 であれば "a is 3." を、さもなくば "a is not 3." を表示します。
int a = 3; if (a == 3) { System.out.println("a is 3."); } else { System.out.println("a is not 3."); } else if を繰り返して使用することもできます。次の例では、もし a が 3 であれば "a is 3." を、a が 4 であれば "a is 4." を、さもなくば "a is unknown." を表示します。
アプリケーション開発でデータベースを利用する新人プログラマに向けて、SQLおよびT-SQLを短期間で理解できるよう、開発現場ですぐに必要となる内容を中心に解説する。（編集部）
第5回を迎えた本連載ですが、過去4回の連載を経て内容が徐々に濃くなってきました。単純なSELECT文から始まり、関数の利用、グループ化による集計などをこれまでに取り上げています。今回は、前回取り上げた「GROUP BY」句によるグループ化機能の利便性をさらに高める「HAVING」句を取り上げます。
★クロス集計クエリの例★
関連：hatena chips (MS Access Tips/Sample and FC2Blog customize and etc...
列数が変化するクロス集計クエリと連結するフォーム
列名が変化するクロス集計クエリと連結するフォーム