【GUI】wxWidgets(旧wxWindows) その5【サイザー】

**デフォルトの名無しさん** · 2014/02/26(水) 19:08:22.51

なるほど
wxPythonでコードを書いたものがC++に直接変換できたりしたら便利ですね
wxGladeみたいに

**デフォルトの名無しさん** · 2014/02/26(水) 20:20:43.75

なんか久しぶりにwxスレが伸びてるぞ、新規ユーザー大歓迎
ボタンとかテキストエリアの動的な生成は、wxPanelとかwxSizerを使った簡単なサンプルを作ったら理解できると思う
言葉で説明するよりコード書いたほうがよいけど一応書いとく

例えばボタンを生成・削除しようとする場合
親Panelをparent, 子panelをchildとすると

1. ウィジェットの生成：parentをnewして、必要な分だけchildをnew
child = new wxPanel(parent, …);
...

2. ウィジェットの削除：parent.DestoryChildren();
この関数で子ウィジェットを全部きれいに削除できる

説明の意味がわからなければ、まずは適当なチュートリアルサイトに行くべし
おすすめ
http://zetcode.com/gui/wxwidgets/

**デフォルトの名無しさん** · 2014/02/26(水) 20:22:35.51

>>614
慣れたら直接C++で書けるから多分コンバータは需要無いよ

**デフォルトの名無しさん** · 2014/02/26(水) 20:29:50.32

>>615
詳しくありがとうございます
拝見致します

>>616
wxGladeも要りませんかね？
フローはwxGladeで枠を作って機能をC++で書く感じになるのかと

**デフォルトの名無しさん** · 2014/02/26(水) 20:30:17.32

そのくらい wx は良く出来てるね。

**デフォルトの名無しさん** · 2014/02/28(金) 21:18:50.52

Qt以下の品質。gtkならcで書けた。

**デフォルトの名無しさん** · 2014/03/01(土) 00:37:16.59

そらQtのほうがメジャーやろ、死ね

**デフォルトの名無しさん** · 2014/03/01(土) 01:40:12.84

どっちも1992年頃にできた。OSSといえども商業的な成功がコミュニティ形成の鍵。
それ以外はGood Oldを懐かしむロートルか宗教的価値観に支えられているだけ。

**デフォルトの名無しさん** · 2014/03/01(土) 01:51:22.19

GUI比較スレってなんだよね・・・
比較的な話ってここで展開してもよいものやら
というかｗｘWidgetとQtどっちも使ってる人っているのか

**デフォルトの名無しさん** · 2014/03/01(土) 02:28:31.91

世の中のアプリケーションはQtかAwt/Swingが採用される流れ。
直交性ならgtk。サクッと安定したものを書くならtk。
トイプログラムならSDL+OpenGL。生きるとは残酷なことである。

**デフォルトの名無しさん** · 2014/03/01(土) 12:13:44.67

バイナリサイズでかいですな
VC2010でサイズ最適化オプションかけてもHelloWorldで5MB...
これはもうどうしようもない感じ？

**デフォルトの名無しさん** · 2014/03/01(土) 12:23:48.03

