|
The wxPython マニュアル
Pythonプログラムのための wxPython ガイド
目次 †紹介 †この文書はひとりのPythonプログラマによって其の善き友であるPythonプログラマのために書かれたwxPython GUIツールキットのガイドです。最初は(C++プログラマ向けに書かれた)wxWidgetの文書の簡単な翻訳でしたが、そこから次第に発展してきまし た。 そしてC++には何も悪いところはないのですが、。。。 やれやれ、あなたはどうしても言わせたいのですね。私はC++が嫌いです。それで私はPythonを使うのです。もしあなたがC++が大好きなら、 行ってwxWidgetの文書を読みなさい。もしあなたが、むしろPythonプログラマを念頭に書かれたガイドを望んでいるならこのガイドを読み進んで ください。もしこれがお気に召したら、新鮮なロースト仕立てのコーヒ豆、ダークチョコレート、幾ばくかのお金を 私にお送りくださるのにご遠慮は不要です。もっと良いのは、大量に私が書いたwxPythonについての本(Robin Dunnとの共著です）を購入して、あなたのお友達、親戚、同僚にお送りくださることです。 wxPythonとは? †wxPythonはPython プログラム言語のためのGUIツールキットの一つです。このツールキットはPythonプログラマが信頼性のある、高度な機能性をもったグラフィカル・ ユーザ・インタフェースを単純かつ簡単に作成することを可能にします。このツールキットはPythonの(ネイティブコードの）拡張モジュールとして実装 されています。この拡張モジュールはクロス・プラットフォームなGUIライブラリであるwxWidget, それはC++で実装されいますが、をラップしています。 PythonやwxWidgetsとおなじくwxPythonはOpen sourceです。つまりこのソフトウェアは誰にでも無料で提供されまた内部やその変更に興味のある誰にたいしてもソースコードが提供されています。そし て誰もが訂正やプロジェクトへの協力を寄与することができます。 wxPythonはクロス・プラットフォームなツールキットです。つまり同じプログラムを複数の異なるプラットフォーム状で変更なく実行可能です。 現在サポートされているプラットフォームは32ビットのMicrosoft Windows, 殆どのUnixあるいはUnix互換のシステム、そしてMacintosh OS X です。 言語がPythonですので、wxPythonのプログラムは簡潔で、簡単にかけ、容易に理解できます。 wxPython requirements †wxPythonを使い始めるために、以下の環境を準備しなければなりません。 MS-Windows †
Linux or Unix †
Mac OS X †
wxWidgetsとは？ †wxWidgets は複数のプラットフォームで利用可能なGUI(グラフィカル ユーザ インタフェース)とその他の機能をもった C++フレームワークです。現在のバージョン２はすべてのデスクトップ板のMS Windows, GTK＋/Unix, Motif/Unix, そして MacOSXで利用可能です。OS/2への移植が進行中です*2。 wxWidgetsはEdinburgh大学、人工知能応用研究所で内部的な利用のために開発が始められました。1992に初めて一般へ公開されま した。 バージョン２は大きく改良された版で、Juilan Smar, Robert Roebling, Vadim Zeitlin Vaclav Slavik等をはじめとする多くの方々が開発に参加しました。 用語に関する注意：この文書では、別に注記我無い限り、"MS Windows"はしばしばマイクロソフトWindowsに関連するすべてのプラットフォームに対して使われます。これには16ビット版や32bit版などの派生物を含みます。すべての商標は尊重されます。 Why another cross-platform development tool? †wxWidgetsはGUIアプリケーション開発に対する投資を最大限とする安価で柔軟性に富む方法を提供する ために開発されました。クロスプラットフォーム開発には既にいくつもの商用クラスライブラリが提供されていますが、 どれ一つとして以下の条件を満たすものはありません：
オープンソース ソフトウェアとしてwxWidgetは、ユーザからの意見、アイデア、バグ フィックス、機能強化 そして熱狂的な支持から多くのものを得ています。これはwxWidgetsに商用の競合ライブラリ、そして独立した開発 チームを持たないフリーなライブラリに対する大きな優位点となっています。また、個人や企業の変化に対するロバストネス を与えています。この様なオープン性とソースコードの利用可能性は数千行からなるアプリケーションコードの将来が 基礎となっているクラスライブラリの寿命に依存している場合には特に重要です。 バージョン２は一般性と機能の両面において以前のバージョンに比較して大きく進歩しています。其の結果 作成されるアプリケーションは一つのプラットフォームに依存したツールキット、Motif, GTK+ そしてMFC,を 用いて開発されたそれと殆どの場合区別がつきません。 プラットフォーム非依存のクラスライブラリを使うことの重要性は言い過ぎになることはありません。 GUIアプリケーションの開発には時間がかかるものであり、特定のGUIの寿命は全く保証されているわけではないの ですから。 プログラムが適切でないプラットフォームや利用者に向けて書かれていると、瞬く間に其のコードは時代遅れ のものになってしまいます。wxWidgetsはプログラマをそれらの変化の大風から守るのを助けてくれます。 wxWidgetsは、たとえばOLEに強く依存した プログラム等の様に、すべてのアプリケーションに対して適切と言う訳ではありませんが、GUIプログラムが通常 必要とする殆どの機能を提供しますし、付け加えてネットワークプログラムのサポート、ポストスクリプト出力 機能、HTML整形表示などの追加機能も提供してくれます。どうしても必要となればwxWidgetsを拡張することも 可能となっています。さらにwxWidgetはネイティブのAPIに比べて非常に明確で使い易いプログラム インタフェースを 提供します。プログラマは一つのプラットフォームについてのアプリケーションを作成する場合でも、wxWidgetsを 使う価値があることを知るでしょう。 wxWidgetsの機能を2,3のパラグラフにまとめることは不可能ですが、其の利点のいくつかを 以下に挙げてみます：
wxPython 概要 †wxPythonアプリケーションが進行するようにするには、App classを継承するクラスを定義し、 App.OnInit?メソッドを 上書きする必要がある。 アプリケーションはトップレベルのフレームあるいはダイアログウィンドウをもたねばならない。それぞれのフレームは一つあるいはそれ以上のPanel, SplitterWindow? あるいはその他のウィンドウやコントロール部品のクラスのインスタンスを含んでいてよい。 フレームはメニューバー、ツールバー、状態表示行、そしてフレームがアイコン化された時のアイコンを持つことができる。 パネルはControlクラスから導出されたクラスであるコントロール部品を配置するために使われる。コントロール部品はユーザとの やり取りのために使われる。ボタン、チェックボックス、選択、リストボックス、ラジオボタン、スライダーなどはコントロール部品 の一例である。 ダイアログのインスタンスもまたコントロール部品のために使われる。そして独立したフレームを要求しないという利点がある。 ダイアログボックスを作成し、様々なアイテムを作り出す代わりに、メッセージダイアログやファイルダイアログのような 共通のよく使われるダイアログのクラスを使うこともできる。 直接にウィンドウに描画することは決して無い。そのかわりにデバイス・コンテキスト(DC)を使うのだ。DCはClientDC, PaintDC, MemoryDC, PostScriptDC, MemoryDC, MetafileDC そしてPrinterDCの基礎クラスとなる。もしDCをパラメータとして持つ描画関数 があれば、これらのDCのどれでもをその関数に引き渡すことができ、其の結果おなじコードを使って異なるデバイスに描画を 行える。DC.DrawLine? やDC.DrawTex?などのDCのメンバ関数を使って描画を行える。ブラシ（Brush)やペン(Pen)とともにウィンドウ上の色(Colour)をコントロールする。 最新のアプリケーションスタイルではオンラインのハイパーテキスト ヘルプシステムをもっているだろう。このために、Help とそれをコントロールするためのHelpController? クラスを必要とするだろう。 GUIアプリケーションはすべてがグラフィカルな魔法の世界ではない。リストやハッシュ表といったデータ構造も必要となる。 我々はPythonを使っているのだから、wxWidgetが提供するデータ構造ではなく、 Pythonが提供するデータ構造(list, tuple, dict)を使うべきだ。同じことがデータベースに関連するクラスについても言える。 守るべき規則はこうだ：もし必要なことがPythonのデータ構造で直接に行えるなら、Pythonのデータ構造を使うべきだ。もし Pythonのそれを使うべきでない明確な理由があるなら、wxPythonはwxWidgetのクラスのラッパーを提供する。 同じプラットフォーム独立なファイル操作関数を必要とするだろうことは疑いようがない。ファイルパスのリストをPathList? を 使って管理し、検索するのは非常に楽であることを知るだろう。 その他のクラスのリストは"Classess by Category"のセクションを見て欲しい。 wxPythonが提供するユーティリティとライブラリ †コアとなるwxWidgetsライブラリのほかにも、更なるライブラリやユーティリティがそれぞれの配付パッケージに付属している。 これらのいくつかのものはcontrib階層の下におさめられている。"contrib"階層はメインのwxWidgets階層の構造を映し持っている。 'utils'階層も見て欲しい。これらのツールやライブラリについての解説文書を探す最初の場所はwxWidgetsの'docs'階層の下である。 たとえば、docs/htmlhelp/fl.chmなどである。 その他のユーザの寄付によるパッケージについてはwxWidgetsウェブページのContributionsページを見て欲しい。
import wx.lib.plot as plot でサンプルプログラムを起動することができます。Plotメニューでplotの機能を選択します。 wxPythonオブジェクトの生成と廃棄 †[Thissection needs to be reviewed.] App 概要 †Classes: wx.App アプリケーションの初期化 †wx.Appを継承したクラスで定義されるOnInit?メソッドが通常最小限のこととしてトップウィンドウを作成する。 OnInit?メソッドは処理を継続(True)すべきかあるいは終了(False)すべきかを示すブール値を戻り値として返す。 wxPythonにトップウィンドウを通知するためにはApp.SetTopWindow?を呼びます。 アプリケーションはすべてのウィンドウを閉じて終了する。アプリケーションが終了するためにはすべてのフレームが 廃棄されなければならない方、新しいフレームを作る際に可能ならば親フレームを使うことが推奨される。それによって トップレベルのフレームを廃棄するとその子供のフレームは自動的に廃棄されるからである。 別の方法としては、トップレベルのフレームのCloseEvent?ハンドラーの那珂で子供のフレームを明示的に破棄することもできる。 緊急寺にはwx.Exit()をアプリケーション終了の為に呼ぶことができる。しかし、通常はアプリケーションは自動的に終了する。 以下を参照のこと。 アプリケーションの破棄の例： import wx アプリケーションの終了 †通常アプリケーションは最後のトップレベルウィンドウが閉じられたときに終了する。これは通常予期された振る舞いであるし、 アプリケーションが単一のトップレベル ウィンドウをもつなら、Expt メニューコマンドに対する応答としてClose()を呼べばよい ということになる。この振る舞いを望まないなら、その振る舞いを変更するためにApp.SetExitOnFrameDelete?()メソッドを実行 してよい。このようなロジックはプログラムがメインループに入るまでは有効では無いことに注意してください。言い換えれば、 App.OnInit?のなかでダイアログを表示して、恐れること無くこのダイアログが閉じられた時、このときにはこのダイアログが最後のトップレベルウィンドウとなっていますが、アプリケーションを終了できます。 アプリケーションの終了に関する別の留意点はOnExit?メソッドです。OnExit?メソッドはアプリケーションの終了時にwxPythonがその内部データ構造を消去する前に呼び出されます。OnExit?を終了する前に自分自身が作り出したwxPythonのオブジェクトを廃棄しておくべきです。 たとえば次のコードはクラッシュするかも知れません： [Need examples of objects needing cleanup to keep app from crashing.] Sizer 概要 †Classes: wx.Sizer, wx.GridSizer?, wx.FlexGridSizer?, wx.BoxSizer?, wx.StaticBoxSizer?, wx.NotebookSizer?, wx.CreateButtonSizer?
wxPythonのクラス階層ではwx.Sizerクラスとその子孫として表現されるサイザー(Sizer)の一群はwxPythonにおいてダイ アログ中の コントロール部品の配置を指定する際に選択される方法となっている。それはSizerを使うことで視覚的に説得力のあるダイアログを プラットフォームに依存することなく, 其のコントロール部品のサイズやスタイルの際を考慮した上で、指定できるという能力に依っている。wxDesigner, wxcredit, XRCed , wxWorkshpといったエディターはSizerに強く頼ったダイアログを生成します、実際上 それによってユーザがプラットフォームに依存しないダイアログを妥協すること無くデザイするようにしむけています。 Sizerの基本的な考え方 †wxPythonのSizerが採用している配置アルゴリズムはJava's AWT, GTKツールキット、Qt ツールキットといったその他のGUIツールキットの配置システムと密接に関係しています。 このアルゴリズムではウィンドウ中に含まれる子ウィンドウはその必要とする最小の大きさと、親ウィンドウが変更されたときにそのサイズを変えることができるかをそれぞれ上位ウィンドウに報告すると言うアイデアに基づいています。 これは通常プログラマーがダイアログの初期の大きさを指定するのではなく、ダイアログ（ウィンドウ）にはSizerを割当て、 このSizerが推奨される大きさを答申すると言うことになります。Sizerはその子、それは通常のウィンドウであったり、空白であったり、別のSizerで会ったりしますが、に推奨される大きさを問い合わせます。それによってSizerの階層が作り上げられます。 wx.Sizerクラスはwx.Windowクラスから派生したものでは無いことに注意してください。このことで、Sizerはtab順序との相互作用がなく、スクリーン上の実際のウィンドウに比べて非常に少ない資源しか要求しません。 wxPythonとSizerの相性がよいのは、すべての構成要素はその最小サイズを報告し、アルゴリズムがプラットフォーム毎のフォントサイズの違いやウィンドウ（ダイアログ部品）のサイズの違いを問題なく取り扱えるということに依っています。 たとえば、もしLinux/GTKウィウジェットの標準フォントが全体のデザインとおなじくWindowsのそれより大きければ、ダイアログの初期サイズは自動的にLinux/GTKではWindowsにくらべ大きくなります。 現在のバージョンでは五つの異なった種類のSizerがwxPythonでは利用可能となっています。 それぞれは、ダイアログのなかにダイアログ部品を配置するある方法を表現するか、ダイアログ部品(あるいは別のSizer)の周りを 静的な箱で包む等の特別なタスクをみたすために用意されています。 それらのSizerは以下のテキストで一つ一つ説明されます。 以下のテキストで、それらのSizerを一つ一つ説明します。 共通の機能 †すべてのSizerはコンテナです。つまりこれらはダイアログ部品（あるいは複数のダイアログ部品）を配置するために使われ、Sizerは これらの部品を含んでいます。これらの部品はSizerの子供と呼ばれることがあります。 Sizerがどのようにこれらの子供を配置するかとは独立にこれらの子供はある共通の特徴を持っています: 最小サイズ †この最小サイズは通常コントロール部品の初期サイズと同じです。初期サイズは明示的にコントロール部品の生成子の sizeフィールドでしていすることもありますし、heightやwidthを-1と指定することでwxPythonに計算させることもできます。 一部のコントロール部品(たとえばチェックボックス）ではそのサイズを計算できますが、その他の部品（リストボックスなど）では自然なサイズが存在せず明 示的にサイズを指定する必要があることに注意しておきます。コントロール部品にはその高さを計算することはできますが幅を計算することはできないもの(た とえば一行のテキストコントロール部品）もあります。 [Need graphics] 境界 †境界は何も無いスペースです、ダイアログのなかのダイアログ部品を分けておくために使われます。 境界は周りすべてにあるかあるいは側面と任意の組み合わせ、たとえば部品の上下のみ、におくことができます。 境界の太さは明示的に指定しなければなりません、通常は5ポイントです。以下のサンプルは一つだけのダイアログ部品（ボタン）を 持つダイアログを表示します。ダイアログの周りには0, 5 , 10 ピクセルの境界があります: [Need graphics] 整列 †ダイアログ部品にはその最小サイズと境界の和より大きなスペースが割りあてられることがあります。 それぞれのダイアログ部品に対するどのフラグが使われたかによってダイアログ備品が利用可能な空間全体を使ってしまうか、この場合には最小サイズよりも大きなサイズに部品が広がることになる、また利用可能なスペースの中央に配置されるのか、 あるいは空間のいずれかの側に寄って配置されるのかが決められます。以下の例では水平ボックスSizer中に一つのリストボックスと 三つのボタンが配置されています。一つのボタンは中央に配置され、別のボタンは上部に整列され、最後の一つは最下部に整列されています： [Need graphics] 拡張因子 †Sizerが複数の子供を持ち、子供達が必要とする最小サイズと境界の和よりも大きな空間を割り与えられたとき、余分な空間を これらの子供達にどのように配分するかという問題が引き起こされます。これを解決するために、拡張因子をそれぞれの子供に 割与えることができます。拡張因子の規定値０は必要最小サイズより大きくなることは無いとの意味になります。 非負の拡張因子はすべての子供達の拡張因子の和に対する相対的な意味を持ちます。つまり、二つの子供がそれぞれ拡張因子１を 持てば、それぞれの子供部品は余分な空間の半分ずつを受け取ります。これは一方の部品の最小サイズが他方のそれに比べて大きいとか小さいとかに関係なく分 け与えられます。以下の例は三つのボタンを持ったダイアログを表示しています。最初のボタンは拡張因子１をもつので広がっています。その他の二つのボタン は拡張因子０を持つので、初期値の大きさのままです。 [Need graphics] wxDesignerでは、この拡張因子はOptionメニュから選択して設定できます。 BoxSizer? †BoxSizer?は其の子供部品を水平あるいは鉛直方向に一列に配置することができます。整列の方向はBoxSizer?のインスタンスを生成 する際のフラグによって指定されます。鉛直Sizerを使う場合には、それぞれの子供は、中央寄せ、左寄せ、右寄せのいずれかに 整列させられます。同様に、水平Sizerでは、それぞれの子供は中央寄せ、天井寄せ、底寄せのいずれかを選択できます。 前節で説明した拡張因子はメインとなる方向について適用されます。つまり水平Sizerを使っているときには、拡張因子は それぞれの子供がどれだけ水平方向に拡張可能かを決めています。次の例は前節の例と同じですが、box sizerが鉛直box sizer となっていることだけが違います： [Need graphics] 静的BoxSizer? †静的BoxSizer?はBoxSizer?と同じですが、静的Boxで囲まれている点だけが異なります。 例をご覧下さい。： [Need graphics] GridSizer? †GridSizer?は２次元のSizerです。すべての子供部品は同じ大きさを割与えられます。この大きさは最大の子供が必要とされる大きさ となります。この例では左下部にあるテキストコントロール部品がこの最大の子供となります。行の数あるいは列の数は固定となります。Grid Sizerは新しい子供部品が追加された際には、それとは異なる方向に伸びて行きます。 [Need graphics] 柔軟なGridSizer? FlexGridSizer? †別の２次元サイザがGridSizer?から導出されています。 それぞれの列の幅と行の高さは独立に最大の子供の最小限のサイズの要求量 から決められます。さらに、列と行は、もしSizerが要求したものとは異なる大きさを割り当てられた時、伸縮可能と宣言されることができます。以下の例は上記の例とおなじですが、FlexGridSize?を使っていることが異なります。 [Need graphics] ノートブック：NotebookSizer? †NotebookSizer? はノートブックと一緒に使われます。NotebookSizer?はノートブックのそれぞれのページのサイズを計算し、 ノートブックのサイズを最大のページのサイズに設定するとともにノートブックタブと周囲の飾りの追加のスペースも 追加します。 [Need graphics] BoxSizer?を使ったプログラミング †BoxSizer?の基本的考え方は、ウィンドウは大体において単純な基本的な形にそって並べられると言うものです。 典型的には水平あるいは鉛直の箱とそれらの階層的な組み合わせになっています。 れいとして、テキストフィールドを上部にもち二つのボタンを底部に持つダイアログを作ってみます。 これは上部階層のテキストフィールドを上部にボタンを底部に持つ列構造と、OKボタンを左にCancelボタンを右にもつ低位の階層の 行構造とみることができます。多くの場合（とくにUnixのダイアログと通常のフレームにおいてはそうですが）メインウィンドウはユーザによるサイズの変更が可能です。このサイズ変更はその子供部品にも伝えられなければなりません。 この例題ではテキストフィールドはダイアログとともに伸び縮みして、ボタンは同じ大きさにとどまるでしょう。 さらに、すべてのコントロールの回りに薄い枠領域が見栄えを良くするために付け加えられ、事態を悪くするために、 ボタンはダイアログの幅が変更されても、中央にとどまります。 | Add(*args, **kwargs) box sizerではboxは水平および鉛直のどちらの方向にも伸縮可能ですが、子供部品に不均等にその変更を配分することはお主な方向 (行boxでは水平方向）のみであるというのは、boxSizerの特徴のひとつです。 この例では、鉛直方向Sizerは高さの変更分のすべてをテキスト エリアだけに配分し、ボタンエリアには配分しないと想定されます。これはSizerに ウィンドウあるいは別なSizerを追加する際のproportionパラメータの設定によって決められます。proportion パラメータは０、このときウィンドウはサイズ変更不能、あるいは正の値をとります。いくつかのウィンドウがゼロでない値をもてば、値は、すべての重みの和 に対する相対値と理解されます。つまい二つのportionパラメータが１のウィンドウを付け加えるとこれらのウィンドウは等しく伸縮され、それらを持つ sizerのちょうど半分の伸縮量となります。 それでは、列Sizerが幅を変えたとき何をすべきでしょう。振る舞いは,Add()関数の第三の引数であるフラグで制御されます。 ０あるいはフラグの指定が無い場合にはBoxsierは元々の幅を保持します。wx.GROW(あるいはwx.EXPAND)が指定されるとSizerと ともに伸縮します。wx.SHAPEDフラグはウィンドウはアスペクト比を保持したまま比例してサイズを変えます。wx.GROWフラグが セットされていないとき、部品は利用可能な領域で整列されます。wx.ALIGN_LEFT, wx.ALIGN_TOP,wx.ALIGN_RIGHT, wx.ALIGN_BOTTOM, wx.ALIGN_CENTER_HORIZONTAL そして wx.ALIGN_CENTER_VERTICAL は名前が示す様に整列します。wx.ALIGN_CENTRE (wx.ALIGN_CENTERとしても同じ)は (wx.ALIGN_CENTER_HORIZONTAL | wx.ALIGN_CENTER_VERTICAL)と定義されています。既定の整列フラグはwx.ALIGN_LEFT | wx.ALIGN_TOPです。 既に触れた様に、sizerに属するどのウィンドウも境界（枠）を持つことができます。そして四つの辺のいずれが境界を持つかを、wx.TOP, wx.LEFT, wx.RIGHT および wx.BOTTOM の４つの定数 あるいは すべての方向を示す wx.ALL を用いて指定できます。 wx.NORTH, wx.WESTなども同様に利用可能です。これらのフラグは上記の整列フラグと二進数のorオペレータ(|)で組み合わせてAdd()メソッドの第三引数 に与えます。境界のサイズも知らせる必要があり、これはAdd()メソッドの第四引数となります。つまり、 sizerとその子供部品の振る舞いはAdd()メソッドの三つのパラメータでその振る舞いが完全に規定されるということになります。 [Show code and graphic here.] GridSizer? のプログラミング †GridSizer?ではすべての子供部品は二次元のテーブルに配置され、テーブルのすべてのフィールドは同じサイズに なります。つまり、フィールドの幅は最大の幅を持つ子供部品の幅で高さは一番高い子供部品の高さになります。 [Show code and graphic here.] FlexGridSizer?のプログラミング †FlexGridSizer?は子供部品を二次元のテーブルに配置します。一つの行に属するフィールドは同じ高さを持ち、一つの列に属する フィールドは同じ幅を持ちますが、GridSizer?とは異なり、すべての行あるいはすべての列が同じ高さあるいは同じ幅を持つ必要はありません。 [Show code and graphic here.] NotebookSizer?のプログラム †NotebookSizer?はNotebookクラスと連携して動作する特別なSizerです。 このSizerは子供部品を足すことが許されないというその他のsizerとはまったく異なったSizerです。 子供部品を足す代わりに、notebookSizerはNotebookにたずねます。 このSizerのなすべきことは、Notebookの最大のページのサイズを決定し、その調整された最小のサイズを上位のSizerに 伝えることです。 ノートブックページのサイズを調べるために、このページはそれ自身のSizerを持っている必要があります、さもなければNotebookSizer?はこのページを無視します。ノートブックのページはSetSizer?()メソッドを使ってそれ自身のSizerを割り当てます。 またSetAutoLayout?()メソッドの引数をTrueとすることで、自動レイアウトオプションを設定します。以下に NotebookSizer?の管理下におかれたノートブックページを追加する方法を示します。： [Show code and graphic here.] StaticBoxSizer? のプログラム †StaticBoxSizer?はBoxSizer?を継承して作られたSizerで、Sizerの周りに静的な箱を持っている。この静的な箱は別途生成 されなければならないことに注意しておいて欲しい。 [Show code and graphic here.] Dialog.CreateButtonSizer? †使い易さの為に、DialogクラスはCreateButtonSizer?(flags)メソッドを持っています。このメソッドは標準的なボタンが表示される標準ボタンSizerを生成します。以下のフラグをこのメソッドの引数に与えることができます。:
日付と時刻に関するクラスの概要 †wxPythonは日付や時刻を取り扱うのに強力なクラスの組み合わせを提供します。 DateTime?クラスがサポートする機能の一部を列挙すると：
すべての日付／時間クラスの一覧 †絶対的な時刻を表現するDateTime?オブジェクトの他に三つの主要なクラスがあります。そのほかにも二つの時間を表現するクラス、 TimeSpan?とDateSpan?が用意されています。 DateTime?クラスとともに使われるヘルパークラスもあります。指定された日が休日であるかどうかを決定するDateTimeHolidayAuthority?クラス、このクラスから導出され土曜と日曜だけが休日であるDateTimeWorkDays?クラスなど。これらの クラスの詳細については休日に関する議論を参照してください。 DateTime? クラスの特徴 †DateTime?クラスは時間をEpoch,それは1970年１月１日に通常は固定されています、からのミリ秒単位の符号付き数値で表します。 このEpochはクラスのユーザが気づくことはありません、とくにEpochより以前の日付はEpoch以後の日付と同じ様にうまく(あるいはまずく）処理されます。しかし、最善の時間の分解能は１ミリ秒に制限されることになります。 DateTime?オ ブジェクトのサイズは8バイトで、64bitsの整数として表現されます。ですからサポートされる時間範囲はおおよそ５億８千万年となります。しかしグレ ゴリオ暦のサポートの制限から紀元前4714年１１月２４日以降がサポートされています。（充分な興味があれば、これは変更される可能性があります。） 現在のところグレゴリオ暦だけがサポートされています。グレゴリオ暦の歴史的な導入、それは1582年10月15日ですが、以前に対しても、グレゴリオ暦を適用します。一般的に言って、歴史的なグレゴリオ暦の導入は国、あるは地域によって異なっています。将来の バージョンではユリウス暦がサポートされるでしょうし、やその他の暦(マヤ、イスラエル、中国など）のサポートも完全に排除されたわけではありません。 DateSpan? と TimeSpan? の差異 †絶対的な瞬間を表現するには唯一の論理的な方法しか無い、従ってDateTime?クラスだけが唯一サポートされている、が時間を 表現するのには少なくとも二つの方法がある。 まず、TimeSpan?に実装されている直接で、自ら意味のあきらかな方法である。TimeSpan?は二つの時刻の時間をミリ秒単位で表現 します。その様な時間をDateTime?に加えるあるいは引き去ることは意味がはっきりしたしかも高速な操作である。 しかし日常の生活に立ち戻るとカレンダーにいぞんした時間間隔の指定が使われます。たとえば、『ひと月後に」は当たり前に使われます。しかし、これはTimeSpan?の60*60*24*30 秒後でなないことは明らかです。たとえば2月15日の「ひと月後」は３月１６日でも3月17日でもありません（閏年かそうでないかによって） これがまた別の時間を表現するためのクラスDateSpan?が導入された理由です。このクラスは例のような操作を最も自然と思われる方法で取り扱います。しかしこのような種類の操作がいつもはっきりした意味を持っているわけでは無いことに注意が必要です。 例えば、1月31日のに「ひと月」を加えることを考えてみます。これは２月28日（あるいは２月２９日）を与えるでしょう。つまり、２月の最後の日と言うことで、存在しない２月３１日ではありません。もちろんこれが通常期待される結果ですが、２月２８日から おなじ「ひと月」を引き去ると結果は１月２８日であって、出発点の１月３１日では無いことに気がついて驚かれるかもしれません。 ですから、プログラムに自然言語を理解する機能を実装することを考えているので無い限り、DateSpan?ではなくTimeSpan?を使うべきでしょう。しかもこちらはより効率的です。しかし、「ひと月」後を理解することが必要な状況ではDateSpan?が有用でしょう。 「ひと月」後は単にDateTime?.Now() + DateSpan?.Month()となります。 日付計算 †日付について様々な操作を行うことができますが、すべてに意味がある訳ではありません。たとえば、日付に数を掛け合わせることには意味がありません。どちらかの時間間隔クラスに数をかけることは全く正当なことではあるのですが。 以下にできることを示します：
時間帯についての考察 †内部的には時刻はGMT(UTC)で保存されているが、おそらくそれぞれの人はその場所での時間帯で仕事をしているはずだ。この為に、 すべての DateTime?生成子と日付を分解する役割を担う設定子はそれらの値が其の場所毎の時間帯で表現された時刻であると仮定している。従って、DateTime?(1,DateTime?.Jan, 1970)はたまたま英国に居るのでなければ、DateTime? Epochに一致しない。 すべての日付成分（年，月、日、時、分、秒,...)を値として返すメソッドはデフォールトでは其の場所の時間帯での正しい時刻を 返す。従って、、一般的にいって自然な流れに従えば、自然で正しい結果が得られる。 これがあなたの望むすべてであれば、このセクションの残りの部分は飛ばしてよい。しかし、異なる時間帯で仕事をするなら、 このセクションを最後まで読む必要がある。 この(稀な)場合にも、DateTime? オブジェクトを生成するには其の場所の時間帯を使う必要がある。すなわち、DateTime?オブジェクトを生成／初期化する場合に使う時間帯、例えば太平洋標準時刻、を指定する方法は存在しない。 そうするためには、ToTimeZone?あるいはMakeTimezone?メソッドを呼び出して目的の時間帯に調整する必要がある。これらの関数の特別なばあいとして、ToGMTとMakeGMT が用意されている。これらは最も良く使われるであろうGMTでの日付を構築するために用意されている。 ある時間帯の値をオブジェクトに変換することなく引き出すこともできる。これは、時間帯が影響するすべてのメソッドの呼び出し時にTimeZone?引数を与えることで、達成される。日付要素を取り出すすべてのメソッドや日付の整形を行うようなメソッドがそのようなメソッドの例である。とくにFormat()に関連する一群のメソッドはTimeZone?パラメータを受け付けます。また、このメソッドはどのような時間帯での時間も簡単に印刷できます。 具体的な方法を示すのに残ったことはこれらのメソッドにパラメータとしてTimeZone?オブジェクトをどのように構築するかと言うことです。 明白な方法は、 時間帯のGMTからのオフセットの秒数を指定して構築することです。しかし通常は事前に定義された時間帯の名前を使います。あとは変換生成子が面倒を見てくれます。つまり、単に： wxDateTime? dt(...whatever...); printf("The time is %s in local time zone", dt.FormatTime?().c_str()); printf("The time is %s in GMT", dt.FormatTime?(wxDateTime?::GMT).c_str()); の様に書くだけです。 夏時間(DST) の取り扱い †DST (a.k.a. 'summer time') はいつも微妙な問題を含んでおり、管理者が適切に設定してあるはずのオペレーティング・システム に任せるのが最良です。残念なことに、標準ライブラリでサポートされていない範囲の日付を取り扱おうとすると、自分自身で 問題を解決するしかありません。 指定された年のDSTの開始と終了の日付を計算するための関数が用意されています。また、ある時刻でDSTの期間であるか否かを判定 するための関数も用意されています。しかしこれらの関数が絶対的に正しいと仮定することはできません、結局のところこれらの関数は片手で数えられるくらい の国々でしか意味を持ちません（DSTを採用している国についての情報を歓迎します）し、それらの国々についても規則はいつでも変更となる可能性がありま す。 時間帯を取り扱う関数もこれらの関数を使っています、ですから時間帯を取り扱う関数も同じ制限を持っています。 DateTime? と休日 †[TODO] クラス †Not done yet. ID 定数 †wxPythonは以下に示す定義済みのID定数を持っている：
Source document †The source document is named wxPythonManual?.txt and can be found by clicking the link at the bottom of this page (assuming you are viewing the html file). It is written using a fantastic formatting convention called reStructuredText?. The wxPythonManual?.html file is created using the Docutils utilities, which can turn reStructuredText? documents into html, xml, pdf, and even OpenOffice? files. Submitting changes to the source document †Some items in the source text file look like this: .. This is text from the wxWidgets documentation that needs to be translated into something appropriate for the wxPython version. They have been commented out and are awaiting editorial review and a rewrite so that they make sense in the context of wxPython. Feel free to send me suggestions for rewording these, or any other parts of this document that you think need improving. I will be eternally grateful to you and will show my gratitude by adding your name to the list of contributors. (Contributors who also send me gifts of coffee, chocolate, or currency will have their names listed in bold.) コントリビュータ †この文書に協力いただいた方々のお名前(姓のアルファベット順） Individuals who contributed to this documentation (in order by last name): * Robin Dunn ライセンス †このドキュメントはwxWidgetsのドキュメントからの翻案として始められた。従って、wxWidgetsと同じライセンスが適用される。 以下にそのライセンスを示す。 This document began as a translation of the wxWidgets documentation. As such, it adheres to the same license, which is provided here: wxWindows Free Documentation Licence, Version 3 |
TestGridBagSizer.py
[詳細]
TestFlexGridSizer.py
[詳細]
TestGridSizer.py
[詳細]
TestStaticBoxSizer.py
[詳細]
TestBoxSizer.py
[詳細]
TestStretch.py
[詳細]
TestAlignment.py
[詳細]
TestListBox.py
[詳細]
TestButton5.py
[詳細]
TestButton10.py
[詳細]
TestButton0.py
[詳細]
TestTextCtrl.py
[詳細]
TestCheckBox.py
[詳細]
