【GUIライブラリ】wxWindowsでのひょーん
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG本家
http://www.wxwindows.org/
dW : Linux : wxWindowsの概要
http://www-6.ibm.com/jp/developerworks/linux/010413/j_l-wxwin.html
SunWorld Online：wxWindows――無名だが成熟したGUIツールキット
http://www.idg.co.jp/sw/back/200102/20010219_01_report.html
メルマガ
http://www.mag2.com/m/0000108320.htm
1はこれからインストールします
0002デフォルトの名無しさん
NGNG0003デフォルトの名無しさん
NGNG0004デフォルトの名無しさん
NGNG0005デフォルトの名無しさん
NGNG0006デフォルトの名無しさん
NGNGドキュメントを四苦八苦しながら読むと、ライブラリのコンパイルとか書いてあるので、
コンパイルしなきゃ使えないのかな、と思ったらそんななかったようです。
VCのincludeファイル参照に
<ライブラリを解凍したdir>\include
<ライブラリを解凍したdir>\contrib\include
libファイル参照に
<ライブラリを解凍したdir>\lib
<ライブラリを解凍したdir>\contrib\lib
を追加するだけでオッケーでした。
0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNGおまえ、
http://slashdot.jp/comments.pl?sid=92195&op=&threshold=-1&commentsort=0&mode=thread&startat=&pid=310367#310379
見て立ててみただけちゃうんか
0009デフォルトの名無しさん
NGNGゲームは関係無い。
0010デフォルトの名無しさん
NGNG天然UIとでた段階で読む気なくした。
0011デフォルトの名無しさん
NGNGMinGWでうまくコンパイルできなかった。
0012デフォルトの名無しさん
NGNG>非GUIクラスだけを含むwxBaseライブラリーも構築可能です。
>また、wxWindowsをDLLとしてコンパイルしていない場合にも、
>でき上がる実行可能ファイルは非常に小さくなります。 たとえば、
>最小のサンプル・アプリケーションをWindowsプラットフォーム用の
>Microsoft Visual C++ でコンパイルすると、 400 Kバイト未満になります。
最小のサンプルアプリでも400kb近くあんの？
0013デフォルトの名無しさん
NGNGDelphiとかMFCスタティックリンクに比べれば大したことないと思うけど。
0014デフォルトの名無しさん
NGNG0015デフォルトの名無しさん
NGNGつーかここコンパイラのスレじゃないでしょ。
0016デフォルトの名無しさん
NGNGとりあえずメルマガに期待か?
0017デフォルトの名無しさん
NGNG0018デフォルトの名無しさん
NGNGコンパイルし直せば、Windows、Linuxで使えるレベルまでいくのだろうか。
0019デフォルトの名無しさん
NGNGttp://www.wxwindows.org/cdrom2.htm
0020デフォルトの名無しさん
NGNG0021デフォルトの名無しさん
NGNG俺もメルマガ登録したけど、こういうのってすぐ配信が止まっちゃうんだよね。
モチベーションが続かないんだろうけど。
0022デフォルトの名無しさん
NGNG今度はグラフィック、ゲーム用フレームワークだって。
現時点ではLinuxに対応してない所が残念（開発中らしい）
0023の
NGNGスレ立ておつかれ
いいフレームワークですな、wxWindows。
"child's play. Well, almost."というのも納得。
ただしC++をまともに使えるガキがいればの話ですが。
日本語のドキュメントが少ないのが欠点ですなぁ。
あと、EUC-JP/SJIS <-> UTF-8とかの変換がデフォルトで
無いところとか
>6
色々と落とし穴があるので気をつけなされ
＃VC一般の話でもあるけど。
>7,9
ゲームに制限されない、つうのが正解ですな。やろうと思えば
OpenGLで3Dゲームも作れる。
>12
私の環境(VC++.net/最適化Off)で
GUI ON
wxAPP::OnInit()からfalseで抜けるだけ(Windowも作らない）
全部スタティックリンク（VCランタイムも使わない）
のプログラムは656KB……まあ、それなりかな？
>20
FOXって、まだ生きてるの？
0024の
NGNGWin2K + VC + wxWindows2.4でのインストール記書いたので、
上の環境の方は参考にしてくれ
http://www.debilotte.net/programming/wxWindows/index.html
GPLプログラム作るためのモノなんで、DLL不要のプログラムを作る
環境になっています。
だれか、Debian(sid)+Anjuta+wxWindowsでまともにプロジェクト
作れるヒトいる？
0025デフォルトの名無しさん
NGNG0026の
NGNG安心しろ。（日本だと）wxWindowsも少数派。
FLTKもいいツールキットだよね。前にAgenda VRでプログラムしたときに
使ったことがある。でも、FLTKって、MS-Winに対応していたっけ？
Xだけだった樣な気がするけど……
0027デフォルトの名無しさん
NGNG参考になる資料サンクス。
ちょっと触ってみよっかなぁ。
0028の
NGNGバリバリ現役ですな。 Fox 1.10.40出たばかりだわ。
http://www.fox-toolkit.org/
0029bloom
NGNG0030の
NGNG・対応プラットフォーム
-wxWindowsはMacに対応
・Linux上で必要になるライブラリ
-wxWindowsはGTK+/Motifが必要
・ライセンス
-wxWindowsはスタティックリンクしたバイナリをソース無しで配付可能
・ライブラリの対応範囲
・プログラムスタイル
-wxWindowsはクラスを継承してプログラムするスタイル。
main関数すら隠蔽しているし。
-wxWindowsはマクロをバリバリ使ってます。
かな？間違えていたらごめん。
wxPythonとかはあえてシカトしています。興味ないし。
0031デフォルトの名無しさん
NGNG0032デフォルトの名無しさん
NGNG0033の
NGNGUTF-8に対応しているので、多分8bitクリーンでしょう。
wxWindowsでこんなアプリ作ったけれど、文字化け等の問題は今のところ無し。
http://www.debilotte.net/programming/SaikoroPencil/index.html
ただ、（上でも書いたけど）EUC-JP/SJIS対応は甘いので、ICUとかと
併用したほうが無難かも。
（FAQでも解るけど）この程度の認識だしね。
http://www.wxwindows.org/faqmsw.htm#doublebyte
0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG0036の
NGNGhttp://www.wxwindows.org/manuals/2.4.0/wx448.htm#classesbycat
間違いあったら指摘ヨロ
0037の
NGNG◯window管理
ウインドウマネージャー（MS Windows, Motif Window Managerみたいなの）に直接コントロールされる種類のウインドウデス。フレームはたいていウインドウを含み、ダイアログボックスはたいてい直下にコントロールを含む。
wxDialog ダイアログボックス
wxFrame 一般的なフレーム
wxMDIChildFrame MDIの子フレーム
wxMDIParentFrame MDIの親フレーム
wxMiniFrame 小さなタイトルバーを持つフレーム
wxSplashScreen スプラッシュスクリーンクラス
※アプリ起動時などに表示されるアレ
wxTipWindow 小さなウインドウに文章を表示するヤツ
wxWizard ウィザードダイアログ
※アプリのインストールとかで出てくるアレ
コモンダイアログの項目も見るように
0038の
NGNG次のやつはwxWindowsがでっち上げた変種クラス
wxPanel 現在のユーザーのセッティングによって色が変化するウインドウ
wxScrolledWindow 自動的にスクロールバーを管理するウインドウ
wxGrid グリッド（テーブル）ウインドウ
wxSplitterWindow 水平方向や垂直方向にウインドウを分割するウインドウ
※２つの領域の間にあるバーで左右の領域の大きさの比率を変更できるやつ
※ペイン ウインドウで適当にGoogleてくれ
wxStatusBar フレームのステイタスバーを実装するやつ
wxToolBar ツールバークラス
wxNotebook ノートブッククラス
※いわゆるタブですな。
wxPlotWindow データを表示するためのクラス
※心電図みたいなやつだって
wxSashWindow ドラッグできる４辺の窓枠をもつウインドウ
※普通はウインドウに標準でついてますな
wxSashLayoutWindow 統合開発環境みたいなレイアウト調整ができるウインドウ
wxWizardPage ウィザードダイアログのページ部分のベースクラス
wxWizardPageSimple ウィザードダイアログのページ部分
0039の
NGNG概要
コモンダイアログはアプリケーションで良く使われる既成のダイアログクラスである
wxDialog コモンダイアログのベースクラス
wxColourDialog 色選択のダイアログ
wxDirDialog ディレクトリ選択ダイアログ
wxFileDialog ファイル選択ダイアログ
wxFindReplaceDialog テキスト検索／置換ダイアログ
wxMultipleChoiceDialog リストから１つ、又は複数選択するダイアログ
wxSingleChoiceDialog リストから１つだけ選択し、文字列を返すダイアログ
wxTextEntryDialog ユーザーから１行の文字列を受け取るダイアログ
wxFontDialog フォント選択ダイアログ
wxPageSetupDialog 一般的なページ設定ダイアログ
※メモ帳の「ファイル->ページ設定」を見てくれ
wxPrintDialog 一般的なプリンタ設定ダイアログ
wxMessageDialog 簡単なメッセージボックスダイアログ
wxWizard ウィザードダイアログ
0040の
NGNG普通、こいつらはユーザー（とプログラム）の相互作用をもたらす小さなウインドウだったりする。staticでないコントロールは、それらに対応するvalidatorをもつことができる。
wxControl コントロールのベースクラス
wxButton テキストが貼り付けられたボタンコントロール
wxBitmapButton ビットマップが貼り付けられたボタンコントロール
wxToggleButton ユーザーにクリックされると押されたままになるボタン
wxCalendarCtrl Date picker control
※ユーザーから日付に関する入力を受ける時に使うコントロールですな
wxCheckBox チェックボックスコントロール
wxCheckListBox チェックボックスがそれぞれのアイテムの左側に対ているリストボックス
wxChoice 選択コントロール（編集エリアの無いコンボボックス）
wxComboBox 編集エリア付きのChoice
※edit controlとlistboxを組み合わせた様なやつだって
wxGauge 変化する分量（例えば残り時間）を描写するコントロール。
wxGenericDirCtrl ディレクトリツリーを表示するコントロール
wxStaticBox お互いに関係のあるコントロール同士を視覚的にまとめるための、静的なまたはグループ化するbox
※原文のstaticてどういう意味？
0041の
NGNGwxListCtrl 多層カラムのレポートビューの文字列および／またはアイコンのリストを表示するコントロール
wxListView インターフェイスを簡単にするもの（wxListCtrlの報告モード用のファサード）
※ファサード(Facade)についてはGoFのデザインパターンを参照のこと
wxTabCtrl いくつかのタブをコントロールするコントロール
wxTextCtrl １つの行、または複数の行のテキストを編集するコントロール
wxTreeCtrl ツリー（階層）コントロール
wxScrollBar スクロールバーコントロール
wxSpinButton Spin、言い換えると『上下』コントロール
wxSpinCtrl スピンコントロール。spin buttonとtext controlを合わせた様なやつ
wxStaticText 編集のできない１つの行、または複数の行のテキスト
wxStaticBitmap bitmapを表示するコントロール
wxRadioBox ラジオボタンのグループ
wxRadioButton お互いに排他的に選択される丸いボタン
wxSlider ユーザーによってドラッグ可能なスライダー
0042の
NGNGwxMenu 選択されるメニューアイテムの一組を表示する
wxMenuBar フレームによって使用されるメニューの一組を収納する
wxMenuItem １つのメニューアイテムを描画する
0043の
NGNGウインドウ（とりわけダイアログ）のレイアウトを行う方法には２種類の
異なる方法が存在する。一つはsizerと呼ばれるものに基づいたもので、
タイピング量、思考、計算量の少ない、そしてたぶんほとんど全ての
ケースで、全てのプラットフォームでほとんど同じ外観をダイアログに
もたらす。
もうひとつがconstraintに基づくもので、よく非難されているけどまだ
利用可能だ。
Sizerの概要
これらはsizerに基づくレイアウトに関連するクラスだ
wxSizer 抽象基底クラス
wxGridSizer 全てが同じサイズのグリッドにウインドウをレイアウトするためのsizer
wxFlexGridSizer 柔軟なグリッドにウインドウをレイアウトするためのsizer
wxBoxSizer 行または列方向にウインドウをレイアウトするためのsizer
wxStaticBoxSizer wxBoxSizerと同じだが、static boxに覆われた sizer
wxNotebookSizer wxNotebook controlと一緒に使うsizer
Constraintsの概要
これらはconstraintsrに基づくレイアウトに関連するクラスだ
wxIndividualLayoutConstraint １つの制約された次元を示す
wxLayoutConstraints あるウインドウに対する制約を示す
0044の
NGNGこれで1/4かな？
続きは気が向いたら。
＃誰か続きしない？
0045デフォルトの名無しさん
NGNGwxStaticBoxのところは A static (box), or group box で
「static box、言い換えればgroup box」じゃないかと推測。
最初の部分は、wxValidatorの説明からいくと
「変数などとデータのやり取りが必要ない」という意味で「静的な」つーとこ？
「イベントによって動作を変える」という意味でも静的なのかもしれんが
wxCalendarCtrlとかあるからちょっと？ですな。
0046デフォルトの名無しさん
NGNGドラッグ＆ドロップと日本語入出力をサポートしていますか？
0047bloom
NGNG0048の
NGNGサンキュー。確かにvaridatorの説明を読むとそんな感じですな。
＃ValidatorはGoFのMediatorパターンを実装したものみたいですし。
Validatorはユーザーからの入力をフィルターするのを想定しているので、
「イベント〜」に見えるのかも。
>46
してます。
http://www.wxwindows.org/manuals/2.4.0/wx495.htm#wxdndoverview
0049の
NGNGあ、日本語入出力はそれぞれのOSの日本語対応に依存しています。
IMの仕組みはなさそうです。
＃意識しなくても普通に使えるから、それぞれのコントロールの裏で
＃処理されていると思うけど……
0050デフォルトの名無しさん
NGNG0051デフォルトの名無しさん
NGNG0052デフォルトの名無しさん
NGNG0053デフォルトの名無しさん
NGNGダサいけど実用的で良いね＞wxWindows
ScintillaとかOGLとか、使えそうな追加ライブラリがあるのもいい感じ。
0054デフォルトの名無しさん
NGNGデバイスコンテキストは、あなたの図面描画コードをパラメター化できるような
抽象的概念を提供する、描画可能な表面です。
(Device context overviewより：wxDCはグラフィックとテキストを描く事が出来る
デバイスコンテキストです。デバイスコンテキストは、様々な出力デバイスを
同様のAPIで包括的に利用できるようにします)
wxClientDC OnPaintイベント外でクライアントエリアにアクセスするためのデバイスコンテキスト
wxPaintDC OnPaintイベント内でクライアントエリアにアクセスするためのデバイスコンテキスト
wxWindowDC 非クライアントエリアにアクセスするためのデバイスコンテキスト
(クライアントエリアにもアクセス可能、ようするにウィンドウ全体にアクセスできる)
wxScreenDC スクリーン全体にアクセスするためのデバイスコンテキスト
wxDC デバイスコンテキストのベースクラス
wxMemoryDC ビットマップに描画するためのデバイスコンテキスト
wxMetafileDC メタファイルに描画するためのデバイスコンテキスト
(Windows only、デバイスコンテキストとして扱えるメタファイルオブジェクトを生成する)
wxPostScriptDC PostScriptファイルに描画するためのデバイスコンテキスト
wxPrinterDC プリンタに描画するためのデバイスコンテキスト
（Windows only、任意のプリンタとWindowsドライバへのアクセスを許可する）
OnPaintイベント = 再描画イベントと判断して良いかな？
省略思いこみ訳ですが。
次、Networking classesとかかしら。
0055デフォルトの名無しさん
NGNGドキュメントに関するライセンス事項（http://www.wxwindows.org/lic_doc.txt）
これって
4. Permission is granted to copy and distribute translations of this
manual or piece of documentation into another language, under the above
conditions for modified versions, except that sections related to
licensing, including this paragraph, may also be included in translations
approved by the copyright holders of the respective licence documents in
addition to the original English.
翻訳して公開する分には制約ないよってことだよね？
んで、このファイルの最初の所に書いてあることだけど
lic_doc.txt も一緒に配布してくれたらばっちりさ、ボブ！
ってことでいいのかしら？
0056の
NGNGつうことを言っているのかと……
※『このライセンス文を修正したものは除く（配付してはいけない）』
※つう例外はあるけど。
0057デフォルトの名無しさん
NGNGｻﾝｸｽｺ。がっつり翻訳してみます。
wxWindows 普及促進サイト作りました。
http://dot-gray.s33.xrea.com/index.html
0058デフォルトの名無しさん
NGNGおお、すばらしい！
あげ！
0059デフォルトの名無しさん
NGNG神降臨
ｷﾀ━(ﾟ∀ﾟ)━( ﾟ∀)━( ﾟ)━( )━(ﾟ )━(∀ﾟ )━(ﾟ∀ﾟ)━!!!!
0060動画直リン
NGNG0061デフォルトの名無しさん
NGNGマルチプラットフォームプログラミングが出来るような気がしてきた
0062の
NGNGおつかれ。
やっぱり、こういう風にまとまっているといいよね。
あと、細かい所だけど、
> Line 5-7 : #pragma hbrstop
#pragma hdrstop
だと思う……プリコンパイルに関連するpragmaですな。
0063デフォルトの名無しさん
NGNGうほ
お恥ずかすぃ。
0064デフォルトの名無しさん
NGNGやっとこさ、”wxWindows を使用したマルチ・プラットフォーム開発” の
http://dot-gray.s33.xrea.com/docs.org/wx10.htm#multiplat
半ばまで訳せましたよ。
お陰さまで私、精も根も尽き果てましたので
”プログラミング戦略”以下の 4 ファイル
http://dot-gray.s33.xrea.com/docs.org/wx22.htm
http://dot-gray.s33.xrea.com/docs.org/wx23.htm
http://dot-gray.s33.xrea.com/docs.org/wx24.htm
http://dot-gray.s33.xrea.com/docs.org/wx25.htm
誰か訳してください。
お願いします。
で、訳後ファイルを↓にうｐって下さい。
http://dot-gray.s33.xrea.com/cgi/upload.cgi
本当にお願いします。
僕はもう駄目です。無理です。
0065デフォルトの名無しさん
NGNG> Watcom C++ is automatic apart from the specification of the .pch
file. Watcom C++ is strange in requiring the precompiled header to be
used only for object files compiled in the same directory as that in
which the precompiled header was created. Therefore, the wxWindows
Watcom C++ makefiles go through hoops deleting and recreating a single
precompiled header file for each module, thus preventing an accumulation
of many multi-megabyte .pch files.
Watcom C++では、.pchファイルの指定を除いては自動的である。Watcom C++は、
プリコンパイルヘッダは、それが作られたのと同じディレクトリでコンパイルさ
れるオブジェクトファイルにのみ利用されるという点でヘンタイ的である。
であるから、wxWindowsのWatcom C++用makefileでは、それぞれのモジュールご
とにプリコンパイルヘッダを削除して作成しなおすという面倒なことをして、
.pchファイルが積もり積もって全部で何メガバイトにもなる事態を回避している
のである。
というところでどうでしょか。文体は丁度今見ているNHKの影響を受けている……。
006665
NGNGyour executable for icons (such as the Program Manager) find your
application icon first.
wx.rcのインクルードは、どのICONステートメントよりも*後に*行え。
それは実行ファイルを見てアイコンを探すプログラム(プログラム・マネージャ
など)が、貴君のアイコンを最初に見つけるようにするためである。
0067デフォルトの名無しさん
NGNG乙です。
翻訳ｱﾘｶﾞﾄｰ。
私、知らない環境の話になると、
英語力が足りなすぎて
ニッチもサッチも行かなくてとてもお困りでしたの。
ｻｿｰｸ直してきま
006865
NGNG> In general, classes derived from wxWindow must dynamically allocated
with new and deleted with delete. If you delete a window, all of its
children and descendants will be automatically deleted, so you don't
need to delete these descendants explicitly.
ふつー、wxWindowから派生したクラスはnewで動的にアロケートしてdelete
で逝ってしまわないといけないんだよもん。ウィンドウを削除したら、その
子も子孫も自動的に氏ぬから、こいつらを明示的に殺す必要はないもん。
# 難しい……
> When deleting a frame or dialog, use Destroy rather than delete so
that the wxWindows delayed deletion can take effect. This waits until
idle time (when all messages have been processed) to actually delete the
window, to avoid problems associated with the GUI sending events to
deleted windows.
フレームやダイアログを頃すにはdeleteじゃなくてDestroyを使ってくださいお
まいら。wxWindowsが、あぼーんの執行を送らせられるよーに。これは、ウィン
ドウの削除をアイドルタイム(全てのメッセージが処理されたとき)まで遅らせて、
GUIがあぼんされたウィンドウにイベントを投げちまうことによる問題を避ける
ためでつ。
> Don't create a window on the stack, because this will interfere with
delayed deletion.
ウィンドウをスタックに作るなゴルァ。削除の遅延が出来なくなるじゃねーか。
006965
NGNG> If you decide to allocate a C++ array of objects (such as wxBitmap)
that may be cleaned up by wxWindows, make sure you delete the array explicitly
before wxWindows has a chance to do so on exit, since calling delete on array
members will cause memory problems.
wxWindowsがあぼーんするかもしんないオブジェクト(wxBitmapとかな)のC++ の配列
(STLのarrayのことか?)をC++でアロケートするんなら、終了時にwxWindows がそうする
前に、絶対、その配列を明示的にあぼんすれ。配列のメンバについてdelete を呼ぶと
メモリの問題が発生するからな。
> wxColour can be created statically: it is not automatically cleaned up
and is unlikely to be shared between other objects; it is lightweight enough
for copies to be made.
wxColourは静的に作成できまつ。自動的に削除されず、オブジェクト間で共有されるこ
ともあんまないでつ。十分軽いのでコピー作ってもおkでつ。
> Beware of deleting objects such as a wxPen or wxBitmap if they are
still in use. Windows is particularly sensitive to this: so make sure you make
calls like wxDC::SetPen(wxNullPen) or wxDC::SelectObject(wxNullBitmap) before
deleting a drawing object that may be in use. Code that doesn't do this will
probably work fine on some platforms, and then fail under Windows.
wxPenやwxBitmapといったオブジェクトを削除する際は、それらがまだ使用中でないか
気を付けよ。Windowsはこの点にたいへんウルサイ。であるから、使用中かも知れない
オブジェクトを削除する前には、必ず、確実にwxDC::SetPen(wxNullPen) もしくは
wxDC::SelectObject(wxNullBitmap)を呼ぶようにせよ。これを怠ったコードはいくつか
のプラットフォームではちゃんと動くだろうが、Windowsではダメなんである。
文体バラバラや。推敲して下さい。
あと、見直して気付いたんですが>>65の「指定」は「仕様」かも知れませぬ。
長くてスマソ >皆様。
0070灰
NGNG65 氏、マジでグジョブ！
要点きちっっと抑えててすげーよ！
でも、一点だけ。
>>68
> classes derived from wxWindow * must * dynamically allocated
with new and deleted with delete.
wxWindowから派生したクラスはnewで動的にアロケートし、delete
で逝かせる * 必要 * があるんだよもん。
ここの must ははしょっちゃいけない気がするんだけど、
いかがでしょ？
漏れも長文ｽﾏｿ。
0072デフォルトの名無しさん
NGNG0073デフォルトの名無しさん
NGNG0074デフォルトの名無しさん
NGNGｶﾓﾝ ｶﾓｰﾝ
0075灰
NGNG清書してて気付いたので突っ込み。
1つ目の奴。
> wxWindows オブジェクトのC++配列は自分で削除せーよ。
ではなく、
> 自分で削除すんなゴルァ。wxWindows が削除するからほっとけよ。
じゃないかな？
mey be 〜 by wxWindows は、If you 〜 にかかってて
since 〜 memory problems は make sure you delete 〜 にかかってる？気がする。
>>65 は指定でいい思いまつ。
仕様にするとそれはそれで変になると思う。
なんか、話がとっ散らかっててしてｽﾏｿ。
0076デフォルトの名無しさん
NGNG0077の
NGNG>75
案１）の方がC++としては自然ですな。
C++では、ポインタの指しているオブジェクトが配列かそうでないかを
識別することができないんだよね。
＃詳しくはARMの5.3.4あたりを参照
オブジェクト配列を割り当てたのにdeleteを使用してしまった場合の挙動は
未定義（だいたいの場合はメモリリーク）になるから、『自分で始末しろ』て
いってんじゃない？
……delete[]した後にdeleteするのもなんかマズい気もするけど……
ポインタを0クリアする必要ないのかなぁ？wxObjectのdelete演算子で
0クリアするように実装しているのかな？
007854 = tofu ◆fS6u1o5e6Q
NGNGhttp://dot-gray.s33.xrea.com/cgi/upload.cgi にうｐりました。
誤訳の責任が他にいくと申し訳ないのでｺﾃ。
007965
NGNG清書おつかれさまです。
>>65の指定・仕様は、私もWatcom C++を知らんのでよくわからんのですが、
ヘンタイ的な仕様(とそれに伴う面倒)を指しているのかなと思ったのでした。
Watcom C++知ってる人のアドバイスきぼんぬ。
>>75,77
この文、やっぱり意味不明ですよねえ。
私のC++の知識はかなーり錆びててあやしいですが、もしかして、delete
explicitly は、まず手動で要素のデストラクタを呼んでdelete[]する、ことま
で言っていたりするんでしょうか。
あと、>>69の最後の訳文は、
Windowsはこの点にたいへんウルサイ。
→とりわけWindowsはこの点にウルサイ。
に訂正です。
0080デフォルトの名無しさん
NGNG共産党幹部宅で行われた鬼畜行為（裁判で明らかになってます）(監禁４１日間の内容)
・オイルを両大腿、膝、すねにたらして着火する
・熱がって火を消そうとすると手にもオイルをかけて着火、火が消えるとまた点火する
・性器に異物を入れて弄ぶ
・自分の尿を飲ます
・性器にライターを入れて着火する（この行為によって何度も気絶し、髪の毛が抜けていったという）
・性器を灰皿代わりにする
・性器にオロナミンＣの瓶を入れる
・お尻の穴に花火を突っ込む
・性器に強引に直径３Ｃｍの鉄の棒を突っ込んだり抜いたりして性器を破壊する
・頬が鼻の高さを超えるまで腫れ上がり、目の位置が陥没して分からないほどになるまで暴行
・歌謡曲を流して、歌詞にあわせて脇腹に思いっきりパンチをいれる
・痛さをこらえるので口が変なふうに歪むのを見て面白がる
・犯人２人の真ん中に立たせ、左右から肩や顔に回し蹴りを数発入れる
・顔にろうそくをたらす
・眉間に短くなった火のついたろうそくを立てる
・６ｋｇの鉄アレイを腹に落とす
・鉄アレイで大腿や顔面を殴る
・逃げないようにガムテープで全身をぐるぐるまきにする
コンクリート詰め事件で検索すればわかります。
アンチが騒いでます(w
http://qb.2ch.net/test/read.cgi/accuse/1052793624/l50
008165
NGNG乙です。んじゃ strategies for reducing programming errors と
strategies for portability を貼ります。それぞれ短いのでご容赦下さい。
プログラミングエラー低減の戦略
ASSERTを使え
私自身はwxWindowsで実行できていないのだが、ASSERTステートメントを
さくさく使うのは良い習慣だ。ASSERTは、成立すべき、ないしせざるべき
条件をチェックし、適切なエラーメッセージを出力する。これらは、
ノンデバッグ版のwxWindowsやあなたのアプリケーションからコンパイル時に
外すことも出来る。ASSERTの使用は、「防禦的プログラミング」の一例であり、
そのうちあなたに問題を警告してくれる。
文字配列よりもwxStringを使え
wxStringの使用は、char*の使用よりもはるかに安全でより有用である。
今度もまた、私自身は自分の説く道を実践できていないのだが、私も
今、可能な限りwxStringを使おうと努めているところである。あなたは
メモリリークの可能性を著しく低減でき、オーバーロードされた演算子
の使用は、strcmpなどの関数よりはるかに便利である。wxStringは、
プログラムにさほどのオーバーヘッドを与えない。オーバーヘッドも、
文字列操作がより簡便となったこと(つまりより少ないコードで済む
ということだ)によってチャラになる。
他のデータ型についても同様である。可能な限りクラスを使え。
008265
NGNG相対位置指定やSizerを使え
[訳注: Constraints positioningは既にobsoleteである。そのため、sizer
に置き換えて文章を構成した。容赦願いたい。]
出来うれば、パネルの要素の絶対位置指定はやめよ。GUIが異なればパネルの
要素の大きさも随分と違うのである。多少はプログラムの手間が増えるかも知れ
ないが、Sizerの使用を検討せよ。
別解として、プラットフォーム毎に、それぞれ少しずつ数値の違う別々の.
wrc(wxWindowsリソースファイル)を用意する方法もある。もしくは、問題を避け
るためにパネル要素の間を十分に空けよ。
wxWindowsリソースファイルを使え
可能な限り .wrc (wxWindowsリソースファイル)を使え。これは、ソースコー
ドとは独立に簡単に編集できる。ビットマップリソースはプラットフォームに
よって異なるビットマップをロードするようにも設定できる(リソースファイ
ルの項を見よ)。
~ ~ ~
たぶん、Windowsでもパネル要素の大きさは大きいフォントと小さいフォントで
違うのではないかと思います。
008372
NGNG何かのクラスのメンバーに例えば wxBitmap *pBitmap = new wxBitmap[N];
とかってやった場合はキチンと自前で delete [] pBitmap; ってやれ、って
事じゃぁないでしょうか。
wxWindows勉強まだ始めてないんで、かなり推測なんですが、wxWindows では
動的にアロケートされたwxWindows用のオブジェクトを終了時に勝手に delete
してくれるようになってるんじゃないですかね。で、その自動化機構によって
配列に delete かけるとマズいから、配列を動的に確保した場合はキチンと
delete [] を明示的にユーザー側でやってちょ。と。
全然違ったらｽﾏｿ
0084デフォルトの名無しさん
NGNGMingwのインクルードファイルとwxWindowsのインクルードファイル間で
構造体の宣言が衝突してエラーになります。
どなたか回避方法とかわかる方いらっしゃいますか？
008584
NGNGとりあえず下記を参考にインクルードファイルを修正してコンパイル中。
http://lists.wxwindows.org/cgi-bin/ezmlm-cgi?5:mss:33083:200305:jimgjppnkkijcogmmhle
コンパイル通ったらまた来ます。
0086灰
NGNG取り急ぎいろいろと。長文、乱文、アンカーミスあったらｽﾏｿ。
>>78 早起き過ぎ。
文責関係は私も気にしなきゃいけない気がしてたので
文書として明文化しておきました。
http://dot-gray.s33.xrea.com/translation.html
あー、なんか俺必死っぽい（藁
>>78,81-82
ローカルに保存しますた。あとでマージしときます。ｻﾝｸｽｺ！
>>79
>>65 は原文併記に切り替えときます。あと、修正もやっときまふ。
>>75,77 は >>77,83 氏の案でビンゴかと。
wxWindows のオブジェクトはガベコレで管理してるけど、
new されたC++配列(wxHoge* p = new wxHoge[N]）までは
管理しない(出来ない)から wx cleaned up までには、自分で責任もって削除しろYO！
でないと、問題ですよ！ってことで理解しかけますた。
new wxHoge != new wxHoge[N]
>> 84,85
うちも cygwin あるんでうｐ期待してまつ。
008765
NGNG>>69 の "a C++ array of objects" は配列じゃないんですな。
STLの……は惜しいけど違って、wxObjArrayだと思われ。こいつは要素を所有し
ますので死ぬときにdeleteします。それがclean upまで持ち越されると、
arrayのdeleteとwxWindowsが要素を直接deleteするのとの前後が不定なため
二重deleteが発生しうるということではないかと。
include/wx/dynarray.h (_WX_DECLARE_OBJARRAYの中のEmpty())
include/wx/arrimpl.cpp (~name()、DoEmpty())
wx31.htm (wxArrayの説明)
を読んでみて下さい。
訳文は夜にでも修正します。
>>84
いかがでしたか? うちではMinGWでもcygwinの-mno-cygwinでも作れていますけど、
ソースを修正したかどうかは忘れてしまいました。
あんまり困らなかったとは思うんですけど。
あと喉にひっかかってるトゲ(>>65)をとってくれる勇者ぼしうです。だれか
Watcom C++試して。
008884
NGNG環境はMingw2.0.0+MSYS1.0.8。
install-msw-2.4.0.txtに書いてある手順だけではうまくいかなかったので、
追加で必要だった作業を書いておきます。
★MingwのWindows APIパッケージは最新の2.3にしておく
★http://lists.wxwindows.org/cgi-bin/ezmlm-cgi?5:mss:33083:200305:jimgjppnkkijcogmmhle
上のURLを参考に、wxWindows-2.4.0/include/wx/msw/missing.hの
162行目以降で
#if defined(__GNUWIN32__) && !defined(HDN_GETDISPINFOW)
#define HDN_GETDISPINFOW (HDN_FIRST-29)
typedef struct {
NMHDR hdr;
となっている所を
#if defined(__GNUWIN32__) && !defined(HDN_GETDISPINFOW)
#define HDN_GETDISPINFOW (HDN_FIRST-29)
#endif
#if defined(__GNUWIN32__) && !wxCHECK_W32API_VERSION( 2, 3 )
typedef struct {
NMHDR hdr;
の様に修正する
以上です。
これで、minimalサンプルをコンパイルできる所まで確認しました。
ところで、wxWindowsのドキュメントの翻訳、乙です。
日本語のドキュメントなどが揃えば、新たな利用者も増えて、
スレ活性化で、情報増えて(ﾟДﾟ)ｳﾏｰ
漏れは英語苦手なんでアレですが、がんがってください！
0089デフォルトの名無しさん
NGNGDevPakとDev-C++を薦めたほうがよさげだね
http://citymap.slyip.com/_scripts/file.php?f=2618&r=46
0090灰
NGNGｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
> 漏れは英語苦手なんでアレですが、がんがってください！
ぶちゃけ、みんな苦手だと思うYO！
漏れ工房んとき、馬鹿すぎて英語教師に黒板けし投げつけられたことあるYO！
しかも当たったョ・・・、黒板けし。・・・糞、・・・氏ね、英語教師。
>>76
遅レスだがソースフォージか・・・、cvs 使えるのがえらい魅力的っぽいんだけど
そこまですんのも・・・。
週末に擬似 cvs ちっくな cgi いれよかな。
メールでパス発行して、期間限定（一週間ぐらい？）のチェックアウト。
コミットした文書はいったんトランク（？）に突っ込んで、
コミッター3人以上の認証が得られれば本コミットみたいな・・・。
面倒くさいか。
あと、皆様。
文責・著作権関係を以下に纏めてみたんだけど、
これでいいのかな？
こういうの書くのって初めてなのでよくわからないです。つっこみｷﾎﾞﾝ。
http://dot-gray.s33.xrea.com/translation.html#res
んじゃ、ちょっくらマージしてきまふ。
009165
NGNG> 訳文は夜にでも修正します。
いまいち反応がないのが不安ですがこの立場で大幅に言葉を足してみました。
> If you decide to allocate a C++ array of objects (such as wxBitmap)
that may be cleaned up by wxWindows, make sure you delete the array explicitly
before wxWindows has a chance to do so on exit, since calling delete on array
members will cause memory problems.
wxWindowsが終了時に個別に始末するオブジェクト(wxBitmapなど)のC++ array
(具体的には、WX_DECLARE_OBJARRAYで定義されるもの)をアロケートするのなら、
wxWindowsが終了時にそれを削除するより先に、確実に、明示的に削除せよ。
それはデストラクタで要素をdeleteするため、終了時の処理の順序によっては、
wxWindowsがarrayの要素についてdeleteを呼ぶときに、メモリを二重に解放して
しまうからである。
違うなら違うといってくれー。
009384
NGNG普及促進サイトの
http://dot-gray.s33.xrea.com/docs.org/wx14.htm#topic10
のページ中で（以下翻訳不能って所を訳してみました。
一部推測と意訳混じってますが、もし良かったら使ってください。
以下訳。
wxWindowsを制御するメイクファイルは、各Windowsコンパイラー用の物がMS-Windowsディレクトリ(src/msw)に入っているし、
Unix版を使っているならビルドディレクトリの中に入っている。このビルドディレクトリはユーザーが選ぶことが出来ます。
configureスクリプトを実行する時のカレントディレクトリがビルドディレクトリとなります。
このディレクトリは、標準的な基本ディレクトリ(そうするには./configureコマンドを実行すればよい)でも良いし、
他のどんなディレクトリ(例えば、先に基本ディレクトリの上階層にビルドディレクトリを作っておいて
そこで../configureコマンド実行するとか)でも良いです。
009484
NGNG以下のページを訳しました。
http://dot-gray.s33.xrea.com/docs.org/wx17.htm#topic14
おかしかったら、指摘してください。
以下訳。
アーキテクチャ依存
マルチプラットフォーム対応なプログラムを書いていると時々、
C言語の基本型(the basic C types)がすべてのプラットフォームで同じように定義されていない
という問題に遭遇することがある。この問題は基本型(intやlongなど)をビットで表したときの長さにも当てはまり、
また、それらのバイトオーダーにも当てはまる。バイトオーダーは、標準的なIntel系のコンピュータではリトルエンディアンになったり、
標準的な幾つかのUnixワークステーションではビッグエンディアンになる。
wxWindowsはアーキテクチャに依存しないコードを簡単に書けるように型とマクロを定義している。
それらの型には以下の物がある:
wxInt32, wxInt16, wxInt8, wxUint32, wxUint16 = wxWord, wxUint8 = wxByte
このwxInt32は32ビット符号付き整数型を表す、などなど。
またあなたは、wxBIG_ENDIANかwxLITTLE_ENDIANのどちらか一方を定義する(将来wxPDP_ENDIANも定義できる様になるかも)wxBYTE_ORDERを使って、
プログラムがどのアーキテクチャ上でコンパイルされるかチェックすることが出来ます。
その、アプリケーションのエンディアンについてビットスワッピングを処理するマクロは、Byte order macrosの章で説明されています。
0095灰
NGNG>>78,79,81-82
マージしますた。
ただ、新規翻訳文書は訳文と原文とのチェックまではいたらなかったので
両文併記のスタイルで挙げておきました。
申し訳ないっす。
>>93
乙です。がっつし！
ばっちりだと思います。
一点だけ・・・、個人的に configure はスクリプトだろ！って思ったのですが
グーグルおじさんによるとコマンド派が優勢だと知りました。
私の負けでございます。結構ショック。
configureスクリプト 約12,300件
http://www.google.co.jp/search?q=configure%83X%83N%83%8A%83v%83g&hl=ja&btnG=%8C%9F%8D%F5
configureコマンド 約17,900件
http://www.google.co.jp/search?q=configure%83R%83%7D%83%93%83h&hl=ja&btnG=%8C%9F%8D%F5
0096灰
NGNG亀レス。
MBCS系のお話。
下によるとにゃんかこんばーたまで用意されてるみたいね。
タイトルだけでぜんっぜん読んでないでけど
>> の氏 いかがでしょこのあたり。
Unicode support in wxWindows
http://dot-gray.s33.xrea.com/docs.org/wx458.htm#unicode
wxMBConv classes overview
http://dot-gray.s33.xrea.com/docs.org/wx459.htm#mbconvclasses
あとね、マジでまるちぷらっとふぉーむでごりごり行きたい人は
これをみとくと良いかもよ。
Supported classes by port
http://www.wxwindows.org/supported.htm
一応スレへのふぃーどばっく（？）つーことで。
009784
NGNG自分で書いておいてあれですが、漏れもスクリプトだと思います。(w
シェルスクリプトのひとつですよね？なんでコマンドって書いたんだろ？
漏れ的にはスクリプトはテキスト、コマンドはバイナリってイメージです。
ところで、もういっちょ訳しました。URLは↓です。よろしくお願いします。長文スマソ。
http://dot-gray.s33.xrea.com/docs.org/wx18.htm#topic15
以下訳。
条件コンパイル
wxWindowsの目的の一つは、乱雑で理解するのを混乱させ得るソースコード中の条件コンパイルの必要性を減らすことにある。
しかし時々、プラットフォーム固有の機能(MS-Windowsにおけるメタファイルの使用など)を組み込む必要が出てくることがある。
もしかするとsymbols.txtに載っているシンボルは、ユーザーが用意(定義)したシンボルと一緒に、この目的のために使用されるかもしれない。
0098灰
NGNG>>97
禿同。
テキストベースはスクリプト、
バイナリベース単機能型はコマンド、
同多機能型はアプリケーション、
って思ってたけどどうやら違うらっすいね。
んで、翻訳乙です！
明日（っつかもう今日か） >>97 はマージします。
>>94 はマージしました。
また、両文併記だけど、もう今日は限界。
ねむりまふ。
もう、ほんとﾍﾅﾁｮｺですまん。
あー、最後に
翻訳者の方々へ。
http://dot-gray.s33.xrea.com/translation.html#doc_info
上にあるとおり翻訳者名をすでうめこんでまふ。
今のところ”数字”で名乗ってる方々は数字のまんまつっこんでるんですが
ちゃんとしたハンドルで埋め込まれてー方はご一報くだされ。
0099の
NGNGwxBitmap::~wxBitmap（）の説明なんかを勘案して、こんな感じかと……
「もしもあンたがwxWindowsがクリンナップ（処理）を行うオブジェクトの
C++配列を割り当てることにしたンなら、（プログラム？関数？）終了（処理）時
みたいにwxWindowsが配列を削除する機会を得る前にてめぇできっちり
やっときなよ。配列メンバのdelete呼び出しはメモリ問題を招きやがるからな」
やっぱり（C++）配列だと思う。
でも、なんでメモリ問題をおこすのかな？オブジェクト配列の各要素が
デフォルトコンストラクタで作成されるから、それによって扱いが特殊になる、
つうこと？
教えて！！詳しいひと！
>96
いいですな。
ただ、確かEUC-JP/SJISはサポートしていない罠。
週末チャレンジしてみますか。
0100デフォルトの名無しさん
NGNG詳しくはないけど"C++ Array"が通常のC++配列(new wxBitmap[N];で確保した配列)
のことだとした場合に考えられる問題は>>83にも書いてある通り
delete[]で削除すべきオブジェクトをdeleteで削除してしまう問題が発生するのでは
0101デフォルトの名無しさん
NGNGwxObjectRefDataクラスが参照カウンタをもっていて
wxObjectのm_refDataメンバにwxObjectRefDataの派生クラスのオブジェクトを指すことで
wxObjectのRef(),UnRef()メンバを使ってwxObjectRefDataの派生クラスのオブジェクトを
管理することができるようになっているみたいです
これがwxWindowsが自動的に削除するオブジェクトの仕組みだとすると、
参照カウンタが0になって削除されるのはwxObjectRefDataの派生クラスのオブジェクトのほうで
>>83も>>87も問題なさそうな気がするのでもしかしたら的外れかもしれない・・・
■ このスレッドは過去ログ倉庫に格納されています