どうしようもないっす
ベース部分(wxStringとかwxWindowとか）の定義が容量食ってるから？ではないかという疑惑

**デフォルトの名無しさん** · 2014/03/01(土) 12:27:18.78

うーんなるほど
ランタイムで色々判断出来るような設計なんですかねえ

**デフォルトの名無しさん** · 2014/03/01(土) 12:32:32.69

そうですねwxWidgetsはRTTIの仕組みが活かされてるみたいなドキュメントはどっかで見た
たぶんwxWidgetsの中核であるwxWindowクラスはそんなんばっかしなんだろう

**デフォルトの名無しさん** · 2014/03/05(水) 12:40:46.24

ファイル操作系が異様にやりにくい
wxString dir_name("some directly name");
dir_name.Traverse(some_traverser,wxString(""),flags);
でディレクトリたどりながらファイル抽出できるかなとおもったが
flags = wxDIR_FILES
だとそのディレクトリの中身”のみ”探す
flags = wxDIR_DIRS
だとその下の”全ての”階層のディレクトリを抽出する
wxDIR_DEFAULT
だとその下の”すべての”ファイルを探す
なんでこんな仕様なんだ

**デフォルトの名無しさん** · 2014/03/05(水) 12:45:32.18

ああわかった
ディレクトリが見つかった場合のみその下も探す、ということなんだな
するとファイルのみだと当然下なんぞ無いからそれ以下を探すことはなく
ディレクトリのみ、とすると下にもいけるから最下層まで探そうとするわけか
うーん

**デフォルトの名無しさん** · 2014/03/05(水) 12:55:52.46

連投失礼
Traverserクラスを継承してそのOnDir関数の返り値で制御すればいいということでした

**デフォルトの名無しさん** · 2014/03/11(火) 15:51:27.09

浮動小数点を扱えるsliderってデフォルトではなさそうですか？

**デフォルトの名無しさん** · 2014/03/11(火) 17:23:40.57

たとえば 0 - 100 を 10 で割ると
0.0 - 10.0 のレンジになります

**デフォルトの名無しさん** · 2014/03/11(火) 17:30:20.25

やっぱそんな感じなんすね
最大値最小値現在値ラベル表示が便利だなーとおもったんですが、小数点付きでやろうと思ったら
自分でラベル付けるしかなさそうですね

**デフォルトの名無しさん** · 2014/03/15(土) 21:45:40.12

右側のボタンを押したら左側のパネルを再描写させたい、など
あるイベントから（親でない）ほかのイベントを誘発させたい時ってあると思うのですが
その辺に関する記事てどっかにあります？

**デフォルトの名無しさん** · 2014/03/15(土) 23:13:55.37

>>634
そのへんはイベント処理の領域になりますね
wxWiki見るしかない感じ

イメージとしては
Sample::LeftPanelRedraw(wxCommandEvent& event);
というイベント関数のIDがID_LeftPanelRedrawであった場合

そのイベントは
wxCommandEvent e(wxCommandEvent(wxEVT_COMMAND_BUTTON_CLICKED, ID_LeftPanelRedraw));
LeftPanelRedraw(e);
で呼べる

**デフォルトの名無しさん** · 2014/03/15(土) 23:39:19.87

>>635
了解です、参考にさせていただきます

**デフォルトの名無しさん** · 2014/03/21(金) 11:44:27.13

glcanvasを使ってパネルを描写し、ドラッグに反応するようにしたのですが
ドラッグ中に、ポインタがパネルの範囲外に出た時に、反応が止まってしまいます

sampleのdragimagではドラッグ中であれば範囲外でもイベントが取れるようですが
sampleのopengl/penguinだと取れないようです
マウスイベントの接続は両者ともEVT_MOUSE_EVENTSで行っているので
何が違って取れているのかわかりません
その辺の事情、どなたかご存知ないですか？

**デフォルトの名無しさん** · 2014/03/21(金) 12:58:58.01

わかりました
wxWindowBase::wCaptureMouse()を呼び出すと以降座標とイベントが取得されるようです

**デフォルトの名無しさん** · 2014/03/23(日) 17:51:04.60

はい。知ってますよ。

**デフォルトの名無しさん** · 2014/03/23(日) 19:26:21.87

いや、知らないです

**デフォルトの名無しさん** · 2014/05/12(月) 21:36:09.61

クロスプラットフォームの開発環境について調べてるんですが、wxWidgetsの
GUIは外観とかは各プラットフォームのものが使われるんですか？それとも
独自のテーマになってしまうんでしょうか？

**デフォルトの名無しさん** · 2014/05/12(月) 21:48:19.14

>>641
各プラットフォームのものが使われます
つまりWindowsならWIN32、LinuxならGTK、MacならCocoa
それぞれの外観になります

対してQtやTk、JavaのSwingなどは独自のテーマになります

**デフォルトの名無しさん** · 2014/05/12(月) 21:58:07.29

Qtってそうだったんだ

**デフォルトの名無しさん** · 2014/05/12(月) 22:57:11.37

>>642
ありがとうございます。他の環境まで概括してくださるとは助かりました。

**デフォルトの名無しさん** · 2014/05/13(火) 02:25:29.32

>>641
敢えてプラットフォームのを使わず
テーマ選ぶ方法もあったはず

**デフォルトの名無しさん** · 2014/05/25(日) 10:10:57.42

てす

**デフォルトの名無しさん** · 2014/06/03(火) 09:02:12.18

Swiftスレ
http://peace.2ch.net/test/read.cgi/tech/1401736341/

**デフォルトの名無しさん** · 2014/06/04(水) 21:33:25.19

いまこのスレ開いたら、>>646にあったはずの有益な書き込みが消えている…
貼っておこう

> 646 名前：デフォルトの名無しさん [sage]： 2014/05/23(金) 01:42:23.54 ID:NdcsMWjh
> wxFormBuilder 3.4.2betaがリリースされていたので試してみたら、
> wxWidgets3.0ベースのGUI描画になったおかげか、2.8をベースに作っていたレイアウトがごっそり狂った。
> これから3.0で作る分にはいいと思うけど、2.8で作る分には3.4.0betaで止めておいた方が良いかも。

**デフォルトの名無しさん** · 2014/06/05(木) 01:15:41.59

なんと、板移転したときに消えたのかもしれないね。

**デフォルトの名無しさん** · 2014/06/19(木) 12:54:27.42

wxWidgetsを使って作られたプログラムの一覧ってあったりするのかね？
とりあえずAudacityは知ってる

**デフォルトの名無しさん** · 2014/06/19(木) 19:37:20.57

http://www.wxwidgets.org/about/screenshots/
とか

**デフォルトの名無しさん** · 2014/06/19(木) 19:41:04.43

おーありがとう
後で見て回る
テンプレにあってもいいじゃないかな？

**デフォルトの名無しさん** · 2014/06/19(木) 20:07:59.88

車の再発見

**デフォルトの名無しさん** · 2014/06/19(木) 22:56:02.45

商用アプリは
http://wiki.wxwidgets.org/Commercial_applications_using_wxWidgets

**デフォルトの名無しさん** · 2014/08/24(日) 18:20:53.22

wxWidgetsで、フォームを閉じる処理をして実際に閉じるまでの間に発生するイベントとかある？
.NETで言うところのOnClosingみたいな感じで。

**デフォルトの名無しさん** · 2014/08/25(月) 02:12:21.61

OnClose
OnVeto

**デフォルトの名無しさん** · 2014/08/25(月) 14:23:49.85

>>656
㌧
おかげで作業が進みました。

**デフォルトの名無しさん** · 2014/08/26(火) 17:09:00.43

Windows で、
CrossBlock + MinGW + wxWidget
で最も簡単な GUI アプリを基本プロジェクトで作成してみたところ、

MyTest.exe のサイズ：736KB
(wxWidgetのDLL) wxmsw28u_gcc_custom.dll のサイズ : 15.9MB
MyTest.exe のメモリ使用量 : 7,732KB // TaskManagerの表示

となった。

この基本アプリは、HelpでAboutでメッセージ・ボックスが表示できる
ようになっているが、メニュー項目をクリックしてから実際にそれが
出るまで数秒かかる。実験したのはそこそこ速いマシンと速いWindows
での事。

**デフォルトの名無しさん** · 2014/08/26(火) 17:09:45.00

ただし、遅いのは最初の一回だけ。
一度でも表示すると後は速い。

**デフォルトの名無しさん** · 2014/08/26(火) 17:56:51.72

Mailer の Thunderbird-Portable なんかもマルチプラットフォーム対応
だけど、起動がかなり遅い。これも巨大な dll を読み込んだりしてる
からかな。

起動やメニュー操作が遅くなるのはマルチプラットフォーム化する代償
として負わされるのかも知れん。

こういうツールキットで軽快なアプリを作るのは難しいのかもな。

**デフォルトの名無しさん** · 2014/08/26(火) 19:14:34.45

小規模の自作ソフトでwxWidgetsをスタティックリンクしない理由が分からん
わざわざ合計バイナリサイズを大きく、速度も遅くする理由がどこにあるのだろう

**デフォルトの名無しさん** · 2014/08/26(火) 21:27:38.25

>>661
なるほど、スタティックリンクにすれば、起動後になってからユーザーの
命令に対する応答が遅れる事はなくなるかもしれない。
起動が遅くなるだけで済むんなら、そっちの方がストレスが少ないかも。

**デフォルトの名無しさん** · 2014/08/26(火) 21:50:56.10

ある程度規模が大きくなるとスタティックリンクだと初回起動が遅すぎになので
dllにモジュールを分割してやったほうがいい
起動時のメモリへのロード時間はどうしようもないのでスプラッシュをつけてごまかす

**デフォルトの名無しさん** · 2014/08/26(火) 22:39:34.76

CrossBlockでは、monolithic タイプのライブラリをビルドしてから使う
ようになってるんだけど、それも遅い原因なのかな。

でも起動後にユーザー入力に対するレスポンスが遅いのはどう説明すれば
いいんだろう？

普通の Windows の仕様だと原則、起動時に全ての DLL をロードする。
LoadLibrary()を使えば動的にロードすることも可能は可能だけど、
それをする必要は旧OSでサポートしてなかった新OSのDLLをロードする
ような場合は、多言語化のサポートなど。

なるほど、多言語化のせいかも。_("xxx") みたいなのがあったから、
gettext を使ってる。それでリソースを動的ロードしているのか。

**デフォルトの名無しさん** · 2014/08/27(水) 04:40:25.51

何度かアプリ起動しているうちにWindowsのFetchが学習してくれて
DLLとか先読みしてくれるようにならないのだろうか

**デフォルトの名無しさん** · 2014/08/27(水) 06:47:58.33

>>665
それはなる。
・ディスクの内容は、メモリにキャッシュされる。
・同じDLLは、全てのアプリで物理メモリが共有されると聞いたことがある。

# >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。

それより、wxWidget 本家のソース配布に入っている samples を
Windows の mingw32 でビルドしてみたところ、全然遅くなかった。

・アプリの起動は速い。
・起動後のメニューコマンドやユーザー入力に対するレスポンスも速い。
・Aboutダイアログも瞬間ではないが、0.3秒程度で、Windows Nativeアプリ
　でも、その程度の遅さはある場合があるので遜色ない。

CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
ライブラリを使用しているからか。

**デフォルトの名無しさん** · 2014/08/27(水) 07:54:18.52

>>666

># >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。

なんだと思ったらわりと素人じゃねえかおい

>CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な
>ライブラリを使用しているからか。

monolithicってのはwxWidgetsのモジュール全部入りのDLL作るという意味なので遅くて当然
（実際試したことないので遅いというのは初めて知ったが…）

普通は ./configure --prefix=/mingw --enable-shared みたいに指定してビルドするから
モジュールごとに分割されたDLLが作成される
Windows上で開発する時はMinGW + NTEmacs/eclipse CDTの環境がおすすめ

**デフォルトの名無しさん** · 2014/08/27(水) 09:58:52.27

>>667
最後の段落：多分、wxWidgets 本体を MInGW32 用のビルドする際は、
configure は使えない気がする。
CodeBlocks のQuickなんたらRefの説明では、いきなり、
make するように支持されていた。しかも、-fno なんたら dll-export
みたいなオプションを付けろと指示。これは、MinGW32のバグで、
付けないと最後のldの段階でldがクラッシュする事をたまたま発見。

ところで話は変わって聞いておきたいのですが、 eclipse では
wxWidget のイベントを書くようなときに

・BEGIN_EVENT_MAP に自動的に一行マクロを挿入してくれて
・*.h にもメンバ関数宣言を書いてくれて
・*.cpp にも5行くらいの関数定義本体の雛形を書いてくれ

たりしますか？

**デフォルトの名無しさん** · 2014/08/27(水) 10:01:06.29

つまり、イベント・ハンドラを追加したとき、

BEGIN_EVENT_TABLE(wxListMainWindow,wxScrolledWindow)
EVT_PAINT (wxListMainWindow::OnPaint)
EVT_MOUSE_EVENTS (wxListMainWindow::OnMouse)
EVT_CHAR (wxListMainWindow::OnChar)
EVT_KEY_DOWN (wxListMainWindow::OnKeyDown)
EVT_KEY_UP (wxListMainWindow::OnKeyUp)
EVT_SET_FOCUS (wxListMainWindow::OnSetFocus)
EVT_KILL_FOCUS (wxListMainWindow::OnKillFocus)
EVT_SCROLLWIN (wxListMainWindow::OnScroll)
EVT_CHILD_FOCUS (wxListMainWindow::OnChildFocus)
END_EVENT_TABLE()

とか、クラスを書くとき

IMPLEMENT_DYNAMIC_CLASS(wxListMainWindow,wxScrolledWindow)

見たいなものの自動生成があるとうれしいんですが、そういう IDE
はありません？

**デフォルトの名無しさん** · 2014/08/29(金) 11:13:03.59

wxWidgetsの問題点の1つは、プログラムのサイズが大きくなる事。
特に静的リンクしたときに顕著。

Windows は、VC++ にて、
ac1rd: CUI の Win32 と printf() を使ったもののリリース・動的リンク版が 16KB程度。
　　　 puts() を使えばもっと小さく出来る。
ac1rs: CUI の Win32 と printf() を使ったもののリリース・静的リンク版が 40KB程度。
　　　 puts() を使えばもっと小さく出来る。
ag2rd: GUI の MFC の基本的な MDI アプリがリリース・動的リンク版で 36 KB 程度。
ag2rs: GUI の MFC の基本的な MDI アプリがリリース・静的リンク版で 332 KB 程度。

wxWidgets 2.8.12 の samples では、
bc1rd: CUI の console.exe がリリース・動的リンク版で 138KB
bc1rs: CUI の console.exe がリリース・静的リンク版で 863KB
bc1dd: CUI の console.exe がデバッグ・動的リンク版で 184KB

bg2rd: GUI の keyboard.exe がリリース・動的リンク版で 293KB
bg2rs: GUI の keyboard.exe がリリース・静的リンク版で 2,924KB
bg2dd: GUI の keyboard.exe がデバッグ・動的リンク版で 492KB

ただし、bc1xx は、アプリ本体のプログラムが複雑なことをしているようなので、
もっと小さく出来る可能性があり。

**デフォルトの名無しさん** · 2014/08/29(金) 19:04:31.75

その説明にac1だの何だの自分以外分からない定義を使う必要があったのだろうか

**デフォルトの名無しさん** · 2014/08/29(金) 19:07:59.00

今から見るとそうかも。
a: Windows Native or MFC
b: wzWidgets
c: CUI
g: GUI
r:release, d:debug
d:dynamic link, s:static link

**デフォルトの名無しさん** · 2014/08/30(土) 00:17:55.46

>>668

>最後の段落：多分、wxWidgets 本体を MInGW32 用のビルドする際は、
>configure は使えない気がする。

なにいってんだCodeBlocksのドキュメントにそう書いてあるだけで
基本autotoolsで作られたソースはconfigureでビルドできるぞ
実際自分はWindows上のmingw32/64、LinuxのクロスビルドからのMinGWでconfigure使ってる

なぜMakefileでやれという指示なのかというと、そのほうが簡潔で保守しやすいからだ
あとGNU MakeじゃないMakeでもビルドできるようにしたいとかいう微妙なこだわりが有る場合も有る

>>669
エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける
ソースのひな形自動生成機能は知らんなあ

**デフォルトの名無しさん** · 2014/08/30(土) 00:21:29.81

>>670
MinGWビルドでバイナリをストリップしたやつとか比較しないのか

**デフォルトの名無しさん** · 2014/08/30(土) 07:56:49.02

>>674
Stripに詳しくないので、言っている意味が分からない。

Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの？

**デフォルトの名無しさん** · 2014/08/30(土) 07:58:19.03

>>674
Stripに詳しくないので、言っている意味が分からない。

Stripって Release 用に Build した Binary に対して行っても
サイズダウンできたりするの？

**デフォルトの名無しさん** · 2014/08/30(土) 08:15:51.54

日本語インライン入力の対応ってまだなの？
というか予定自体なくて諦めた方がいい？
wxWidgets使ってるEditraってエディタにそろそろ移行できるかなと
思って試してみたら、未だにインライン入力できない

**デフォルトの名無しさん** · 2014/08/30(土) 08:19:53.34

>>674

小さくなりますた!!

Relese, 動的リンク
/wxWidgets-2.8.12/samples/keyboard/gcc_mswdll/keyboard.exe

strip 前：299,808 bytes
strip 後：124,430 bytes

Relese, 静的リンク
/wxWidgets-2.8.12/samples/keyboard/gcc_msw/keyboard.exe

strip 前：2,993,255 bytes
strip 後：1,887,758 bytes

strip 後も、*.exe が正常に起動することを確認済み。

**デフォルトの名無しさん** · 2014/08/30(土) 08:22:26.84

>>673
>エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける

詳しく：

**デフォルトの名無しさん** · 2014/08/30(土) 11:51:11.86

馬鹿には無理

**デフォルトの名無しさん** · 2014/08/30(土) 12:02:34.82

スタンド・アローン・コンプレックスと化した馬鹿には無理さんオッスオッス

>>679
cua-modeでググって
http://qiita.com/yyamamot/items/7efcbfdcccdb5fa45ebe

例えばイベントテーブルとかはこれでザクッと一気に書ける
もちろん個々のwxWindowIDとメソッド定義は書かなくてはいけないが
クラス名とマクロ定義は同じ文字列の繰り返しなのでだいぶ楽になる

**デフォルトの名無しさん** · 2014/08/30(土) 13:53:01.64

>>681
あー、そういう風に沢山のイベントを一気に書きたいんじゃなくて、
開発段階で徐々にイベントを追加して行く際に、

1. *.h のクラス内にメンバ関数宣言
2. *.cpp に EVENT MAP
3. *.cpp にメンバ関数定義の本体

の三箇所にコードを書くのが面倒ということなんだわ。

**デフォルトの名無しさん** · 2014/08/30(土) 14:33:49.98

>>682
それは自分で作らないと無さげですねえ

**デフォルトの名無しさん** · 2014/08/30(土) 19:11:57.66

wxFormBuilderでしかGUIとイベントを設計できない俺には何言ってるのかさっぱりわからんぜよ……

**678** · 2014/08/31(日) 15:54:21.95

wxAUI のデモ・アプリ wxauitest.exe のサイズは、1,417,216 bytes。
スタンドアロンのアプリで、環境変数からパスを完全に消去しても起動
できた。つまり、ライブラリはDLLを使わずに静的リンクされている。
wxAUIはFloating & Dockingのできる強力なGUI。

>>678 に示した keyboard.exe はキーボードから押されたキーの値を
表示するだけで、上記アプリよりずっとシンプルなのにも関わらず、
1,887,758 bytes と 470,542 bytes も大きい。

理由は不明。

**デフォルトの名無しさん** · 2014/08/31(日) 15:56:18.96

そんなことしなくても
DLLの依存関係調べるツールあるのに

**デフォルトの名無しさん** · 2014/08/31(日) 16:01:12.95

ちなみにwxWidgetsで作った一番小さいexe探したら65kbのがあった

**678** · 2014/08/31(日) 17:34:23.46

Windows実行形式であっても、コンパイラが、MinGW32 と VC++ でサイズに
大幅な違いが出てくるのかな？

**678** · 2014/08/31(日) 17:41:03.82

>>687
それは DLL 版だよ。絶対に。

**デフォルトの名無しさん** · 2014/08/31(日) 19:56:13.33

>>685
実行ファイルの関数テーブルに何が入っているか nm で確認したら少しはわかるかもね

>>688
大幅とは行かないかもしれないがVC++はWindowsのみをターゲットにしているから
基本的にコンパイル後のバイナリサイズは MinGW ＞ VC++ だよね

**デフォルトの名無しさん** · 2014/08/31(日) 20:18:05.13

CodeBlocks + MinGW32 で、
wxWidgets の Monolithic、ASCIIライブラリ, 静的リンクで
最も簡単な Frame Based な GUI を作成してみたら、
2,073,600 バイトよりは小さくならなかった。

wxWidgets のライブラリは、
-Os
-ffunction-sections
-fdata-sections
でコンパイルし、
-Wl,--gc-sections -s
でライブラリ化した。その時のコマンド：

mingw32-make -j2 -f makefile.gcc CPPFLAGS="-MD -MP -DHAVE_W32API_H
-D__WXMSW__ -DNOPCH -DwxDEBUG_LEVEL=0 -DNDEBUG" CFLAGS="-mthreads
-fmessage-length=0 -ffunction-sections -fdata-sections -fno-builtin
-Os" CXXFLAGS="-mthreads -Wno-ctor-dtor-privacy -fmessage-length=0
-ffunction-sections -fdata-sections -fno-builtin -Os
-fno-keep-inline-dllexport" LDFLAGS="-Wl,--subsystem,windows
-Wl,--gc-sections -s -mthreads -mwindows"
BUILD=release UNICODE=0 SHARED=0 MONOLITHIC=1

CodeBlocks でアプリのリンクのオプションにも、
-Wl,--gc-sections -s
は付けてある。

**デフォルトの名無しさん** · 2014/08/31(日) 20:27:38.74

ちなみに、Unicode 版より ASCII 版のほうが小さくなることを確認済みである。

[Compiler settings - #defines]
が、標準では、
__GNUWIN32__, __WXMSW__, WXUSINGDLL, wxUSE_UNICODE, WX_PRECOMP
となるところを：
__GNUWIN32__, __WXMSW__
だけとし、

[Search Directories] の Compiler, Linker, Compiler
の、gcc_dll の部分を、gcc_lib に変えた。

アプリにリンクするリンクライブラリとしては、上記で作成した Monolithic
ライブラリだけでは足りず、以下が必要であった。Win32のimport libraryは、
ライブラリを動的リンクする場合はライブラリのDLLが行っているので必要ない
が、ライブラリを静的リンクする場合は、アプリが直接リンクする必要がある
ため必要となるのは理解できる。libwxpng, libwxjpeg, libwxtiff, libwxzlib
が必要となった理由は不明。

libwxmsw28 // これが wxWidgets の monolithic ライブラリ本体。
libwxpng
libwxjpeg
libwxtiff
libwxzlib
libuuid // Win32 の import library
libcomctrl32 // Win32 の import library
libwinspool // Win32 の import library
liboleaut32 // Win32 の import library
libole32 // Win32 の import library

ちなみに、wxWidgets を動的リンクする場合は、ここが、libwxmsw28
だけで済む。

**デフォルトの名無しさん** · 2014/08/31(日) 20:33:24.61

誤：[Search Directories] の Compiler, Linker, Compiler
正：[Search Directories] の Compiler, Linker, Resource Compiler

誤：Win32のimport libraryは、ライブラリを動的リンクする場合はライブ
　　ラリのDLLが行っているの
正：wxWidgets ライブラリをアプリに動的リンクする場合は
　　wxWidgets ライブラリの DLL 部分が Win32 の import library の
　　リンクを行っているの

**デフォルトの名無しさん** · 2014/08/31(日) 20:45:44.37

サイズはどうでもよくないか。exeを使う側としては速度では?
あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。

**デフォルトの名無しさん** · 2014/08/31(日) 20:48:05.22

完全テンプレートライブラリにしたら軽くなるんだろうか

**デフォルトの名無しさん** · 2014/08/31(日) 20:58:57.78

>>694
でも wxWidgets がやっていることの割にはリンクされるバイト数が多すぎる
感じがする。
基本、Win32をラッピングしているだけなのだから、2MBも必要ない。

**デフォルトの名無しさん** · 2014/08/31(日) 21:00:34.83

ラッピングしてるだけじゃなくマルチプラットフォームのために徹底した抽象化をしてるんでしょ
とソースも読まず推測

**デフォルトの名無しさん** · 2014/08/31(日) 21:04:00.35

>>697
でもソースを呼んでみたら、たとえば、wxListCtrl なんかは、
Win32 の LIST CONTROL をそのまま使っていた。
DrawRect()などで書いているわけではない。
ただし、wxGenericListCtrl だったかは、DrawRect()みたいなグラフィック
関数で独自に描画していた。が、それは、Windows版では簡単には使えない
という噂を聞いたが。

**デフォルトの名無しさん** · 2014/08/31(日) 21:06:47.60

>>697
wxWidgets の基本設計は、Widgetは、OS nativeの物を使うが、
どんなサイズであっても対応できるように Sizer で Layout を
コントロールする、という物。

なので、抽象化はサイズと配置程度で済むはずなのだが・・・。

**デフォルトの名無しさん** · 2014/08/31(日) 21:09:35.31

>>696

>>697の言ってることが正しい。

---------------------
　　　　wxWidgets
---------------------
Win32 | GTK | Cocoa etc...
---------------------

wxWidgetsは通常のGUI用ライブラリに一枚レイヤを重ねた形になるので
型情報・関数テーブルの情報だけで結構容量食う

>>692
ASCIIモードでビルドするのはやめておいたほうがいい
日本語使えないし

というかなぜMonolithicビルドにこだわるのか…
普通にconfigureからビルドしてdllごと配布したほうが立ち上がりは早い

**デフォルトの名無しさん** · 2014/08/31(日) 23:57:56.42

wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。

実は、Win32 の LIST CONTROL は、

・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
　行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
　とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
　奇妙な動作をする。奇妙な動作と言ったがバグに近い。

こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。

**デフォルトの名無しさん** · 2014/08/31(日) 23:59:28.64

wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。

実は、Win32 の LIST CONTROL は、

・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
　行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
　とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
　奇妙な動作をする。奇妙な動作と言ったがバグに近い。

こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。

**デフォルトの名無しさん** · 2014/09/01(月) 00:00:47.70

>>700
>wxWidgetsは通常のGUI用ライブラリに一枚レイヤを重ねた形になるので
>型情報・関数テーブルの情報だけで結構容量食う

オイラはコンパイラの基本部分に詳しいが、それだけで1MBなどには
ならない。

**デフォルトの名無しさん** · 2014/09/01(月) 00:06:51.19

>>694
諦めることも手かも知れないけど、やっている事の規模とサイズとの
ギャップに納得がいかない人もいるはず。

wxWidgetsはラッピング・ライブラリの一種。

8bit時代、16bit時代を知る人にとって、Widget 程度が64KBを超える
事があってはならない。どういうプログラミングをしたら2MBにもなる
のか。

**デフォルトの名無しさん** · 2014/09/01(月) 01:16:10.03

>>703
>>704
一理あるのでちょっとメーリングリストを探ってみたり
まず、wx/wx.hがいろいろなヘッダファイルを事前にincludeしているので
それがバイナリサイズの増加の一因になっているらしい

[wxMSW]: why EXE-files are so large?
https://groups.google.com/d/msg/wx-users/psTmm3nB6AU/9j6-4ir95-gJ

**デフォルトの名無しさん** · 2014/09/01(月) 07:25:22.06

>>591 のライブラリを samples/keyboard にも使ってみたら、
keyboard.exe のサイズを 1,619,968 にまで縮小することに成功した。
コンパイラは MinGW32 のまま。
条件は：release, 非UNICODE(ASCII), SHARED=0(静的リンク), MONOLITHIC = 1

どうやら MONOLITHIC であるかどうかは最終 exe サイズには関係してないらしい。
ライブラリと言うのは集めてもばらしても、最終 exe のリンク結果には影響を
及ぼさない事が基本なので、元々当たり前なことなのだが。

[samples/keyboard]
$ mingw32-make -f makefile.gcc BUILD=release UNICODE=0 SHARED=0 MONOLITHIC=1

[samples/keyboard/makefile.gcc の修整]
-------------------------------------------------------------------------------------
$(OBJS)\keyboard.exe: $(KEYBOARD_OBJECTS) $(OBJS)\keyboard_keyboard_rc.o
　　　　　$(CXX) -o $@ $(KEYBOARD_OBJECTS) $(__DEBUGINFO) $(__THREADSFLAG)
-L$(LIBDIRNAME) -Wl,--subsystem,windows -Wl,--gc-sections -Wl,-s -mwindows
$(____CAIRO_LIBDIR_FILENAMES_p) $(LDFLAGS) $(__WXLIB_CORE_p) $(__WXLIB_BASE_p)
$(__WXLIB_MONO_p) $(__LIB_TIFF_p) $(__LIB_JPEG_p) $(__LIB_PNG_p)
-lwxzlib$(WXDEBUGFLAG) -lwxregex$(WXUNICODEFLAG)$(WXDEBUGFLAG) -lwxexpat$(WXDEBUGFLAG)
$(EXTRALIBS_FOR_BASE) $(__UNICOWS_LIB_p) $(__GDIPLUS_LIB_p) $(__CAIRO_LIB_p)
-lkernel32 -luser32 -lgdi32 -lcomdlg32 -lwinspool -lwinmm -lshell32 -lcomctl32 -lole32
-loleaut32 -luuid -lrpcrt4 -ladvapi32 -lwsock32 -lodbc32
--------------------------------------------------------------------------------------

上記は original の makefile.gcc に、
-Wl,--gc-sections -Wl,-s
を追加しただけ。

**デフォルトの名無しさん** · 2014/09/01(月) 07:31:05.33

誤：>>591
正：>>691

【大吉】 · 2014/09/01(月) 07:40:36.83

wxWidgets の samples で ListCtrl 関連を見てみたが、ヘッダを
ドラッグしようとしてもドラッグできないので、ドラッグによる列の入れ替
えは出来ないようだった。

実は、Win32 の LIST CONTROL は、

・マウスドラッグによる自動的な列の入れ替えをした際、どこにどの列が
　行ったかを掌握するには注意が必要。動作を知るには基本的に実験を必要
　とする。
・第1カラムを削除すると第2カラム以降を削除した時とは同じとは言えない
　奇妙な動作をする。奇妙な動作と言ったがバグに近い。

こういった辺りがどう処理されているか知りたかったのだが、サンプルでは
故意か偶然か、全くそこに触れていないようだった。

**デフォルトの名無しさん** · 2014/09/01(月) 07:45:41.49

>>694
>あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。

「>>692」で示した Win32 import library は、Windows のシステム DLL
をリンクするための小さなライブラリ。例えば、
libcomctrl32 をリンクしていても、実際は、comctrl32.dll が動的リンク
される。libcomctrl32.a は、MinGW32 が用意している import library で：

/xxx/CodeBlocks/MinGW/lib/libcomctl32.a　# 86,428 bytes
C:/WINDOWS/system32/comctl32.dll　　　　 # 617,472 bytes

のように、windows/system32 の comctrl32.dll を動的リンクするための
呼び出し部分だけを提供する小さなライブラリ。

**デフォルトの名無しさん** · 2014/09/01(月) 08:18:53.15

map出力して何がリンクされてるか見れば？

**デフォルトの名無しさん** · 2014/09/01(月) 14:09:14.38

MONOLITHIC の値が違うと別の *.o が作成されることが判明。
以下は、SHARED=0(静的リンク)の場合の、MONOLITHIC が 0 と 1 の場合。

CORELIB_CXXFLAGS = $(__DEBUGINFO) $(__OPTIMIZEFLAG) $(__THREADSFLAG) \
　　$(GCCFLAGS) -DHAVE_W32API_H -D__WXMSW__ $(__WXUNIV_DEFINE_p) \
　　$(__DEBUG_DEFINE_p) $(__NDEBUG_DEFINE_p) $(__EXCEPTIONS_DEFINE_p) \
　　$(__RTTI_DEFINE_p) $(__THREAD_DEFINE_p) $(__UNICODE_DEFINE_p) \
　　$(__MSLU_DEFINE_p) $(__GFXCTX_DEFINE_p) -I$(SETUPHDIR) -I..\..\include \
　　$(____CAIRO_INCLUDEDIR_FILENAMES) -W -Wall -DWXBUILDING -I..\..\src\tiff \
　　-I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex \
　　-I..\..\src\expat\lib -DwxUSE_BASE=0 $(__RTTIFLAG) $(__EXCEPTIONSFLAG) \
　　-Wno-ctor-dtor-privacy $(CPPFLAGS) $(CXXFLAGS)

MONOLIB_CXXFLAGS = $(__DEBUGINFO) $(__OPTIMIZEFLAG) $(__THREADSFLAG) \
　　$(GCCFLAGS) -DHAVE_W32API_H -D__WXMSW__ $(__WXUNIV_DEFINE_p) \
　　$(__DEBUG_DEFINE_p) $(__NDEBUG_DEFINE_p) $(__EXCEPTIONS_DEFINE_p) \
　　$(__RTTI_DEFINE_p) $(__THREAD_DEFINE_p) $(__UNICODE_DEFINE_p) \
　　$(__MSLU_DEFINE_p) $(__GFXCTX_DEFINE_p) -I$(SETUPHDIR) -I..\..\include \
　　$(____CAIRO_INCLUDEDIR_FILENAMES) -W -Wall -DWXBUILDING -I..\..\src\tiff \
　　-I..\..\src\jpeg -I..\..\src\png -I..\..\src\zlib -I..\..\src\regex \
　　-I..\..\src\expat\lib -DwxUSE_BASE=1 $(__RTTIFLAG) $(__EXCEPTIONSFLAG) \
　　-Wno-ctor-dtor-privacy $(CPPFLAGS) $(CXXFLAGS)

**デフォルトの名無しさん** · 2014/09/01(月) 14:13:21.84

違いは、-DwxUSE_BASE の部分で、
　MONOLITHIC = 0 の場合 : -DwxUSE_BASE=0　 // #define wxUSE_BASE 0
　MONOLITHIC = 1 の場合 : -DwxUSE_BASE=1　 // #define wxUSE_BASE 1
となっている。

例えば、/xxx/src/msw/dc.cpp は、同じソースに対し make に渡すオプションに応じて
以下の2種類の *.o ファイルが作成される。
1つ目は、MONOLITHIC=0の時に作られ、2つ目は、MONOLITHIC=1の時に作られる。

ifeq ($(USE_GUI),1)
$(OBJS)\corelib_dc.o: ../../src/msw/dc.cpp
　　$(CXX) -c -o $@ $(CORELIB_CXXFLAGS) $(CPPDEPS) $<
endif

ifeq ($(USE_GUI),1)
$(OBJS)\monolib_dc.o: ../../src/msw/dc.cpp
　　$(CXX) -c -o $@ $(MONOLIB_CXXFLAGS) $(CPPDEPS) $<
endif

ソースを見ると、wxUSE_BASE の値に応じて場合分けされている箇所が多数ある。
つまり、MONOLITHIC の 0 と 1 の違いは単に *.o ファイルの集め方の問題では無い。
コンパイル時点のソース自体が変更されるのである。故にリンク後の*.exe のサイズ
が変わって来ても不思議は無い。これは驚くべきことである。

**デフォルトの名無しさん** · 2014/09/01(月) 15:21:49.13

別に驚くほどのことじゃ無いけど

**デフォルトの名無しさん** · 2014/09/01(月) 16:14:53.94

>>713
コンパイルオプションまで変えてしまって何をやっているかと言うこと
なんだよ。ライブラリの集め方だけの問題じゃないって事なんだ。

ライブラリの動作が変わってしまい、MONOLITHIC が 0 と 1とで結果が違うことに
悩まされる可能性もある。

単にライブラリのオブジェクトの集め方（含み方）の問題では無いとすると、MONOLITHIC
オプションの意味はいったい何かと言う問題になる。

また、最終EXEが大きくなる理由として、アプリが使ってないオブジェクトを
非常に基本的なライブラリの一部が参照している可能性がある。
そしてそのオブジェクトが別のオブジェクトを勝手に参照して・・・という
事が続いて最終EXEのサイズが肥大化してしまっているのかも知れない。

**デフォルトの名無しさん** · 2014/09/01(月) 16:33:12.36

http://wiki.wxwidgets.org/WxWidgets_Build_Configurations

「MONOLITHIC=1 :
　Packages all libraries in a single file.
　(Note: do not combine this option with a static build.)」

とあった。static build の時は、MONOLITHIC=1 にするな、と
書かれている・・・。

**デフォルトの名無しさん** · 2014/09/01(月) 16:49:54.89

いったい何を目的として何を検証しているんだ？

**デフォルトの名無しさん** · 2014/09/01(月) 17:12:16.45

このライブラリを使うなとなる。

**デフォルトの名無しさん** · 2014/09/01(月) 17:31:47.05

>>717
そういうわけではない。

**デフォルトの名無しさん** · 2014/09/02(火) 13:46:25.35

configure を試してみたら、configureのヘルプ通りには行かなかった：

・以下、xxx = wxWidgets-2.8.12 とする。/xxx/ に configure スクリプトがある。

・configureを使用するために、単なるcmd.exeではなくcygwin環境が必要であった。

・cygwinを起動する際、cygwin に入ってからの PATH が、
　(MinGWのbin) : /usr/local/bin/ : /usr/bin/ : (Winからのbin)
　の順になるようにした。

・カレントを /xxx/ にして configure した。configure の引数には少なくとも

・--build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-pc-mingw32
　を指定し、例外, rtti, regex, zlib, jpeg, png, tiff は無効にするオプション
　を設定した。他にも無効にしたものも多い。大量に及ぶので　スクリプトに記述した。

・Makefileが普段の /xxx/build/msw/ ではなく、/xxx/ に作られた。

・/xxx/samplesのサブディレクトリにあるMakefileが書き換えられた。

・setup.h が、
　/xxx/lib/wx/include/msw-ansi-releasw-static-2.8/wx
　/xxx/lib/wx/include/msw-ansi-releasw-2.8/wx
　の二箇所に作成された。元々各所にあるが、例としては
　/xxx/include/ws/msw や /xxx/lib/gcc_lib/msw/wx にある。　

・/xxx/ で make[ret] してみた。

・途中で例外を有効にするように言われたので有効にした。

**デフォルトの名無しさん** · 2014/09/02(火) 13:46:50.57

・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
　src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
　ないエラーとなった。。
　そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
　を最後尾に追加した。

・make には成功した。

・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
　/build/msw から make した場合は、/xxx/lib/gcc_lib に作られるのと対照的
　である。

・/xxx/samples/console で make してみたら、成功した。

・「プロシージャエントリポイント _gxx_persolanity_v0 が
　　ダイナミックリンクライブラリ libstdc++-6.dll から見つかりませんでした。」
　のメッセージボックスが出て起動できず。

・Makefileを書き換えて、LIBS の最後に -lstdc++ を書いても症状は治まらない。

**デフォルトの名無しさん** · 2014/09/02(火) 13:48:11.36

・regex, zlib, jpeg, png, tiff は全て無効にしていたにも関わらず、
　src/regex, src/zlib, src/jpeg, src/tiff にしかない *.h ファイルが見つから
　ないエラーとなった。。
　そこで、Makfileを直接修整して、CPPFLAGS に -I 指定によって、上記ディレクトリ
　を最後尾に追加した。

・make には成功した。

・/xxx/ に大量の *.o ファイルが作られ、*.a は /xxx/lib/ に作られた。
　/build/msw から make した場合は、/xxx/lib/gcc_lib に作られるのと対照的
　である。

・/xxx/samples/console で make してみたら、成功した。

・「プロシージャエントリポイント _gxx_persolanity_v0 が
　　ダイナミックリンクライブラリ libstdc++-6.dll から見つかりませんでした。」
　のメッセージボックスが出て起動できず。

・Makefileを書き換えて、LIBS の最後に -lstdc++ を書いても症状は治まらない。

**デフォルトの名無しさん** · 2014/09/02(火) 16:41:02.66

console.cpp の中身を printf() だけを使う4行の main() 関数だけに
書き換えてみたら問題なく起動して普通に文字列が表示された。

なので、MinGW 環境の問題ではなさそう。

**デフォルトの名無しさん** · 2014/09/02(火) 17:12:10.67

wxPrintf()だけを使った console 版 hello world が、static link
で 96,468 bytes で済んだ。

ところが、wxString を使った場合、作成した exe を実行しようとすると
>>721 後半で書いたメッセージ・ボックスが出て起動できない。

**デフォルトの名無しさん** · 2014/09/02(火) 17:17:49.98

libstdc++がダイナミックリンクになってるだけだろ。

**デフォルトの名無しさん** · 2014/09/02(火) 17:44:29.48

>>724
ダイナミックライブラリであるところの
　libstdc++-6.dll
は既に読み込めているんですわ。
「libstdc++-6.dll から見つかりませんでした。」
の「から」がそれを表している。

なお、configureを使わずに、build/msw から build したライブラリだと
wxStringとwxPrintfだけを使ったconsoleアプリは、静的リンクでも
451,584 バイトで済むことが判明。こちらはちゃんと起動できる。

**デフォルトの名無しさん** · 2014/09/02(火) 19:04:52.66

パスが通ったところに互換性のない別バージョンのdllがあるんだろ。
mingwだとsjljとdw2の２種類あるから。

**デフォルトの名無しさん** · 2014/09/02(火) 19:56:42.14

MinGW/bin を

i686-pc-mingw32-g++ と MinGW/bin/g++ は別物らしくコンパイラのサイズ
（作ったプログラムのサイズではなく変換機のサイズ）がそもそも違う。

また、前者では、リンク段階で何もエラーを出さないが、
後者では、ちゃんと、_gxx_persolanity_v0 や _Unwind_Resume が
undefined reference というエラーになる。

**デフォルトの名無しさん** · 2014/09/02(火) 20:00:33.47

>>726
最初、xxx dw2 yyy.dll が見つからない、と言うメッセージ・ボックス
が出たのだが、そのdllを検索すると MinGW/bin にある事が分かって、
そこにパスを通したらそのメッセージ・ボックスは出なくなった。

その代わりに >>721 のメッセージ・ボックスが出るようになった。

**デフォルトの名無しさん** · 2014/09/02(火) 20:55:48.58

結論的に言うと、自分のローカルにMinGW32 の別バージョンが沢山あった。
サンプルのコンパイルに使われたのと同じMinGW32のbinだけをパスに
設定してからサンプルを起動すると実行できるようになった。
実行結果も問題ない。実行ファイルはstripするとサイズが小さくなったが、
>>691のライブラリをリンクした物よりも大きくなってしまった。

[wxStringを使った最小な cui program のサイズ]

・>>691 のwxライブラリ使用時 : 451,584 bytes
　コンパイラは CodeBlocks付属のMinGW

・configureしたwxライブラリ使用時 : 547,342 bytes
　コンパイラは cygwinにインストールしたMinGW

[wxFrameを使った最小な gui program のサイズ]

・>>691 のwxライブラリ使用時 : 1,611,264 bytes
　コンパイラは CodeBlocks付属のMinGW

なお、今回は、>>719-720 のような不具合を回避するため、RegExや、png,jpeg,tiff,zlib
などはconfigureで有効にしておいた。そうすると>>720の最初のヘッダファイル問題は
消えたので、何か良いことがあるかと思ったから。ただし、様子を見るとそれは必要なかった
かも知れない。サイズ縮小のためには disable にすべきかも。

**デフォルトの名無しさん** · 2014/09/02(火) 21:12:01.59

よかったな
-Wl,-Bstatic -lstdc++ -Wl,-Bdynamic
にすればlibstdc++とスタティックリンクできるかもな

**デフォルトの名無しさん** · 2014/09/02(火) 22:46:11.97

cygwin版のMinGWと、cmd.exe 版のMinGWって結構違うような気がしてきた。
Makefileなんかもcygwin版だと/cygdrive/c/xxx/yyy/zzz の形式になっている
のに対し cmd.exe版は c:\xxx\yyy\zzz になっているらしい。
また、コンパイラに -I 指定したパスなんかも同様の違いがあるらしく、
configureが作ったMakefileは、cygwin版MinGW用で、
cmd.exe版のMinGWでは、#inclde "wx/setup.h" のパスが探せなかったり
する。

build, host, target の指定は、全て mingw を指定していたのだから、
cygwinが入り込む余地は無かったはず。これは、configure.inか、
Makefileのどちらかを自前で修整する必要がありそう。

さらに、makeが(？)
process_begin: CreateProcess(NULL, sh xxxxxx, ...) failed.
というエラーを出すことがあり、その原因を探る必要もある。

**デフォルトの名無しさん** · 2014/09/02(火) 22:56:33.59

もう完璧にスレ違いだな

**デフォルトの名無しさん** · 2014/09/02(火) 22:56:38.09

cygwin版のMinGWと、cmd.exe 版のMinGWって結構違うような気がしてきた。
Makefileなんかもcygwin版だと/cygdrive/c/xxx/yyy/zzz の形式になっている
のに対し cmd.exe版は c:\xxx\yyy\zzz になっているらしい。
また、コンパイラに -I 指定したパスなんかも同様の違いがあるらしく、
configureが作ったMakefileは、cygwin版MinGW用で、
cmd.exe版のMinGWでは、#inclde "wx/setup.h" のパスが探せなかったり
する。

build, host, target の指定は、全て mingw を指定していたのだから、
cygwinが入り込む余地は無かったはず。これは、configure.inか、
Makefileのどちらかを自前で修整する必要がありそう。

Makfileの / を \ で置換して、/cygdrive/x/ を x:/ にしてみたら結構
行ける。途中、pch でファイルにアクセス拒否で書き込めないと言われるが、
もう一度 make すると、何事も無かったように続行する。

**デフォルトの名無しさん** · 2014/09/02(火) 22:57:58.06

>>732
wx アプリのサイズダウンの仕方関連なんだけど。

**デフォルトの名無しさん** · 2014/09/02(火) 23:40:17.26

作ったバイナリのサイズなんてwxWidgetsのビルド方法によって大きく変わるうえ、
最終的に使い物にならないライブラリの出来上がりとなるのが目に見えている
本当に必要なものだけを炙り出すつもりなら止めはしないが、どう考えても徒労でしかないと思うぞ

**デフォルトの名無しさん** · 2014/09/02(火) 23:47:28.37

正直wxWidgetsのバイナリサイズの話以外はほとんど既出だし
CygwinとMinGWの仕様の違い、クロスコンパイラのターゲット、configureの基本
それらの件に関しては自分のブログにでも書いていてほしい

**デフォルトの名無しさん** · 2014/09/02(火) 23:54:47.98

まあ一応上から目線でコメントしとくと

>>725
libgccの存在に関して勉強不足、>>726の言うとおりdllの種別が２種類ある
DLLにするよりもlibgccだけスタティックリンクしたほうがいいが、libtoolにかませるのが
割と面倒なので一緒に配布したほうが楽、まぜこぜにするとか初心者くさい

>>727
クロスコンパイラとネイティブコンパイラを混同している

>>731
もうネット上で一万回は言及されたであろうCygwinとMinGWのファイルパスについて
述べているが無駄なのでやめてほしい、てか環境を混ぜるな

**デフォルトの名無しさん** · 2014/09/03(水) 00:12:32.54

>>737
最後の段落について。

・cygwin版のMinGW ---> ファイル名はUnixライクな /cygdrive/c/xxx/yyy/zzz 形式だが、
　　　　　　　　　　　　出来た実行ファイルはcygwinが無くても動作する。
　　　　　　　　　　　　ユーザー・プログラムからは主にWin32 APIを使う。

・cmd.exe版のMinGW ---> 何もかも Windows 用。ファイル名もDOS式、
　　　　　　　　　　　　出来た実行ファイルは Windows のみで動作。
　　　　　　　　　　　　ユーザー・プログラムからは Win32 API を使う。

・cygwinのgcc　　　 ---> cygwin環境で動く実行ファイルを作成する。
　　　　　　　　　　　　ユーザー・プログラムからはUnix系関数を使う。

**デフォルトの名無しさん** · 2014/09/03(水) 00:20:01.40

>>738
スレ違いだ、こっちでやれ
Cygwin + MinGW + GCC 相談室 Part 7
http://peace.2ch.net/test/read.cgi/tech/1357019230/

あとMinGWはcmd.exeではなくminttyから使うべきだ
さっさとネットで資料を探す作業に戻るんだな

**デフォルトの名無しさん** · 2014/09/03(水) 00:37:00.57

ちなみに c:\cygwin\bin と c:\cygwin\usr\local\bin にパスを通せば、
cmd.exe からでも cygwin のコマンドが実行できるようになる。
gccもlsもmakeも。ここでbashを起動すればcygwin環境になる。

**デフォルトの名無しさん** · 2014/09/03(水) 08:47:34.91

久しぶりに２ちゃん観に来たら
wxのスレめっちゃ野比てて嬉しい

**デフォルトの名無しさん** · 2014/09/03(水) 14:50:56.74

wx のソースを修正したら、wxString() を使った最小サンプルが、
静的リンクしても 70KB で済むようになった。

PATHには、MInGW/bin しか設定せずにテストしているので、wx の DLL
がリンクされている可能性は無く、間違いなくスタンド・アローンの
プログラム。

ちなみに、wx のソースを修正しなければ、451,584 バイトになってしまう。
>>729 に書いたものとほぼ同じプログラムだから。

**デフォルトの名無しさん** · 2014/09/03(水) 15:05:09.35

wxというよりgccとライブラリのお話で伸びている

**デフォルトの名無しさん** · 2014/09/03(水) 16:58:33.04

>>742
dllの依存関係すらまともに調べられないのか
dependency walkerとかobjdumpとか使え

**デフォルトの名無しさん** · 2014/09/03(水) 17:02:39.87

mingw入ってるならlddコマンドでもいける＞依存動的ライブラリ

**デフォルトの名無しさん** · 2014/09/03(水) 18:30:34.52

ただ、パス設定を空にして起動できるかどうか見るのも1つの確実な方法。

**デフォルトの名無しさん** · 2014/09/04(木) 03:37:02.91

性格悪いな。
コンピュータ・ソフト関連の人って。

**デフォルトの名無しさん** · 2014/09/04(木) 17:23:39.03

GUIアプリのサイズ縮小を試みていたが、断念するかも知れない。

**デフォルトの名無しさん** · 2014/09/04(木) 18:46:24.22

△性格が悪い
○無駄が嫌い
◎無駄な事をしてる奴が嫌い

**デフォルトの名無しさん** · 2014/09/05(金) 15:14:57.29

>>749
何も悪いことをせず、自分にも害を与えない人を嫌うのが性格が悪いんだよ。

**デフォルトの名無しさん** · 2014/09/05(金) 15:46:20.79

公園の蚊を駆除するのに外側からじゃなくて内側から始めるとかが無駄
自分にも危害が及ぶので嫌

**デフォルトの名無しさん** · 2014/09/05(金) 17:37:07.79

>>749 >>750
言われた側が一方的に立場が悪くなるという効能は興味深いと思う
言ったもん勝ちという現象は絶対にあるのだ
>>751
生死にかかわる難しい判断を
「無駄なこと」に無理やりおしこめた詭弁
物事を矮小化させる効果もある

**デフォルトの名無しさん** · 2014/09/05(金) 18:18:43.88

>>751
正直言って、今回のこととの関連も分からない。
それ以前に外側から、内側から、ということの意味が全く分からない。
まるで会話ロボットが生成した文書のようだ。

>>752
この文書も意味不明。人間が書いたとは思えない全く理解できない文書だ。

**デフォルトの名無しさん** · 2014/09/05(金) 22:33:12.96

俺の大好きなwxWidgetsスレがめちゃんこ糞スレになって泣きそう

**デフォルトの名無しさん** · 2014/09/05(金) 22:52:37.72

案の定あらし化したか
これ以上触れないで放っとくの推奨

**デフォルトの名無しさん** · 2014/09/10(水) 10:22:55.86

wxWidgets って、GTK をバックエンド(port to)に使うことも出来るらしい
ね（wxGTK）。

上位のツールキットが、下位のツールキットに被さっているってことか。

X11 を直接バックエンドに使うのともまた違うのかな？

**デフォルトの名無しさん** · 2014/09/10(水) 18:37:52.75

　　　　　　＼　　　　　　　ヽ　　　　　 |　　　　　　　/　　　　　　　　／
　　　　　　　　　＼　　　　ヽ　　　　　　　　　　　/　　　　　　／
‐､、　　　　　殺　伐　と　し　た　ス　レ　に　鳥　取　県　が　！　！　　　 _,,－''
　　｀－､、　　　　　　　　　　　　　　　　　　__／＼　　　　　　 _,,－''
　　　　　｀－､、　　　　　　　　　　　　　 _|　　　 `～┐ 　　　　 _,,－''
　　　　　　　　　　　　　　　　　　　　　_ノ　　　　　　 ∫
　　　　　　　　　　　　　　　　　　＿,.～’　　　　　　　　/
───────‐　　　　　,「~　　　　　　　　　　　ﾉ　　 ───────‐
　　　　　　　　　　　　　　　,/　　　　　　　　　　　　　｀￣7
　　　　　　　　　　　　　｜　　　　　島　根　県　　　　/
　　　　　　　　 _,,－'　　　~`⌒^7　　　　　　　　　　　 /　　　｀－､、
　　　　 _,,－'' 　　　　　　丿　　　　　　　　　　　＼, 　　　｀－､、
　,'´＼　　　　　　　　／　　_７　　　　　　／`⌒ーへ＿,._⊃　　　　　　　　　／｀i
　!　　＼　　　　　 _,,-┐ 　　＼　　　＿,.,ﾉ　　　　　　　ｒ‐-､、　　　　／　　!
　ﾞ、　　　｀ー--＜´ 　 / 　　　　Ｌ. ,～’ 　　　　　　　　　ﾞ、　　＞－一'′ 　　,'
　　y'　　U 　　　｀ヽ/ 　　 / 　　　　　　　　　　　ヽ　　　　ヽ '´　　　　　U　　ｲ
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＿＿＿＿
　　　　　　　　 /　　　　　＿＿　　　　　　 |　　　　　　＼＿＿＿＿＼
　　　＿＿＿/＿＿　/￣　　　　＿＿＿＿|＿＿＿＿＼＼＿＿＿＿＼
　　　　　／/ヽ　　 /＿＿＿　　　　／|＼　　　　　　＼＼＿＿＿＿＼
　　　　／　/　ヽ　 /　/＿＿　　　　　／　 |　＼　　　　　　＼＿＿＿＿＿＿＿
　　　／　　/　　／／　　　/ 　　／　　 | 　　＼　　　　　　　 |　　＼
　／　　　/　／／　＿／　 __／　　　 |　　　＼__　　　　　　|　　　　＼　￣―＿

**デフォルトの名無しさん** · 2014/09/11(木) 00:33:29.51

>>756
X11は組み込み向けのportなので一般的には使われないよ（メンテされてるかもよくわからん）
Linuxでの使用の際はGTKベースと思っていた方がいい
つまりwxWidgetsのクラスやメソッドでコードを書いてLinux上でビルドするとGTKアプリができる

最近はwxQtというwxWidgetsからQtをバンドルするイカれたプロジェクトが本流にマージされたようだが…

**デフォルトの名無しさん** · 2014/09/11(木) 07:34:16.28

wxQtってなんかメリットあるの？

**デフォルトの名無しさん** · 2014/09/11(木) 20:49:49.06

>>759
目的は、Qtベースのデスクトップ（KDE）でもwxWidgetsアプリを使うためとか
（→まあKDE上でGNOMEアプリを使うツールもあった気がするのだが…）
あとQtをバンドルすることでAndroid対応も果たしていた（実用性は不明）

**デフォルトの名無しさん** · 2014/09/12(金) 10:47:54.87

wxWidgetsで、POPUP Menu (Windows では、Context Menu が正式名称かも)を作る場合、
どうしてますか？

特に、CodeBlocksなどのIDEで行う場合の最良の作法が知りたいです。
自分は、基本的な wxSmith の使い方が分かったところです。

**デフォルトの名無しさん** · 2014/09/12(金) 11:29:17.36

MenuItem作って
SubMenu作って
AddItem

**デフォルトの名無しさん** · 2014/09/12(金) 11:47:23.49

>>762
それは手作業の場合ですよね。
そこの部分は対した手間ではないですが、
イベント・ハンドラを*.cpp, *.h, EVENT_TABLEの全てに書くのが面倒で。

**デフォルトの名無しさん** · 2014/09/12(金) 11:47:52.57

どうぞ
https://www.youtube.com/watch?v=jCW7DZ6gdAo

**デフォルトの名無しさん** · 2014/09/12(金) 12:20:43.41

>>764
これ、今ちょうど数秒前に見終わったところだった。

これ見てると、

1. wxSmithでwxFormをエディット中に、「MenuBar」ではなく「Menu」ボタンを押して
　「要素」を追加する。
　そうするとwxSmithの上辺に要素のアイコンが並んでいる末尾に新しいアイコンが追加される。
2. 追加したMenu要素に名前を付ける。
3. wxFormの中に既に配置してあったwxPanelに対して、マウス右UPイベントに対応するハンドラを追加する。
4. そのハンドラの中に、手作業で PopupMenu()関数の関数呼び出しを書き、
　その引数に2.でMenuに付けおいた名前を書く。

こここまでは大した手間じゃない。

その後が問題で、EVENT_TABLE の「自動的にwxSmith が作成する範囲」の外側（直後）に、
POPUP MENUのMENU項目数分だけ、手作業で Connect() 関数を書いている。メニュー項目が7個だと、
Connect()関数も7個書く。それぞれ、MENU項目に付けた ID_xxxx の値と、対応する自前の
イベント・ハンドラの関数名を引数に指定して。

最後の部分が知りたかった事で、POPUP MENUの作り方としてはかなり面倒な方法に属する。

**デフォルトの名無しさん** · 2014/09/12(金) 12:28:57.27

馬鹿には無理

**デフォルトの名無しさん** · 2014/09/12(金) 14:27:34.99

7個のメニュー項目にイベント結びつけるのに7行コード書くのって、そんな突出して面倒か？

**デフォルトの名無しさん** · 2014/09/12(金) 15:27:57.79

>>767
それは、「EVENT_TABLE」の箇所だけの話で、実際は、*.h に
メンバ関数宣言を7つ書き、*.cpp に
Zzzz Ccccc::OnXxxxx( Yyyy *pYyyy )
{
return Qqqqq;
}
みたいなの(4行)を 7 つ書く必要がある。

少なくとも (1+1+4)*7 = 42 行だ。

**デフォルトの名無しさん** · 2014/09/12(金) 16:36:39.60

IBみたいなのを期待したら駄目

**デフォルトの名無しさん** · 2014/09/12(金) 19:11:10.85

なんで今更wxSmithなんだよ古臭いな
なんでイベントテーブル使ってんだよ古臭いな
黙ってwxFormBuilder使ってみろよメッチャ簡単で笑えるぞ

**デフォルトの名無しさん** · 2014/09/12(金) 19:15:42.12

>>770
IDEとの組み合わせは？

IDEがサポートしていなくてもいけるんだろうか？

**デフォルトの名無しさん** · 2014/09/12(金) 19:26:00.24

>>771
ちんまい個人用ツールしか作った事が無いから大規模プログラムでどうなるかは分からんが、
俺はwxFormBuilderでGUIデザインし、VisualStudioでコード書いてる。
GUI部品を追加したくなったら、いつでも追加編集できる。
もちろんイベント追加も問題ない。
VSでコード書きつつGUIエディットしても、VSにフォーカスを移したら勝手に読み込み直してくれる。

今まで書いたコードがGUI生成時に消去される事も無い。
これにはちょっと条件があるけどな。

**デフォルトの名無しさん** · 2014/09/12(金) 19:30:56.63

>>772
POPUP MENU を作る時、EVENT_TABLE を使わずに何か良い方法で
やってくれるのかな？

**デフォルトの名無しさん** · 2014/09/12(金) 19:38:30.73

wxFormBuilderかあ
もはやクロスプラットフォームでGUIがGUIでデザインできるのか（しかもフリーソフトウェア）

**デフォルトの名無しさん** · 2014/09/12(金) 19:39:02.29

VSは、外部エディタでソースを編集した場合、VSに戻ると自動的に再ロード
してくれる機能がある事は知ってる。これは昔からある機能。

**デフォルトの名無しさん** · 2014/09/12(金) 20:52:41.52

>>773
凝りに凝ったメニューは知らんが、ポップアップメニューの作成および
メニュークリック時のイベント生成なんかは全部wxFormBuilder上で出来る。
従来のイベントテーブルでも生成してくれるし、Connect関数を使ったイベント生成も出来る。
今はConnectも古くてBindがトレンドらしいが、詳しくは知らない。

http://www.dotup.org/uploda/www.dotup.org5309542.zip.html
参考までに、wxFormBuilderのみで作ったサンプルコードを添付する。
自分で書いたのはmain.cppとthis->Close();だけ。
VS2013 + wxWidget3.0.1でビルド確認済。

**デフォルトの名無しさん** · 2014/09/13(土) 07:40:07.50

>>776
これは、どうやって作ったの？
生成されたコードも参考にはなるけど、wxFormBuilder上での操作方法が
知りたい。

**デフォルトの名無しさん** · 2014/09/13(土) 16:39:39.92

>>777
説明がめんどくさいから、wxFormBuilderでこの「wxMenuTest.fbp.」を開いて確認してくれ。
あとは適当に触ってれば理解できるだろ。
http://www.dotup.org/uploda/www.dotup.org5310926.zip.html

適当にGUIを作ったらF8キーでメインクラスを生成して、
その後F6キーでサブクラスを生成すればいい。

あとは添付した「main.cpp」みたいなコードを書いてビルドすれば目出度くGUIプログラムの完成だ。

**デフォルトの名無しさん** · 2014/09/13(土) 17:37:50.07

レイアウトやイベントの仕様が
前もって分かって一発で決まるようなものならいいけど
そうでない場合は細かいテクが必要になるんだよなぁ
VB,delphi,VisualStudio他のポトペタとは違って
基本クラスや継承クラスの生成コードは
上書きしちゃってよしなにしてくれないから目視マージが必要になる
で、それならxrcでいっかなとなったりとね
あとは最近のバージョンでは修正されてるかも知らないけど
splitter > panel > sizer > xxx
の深いネストが嫌いだったな
バグだよね

**デフォルトの名無しさん** · 2014/09/13(土) 18:03:46.11

>>778
出来れば言葉で説明していただけるととても有難いんだけれども。

**デフォルトの名無しさん** · 2014/09/13(土) 18:20:32.24

>>776
MyProject1MyFrame1.cpp に、

void MyProject1MyFrame1::m_button1OnButtonClick( wxCommandEvent& event )
{
　　// TODO: Implement m_button1OnButtonClick
　　this->Close();
}

と類似の行が沢山あるけど、this->Close() 以外は、wxFormBuilder が自動生成したとのことで Ok ？

>>779
>基本クラスや継承クラスの生成コードは
>上書きしちゃってよしなにしてくれないから目視マージが必要になる
>で、それならxrcでいっかなとなったりとね

この辺りとの関連が知りたい。自分で書いたコードが勝手に上書きされて消されてしまうということ？

**デフォルトの名無しさん** · 2014/09/13(土) 18:22:33.01

そもそも wxFormBuilder って、人間が書いたコードと「マージ」や「アペンド」する機能は全くなくて、
デザイナのテキスト領域に表示されるコードをコピペして使う程度の事しかできないのかな？

**デフォルトの名無しさん** · 2014/09/13(土) 18:27:14.64

xrcはwxFormBuilderだとwxRibbonとかで生成に抜けがあるよね
これ自体はそのうちなおるだろうけど、案外使われてないのかなxrc

**デフォルトの名無しさん** · 2014/09/13(土) 18:54:43.70

class MyFrame1 : public wxFrame {・・・};
class MyProject1MyFrame1 : public MyFrame1 {・・・};

となっていて、

http://stackoverflow.com/questions/8255753/how-to-add-personal-code-into-wxformbuilder-generated-class

の

・build your frame/panel in formbuilder
・generate inherited class
・implement your handling code in inherited class
・make changes to form/panel in wxFormbuilder ->
　will only affect generated class, not inherited class

の最後の行と矛盾するね。

wxFormBuilder は、MyFrame1 は書き換えるが、それを継承した所の MyProject1MyFrame1 は、最初の
一回しか書き換えない（というよりユーザーが指示しないと生成しない）、ということらしいから。

**デフォルトの名無しさん** · 2014/09/13(土) 18:57:59.23

つまり、>>781 のイベント・ハンドラにおいて、this->Close(); の外側の部分も手作業で
書くしかないのではなかろうか？

そして、対応する *.h ファイルの中に、同じ関数のメンバ関数宣言も手作業で追加するしかないのでは？

**デフォルトの名無しさん** · 2014/09/13(土) 19:05:46.06

実装の中身以外は何一つ手では書かないっていうなら、wxWidgetsは投げ捨てて
QtCreator有するQtか、C++ Builderあたりを使うしかないよ。
wxFormBuilderはIDEじゃないし。

**デフォルトの名無しさん** · 2014/09/13(土) 19:07:33.52

>>786
QtCreator では、それが出来るのかな？

**デフォルトの名無しさん** · 2014/09/13(土) 19:09:46.08

XRC最強なんですけど

**デフォルトの名無しさん** · 2014/09/13(土) 19:18:48.99

>>785
言葉通りに受け取ってくれればいい。
本当に「this->Close();以外書いてない」んだ。
つまり関数実装部は全て自動生成される。

つーか試してくれよ。
これだけ御膳立てしたんだからさ。

**デフォルトの名無しさん** · 2014/09/13(土) 19:23:58.85

>>789

大体、答えが分かった。

つまりあなたは、wxFormBuilder に MyProject1MyFrame1 を生成させて、
this->Close();
を追加したんだ。

そいういうやり方だと、ボタンやメニュー項目を一つ増やす度に、手作業で、また、
this->Close();
を自分で書かなきゃならない。

それが、>>779 の意味だね？

だとすれば、this->Close(); の部分は、実践的には、もっと長くなるのだから、
物凄く面倒で、なおかつ危険が伴う作業になるね。

**デフォルトの名無しさん** · 2014/09/13(土) 19:27:26.32

>>790

>そいういうやり方だと、ボタンやメニュー項目を一つ増やす度に、手作業で、また、
>this->Close();
>を自分で書かなきゃならない。

ここの部分を補足すると、その時に追加したボタンやメニュー項目に対するハンドラだけ
でなく、既に存在していたボタンやメニュー項目に対する全てのハンドラの中身を手作業で
コピーする必要があるということになる。

ボタンやメニュー項目の個数をN とすると、O(N^2) の作業時間が必要になるね。

**デフォルトの名無しさん** · 2014/09/13(土) 19:44:06.05

>>790
> そいういうやり方だと、ボタンやメニュー項目を一つ増やす度に、手作業で、また、
> this->Close();
> を自分で書かなきゃならない。

そこらへんに少しコツがあってな。
自動生成された部分を一切変更しない限りにおいて、
後から機能追加して再度サブクラスを生成した時、以前書いた部分は削除されない。
つまり今回の例では「this->Close();」は消えずに残る。
逆に言えば「// TODO～」コメントの削除や編集すら許されないという事なんだけどな。

これが守られなかった場合、同名の(空の)関数が別に生成される。
この場合は旧関数から新関数へのコピペおよび旧関数の削除の手間が生じるが、
いずれにせよ一度書いたものが消える事は無い。

ヘッダファイルにおいても同様であり、
//// end generated include と
/** Implementing MyFrame1 */ の間、それと
//// end generated class members 以降の行に書いた内容は削除されない。
安心して機能追加できる。
不安だったら再生成する前にバックアップ取っておけばいい。

問題があるとすれば、コードのインデントが全て消える事。
Eclipse等開発環境のコードフォーマッタで解決するが、3.4.0beta時点では
インデント維持されてた筈なんだ。なんで維持されなくなったんだ？
俺の見落しか仕様かバグか。

**デフォルトの名無しさん** · 2014/09/14(日) 06:35:44.14

なるほど、wxFormBuilderも新規出力（全書き換え）しかできないわけではないという
ことなの？

どうやるのかな？

**デフォルトの名無しさん** · 2014/09/14(日) 06:44:15.89

あと、EVENT TABLEが古いと言ってる人がいたけど、Connect()がそれに置き換わっただけ
だからね。使う側から目線では（抽象的な意味では）変わってない。配列で静的に持っているか、
関数で登録するかの違いに過ぎないから。

**デフォルトの名無しさん** · 2014/09/14(日) 07:18:40.80

以下によると、wxSmith には、TOP LEVEL RESOURCE を2つ以上作成する方法が見つからないらしい。
いったん、1つのTOP LEVEL WINDOW を作ると、全てがそのウィンドウの子供になってしまう。
POPUP MENU や、メインウィンドウに付随する1群のダイアログは、作るのが難しいらしい。
それに対して、wxFormBuilderは、2つ以上の TOP LEVEL RESOURCE を作ることが出来る、
と主張している。

http://forums.codeblocks.org/index.php?topic=15742.0

It's one of reasons why I have switched from wxSmith to wxFormBuilder.
I haven't found how can I create more than one "top level" resource in my XRC file using wxSmith.
Once I created a top level window, everything needed to be a child of this window.
Create a set of popup menus? Forget it. Create a set of dialogs along with your main window? Forget it.
wxFormBuilder allows more than one top level resource.
Moreover, wxFormBuilder can create only a XRC file - well, it creates a code, too,
and you can paste parts of the code in your own code.

I am curious what I have missed. I am a "XRC user", too.

**デフォルトの名無しさん** · 2014/09/14(日) 10:11:50.71

お前が返信に時間かかってるのは煽るための文言を探してくるためか？
これだけ御膳立てしてやっても自分では一切手を動かす気は無いんだから、
呆れを通り越して笑いすら出てくるわ。俺はお前の保護者じゃねえよ。
英文は読めるみたいだからソフトの使い方が分からない筈があるまいに。

>>793
こんな問いに答える気はもう無い。理由は上記の通りだ。
今まで以上に噛み砕いた説明は俺には出来ないし、
そもそも手を動かしていれば既に理解している筈の内容ばかりだからな。
F8とF6からクラス選んで名前付けてコード生成すら出来ん奴が本当にプログラム書けるのか？
無理しないでVSやMonoでC#あたり使ってればいいんじゃないか？
そっちの方がずっと楽だぞ。

>>794
それ書いたのは俺だが、利用上はそれだけの違いでは済まないという事も
英文読んだなら理解できてるはずだろ。煽るためのネタにはならんぞ。
柔軟性は高いに越した事はなかろうよ。
もちろんその機能が自分にとって役立つかどうかは別問題だ。

**デフォルトの名無しさん** · 2014/09/14(日) 12:57:54.21

>>796
誰も悪気がやってやってるわけじゃない。
あなたが勝手にそう取ってるだけだよ。

**デフォルトの名無しさん** · 2014/09/14(日) 19:26:47.68

>>791
それは難癖だよ
継承側で動的バインドという
他と同じ手法を取ればいいだけの話だから
手間はおんなじだよ

>>792
その癖やコツをつかむのに
試行錯誤したりソースを読み解く必要性があるのが辛いんだよね
正味な話不安で信用ならない
手動目視でDiffるか
PEGでも使って自前で書いたほうが楽

**デフォルトの名無しさん** · 2014/09/14(日) 19:52:29.25

>>798
前半意味不明です。

**デフォルトの名無しさん** · 2014/09/14(日) 20:11:08.81

>>799
> ここの部分を補足すると、その時に追加したボタンやメニュー項目に対するハンドラだけ
> でなく、既に存在していたボタンやメニュー項目に対する全てのハンドラの中身を手作業で
> コピーする必要があるということになる。

電卓とか参考になると思うよ

**デフォルトの名無しさん** · 2014/09/15(月) 08:45:18.98

>>800
ならないと思う。
全てのボタンを一気に wxFromBuilder で作ってからイベントハンドラの
コードを手作業で書けば問題は表面化しないから。

そうでなくて、実際のプログラミングでは、機能追加のたびにボタンを追加して行く
ような作業が必要となる。

その時に上書きされてしまうかどうかがポイント。

**デフォルトの名無しさん** · 2014/09/15(月) 10:58:47.94

xrcでFA

**デフォルトの名無しさん** · 2014/09/15(月) 19:07:00.41

だから「ソフトの様式さえ守っていれば」書いたコードが消去されるような事は無いと何度言えば分かってくれるんだ。
試してないのが丸判りだ。ほんっっっっっっとに口ばっかりだなお前は。
これで悪気が無いというんだから最悪だ。本当に本当に最悪だ。

そもそもwxFormBuilderで生成したイベント部に何十行も書くのか？
保守性考えたら、C++だったら別にクラスや関数作って、そっちに処理ブン投げて終わりじゃないか？

**デフォルトの名無しさん** · 2014/09/16(火) 00:01:13.35

>>803
全部自分で試さなきゃならないなら、人に聞く権利がなくなるじゃん。
試すのが時間がかかりすぎるから、誰かが試した結果が文書化されるん
だから。

**デフォルトの名無しさん** · 2014/09/16(火) 02:40:02.42

これは一緒に仕事できないタイプですわ

**デフォルトの名無しさん** · 2014/09/16(火) 02:41:50.55

自分はネット上に調べ物を書くときは自分が試した範囲のことしか書かないよ
妄想の実行結果で文句言ったりしないし、困難があれば自分で突破する

**デフォルトの名無しさん** · 2014/09/16(火) 09:52:32.15

「共助」という概念を知らないの？
「自助」しかしてはならないなら、掲示板の意味がほとんど無くなる。

**デフォルトの名無しさん** · 2014/09/16(火) 15:26:46.89

>>803
>そもそもwxFormBuilderで生成したイベント部に何十行も書くのか？
>保守性考えたら、C++だったら別にクラスや関数作って、そっちに処理ブン投げて終わりじゃないか？

これは駄目。

なぜなら、また、*.cpp と *.h に決まりきったコードを書く必要が出てくる
から。イベントハンドラ 1 つずつにこれを書く作業が大きなロスを
生む。

**デフォルトの名無しさん** · 2014/09/16(火) 22:49:04.68

>>804
共助？お前だけは言っちゃいかん言葉だ。
1から100まで他人に聞いてばっかじゃんかお前。
お前がスレの閲覧者に対して何か有益な事一つでも書いたか？
ぜ～～～～～んぶ愚痴もしくは煽りじゃんか。

全部自分で試さなきゃいけないとか言ってるがよ。
そもそもお前、俺の言った事何一つ聞く気が無いだろ？
徹頭徹尾お前はコードが消える前提でしか話してない。
信じてるなら未だにコードが消えるなんて言ったりする筈が無いからな。
書かれた事を信じず、そのくせ試す気も無い奴が共に助け合う？笑わせんな。

あと、決まりきったコードを書く必要が出てきてはダメな理由がまるで分からん。
そもそも一度書いたら終わりなのに、なんでロスなんだ？
具体例をサンプルコードで挙げてくれないか。
共助とか抜かしてるんだから勿論やってくれるよな？

**デフォルトの名無しさん** · 2014/09/16(火) 22:56:48.49

>>809
もうほっとけよ。相手するだけ無駄だ。

**デフォルトの名無しさん** · 2014/09/16(火) 23:45:52.12

>>809
あんたが作ってるプログラムとは規模が違うからだよ。

**デフォルトの名無しさん** · 2014/09/16(火) 23:46:54.65

てか決まりきったコードを減らすためのテンプレート？
そのためのメタプログラミングでしょ

**デフォルトの名無しさん** · 2014/09/17(水) 00:02:45.14

>>812
はあ？