【GUI】wxWidgets(旧wxWindows) その5【サイザー】
クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)についてのスレ。 本家 ttp://www.wxwidgets.org/ wxWindows日本語プロジェクト ttp://wxwindowsjp.sourceforge.jp/ Cross-Platform Programming with wxWidgets ttp://wxwidgets.info/ Let's wxWidgets ttp://dot-gray.s33.xrea.com/ wxWindowsで始めるC++ GUIプログラミング ttp://www.h3.dion.ne.jp/~k5_n/wxwin/ wxWidgets でクロスプラットフォーム GUIアプリを作ろう ttp://0xcc.net/pub/uu-2004-08/ 前スレ 【GUI】wxWidgets(旧wxWindows) その4【サイザー】 http://pc12.2ch.net/test/read.cgi/tech/1214657360/ >>596 理想の実装になるかわからない&C++しかわからないが wxMenuをそのまま使うのが良いと思います 実装の骨子 ・メニューの項目一つ一つにwxWindowID ( enum )を振る ・wxWindowIDはwxCommandEventで起動するようにしておく ・上記のwxCommandEventを処理する関数はenumをswitch文で処理する ・wxCommandEventはEVT_MENU_RANGEで定義しておく(enum値が 1000~1200の場合反応する関数を作るなど) アイテムを編集可能にするために ・EVT_UPDATE_UIをwxMenuに設定しておき、ユーザーがメニューの項目を触ったら更新を実施 右クリック ・wxのConnectとかBindでwxMouseEventをくっつければいいと思う ------------------------------------------------------- 上記をやろうとすると、ユーザーが設定した項目でループを回して常に更新かける 感じになるんじゃないでしょうか。 wxMenu *menu = new wxMenu; wxMenu *foo = new wxMenu; for ( ユーザーが設定した数だけループ ) { foo->Append(wxID_HOGEHOGE_RANGE + i , wxT("ユーザー設定項目1")); foo->Connect(); // 右クリックイベントを定義しておく } >>597 レスありがとうございます。 wxMenu に対して Connect/Bind を試してみたのですが、 クリックイベントは wxEVT_MENU または wxEVT_MENU_RANGE だけが呼び出されました。 LEFT_UP, RIGHT_UP, COMMAND_LEFT_UP, COMMAND_RIGHT_UP, CONTEXT_MENU のイベントを試しましたが、 こちらは EVT_MENU の有無にかかわらず呼び出されませんでした。 試したソースコード : http://codepad.org/S9vtw4yX wxEVT_MENU の際に右クリックか左クリックかわかれば処理を分岐できるのですが、 wxCommandEvent でクリックしたボタンの情報の取得方法がわかりません。 wxWindow::PopupMenu では wxMenu を参考にして GUI を作り出すようですが、 そこですでにイベントが途絶えているように思えてしまいます。 ウィンドウハンドルも得られないようだし、 ポップアップメニューにイベントを追加することはサポートされていないように感じます。 wx.ListCtrl でも思ったことなのですが、 wx.CommandEvent 系のイベントを使うコントロールクラスでは wx.MouseEvent 系のイベントは関連付けられないのでしょうか? >>598 う〜ん、メニュー上での右クリックは悲しいことにできなさそうね [wx-users] Trapping wxMouse events over wxMenus https://groups.google.com/d/msg/wx-users/xAGPwk-f9Ao/0BGV9JD55L4J この会話の中で、Vadimさん(wxWidgetsのコミッタ)が無理やでとか言ってる メニューの項目の中で右クリックするとイベントはメニューのほうに行ってしまう から、そのイベントをつかむのは無理だと。 で、それはWindowsとGTKのネイティブ実装がそうなっているから。 > Ideally, I would like to be able to left-click and > right-click WITHOUT the menu disappearing. This is impossible under the two main platforms: MSW and GTK. Menus grab the mouse when popped up (down?) and so all mouse events go to them. いや、ちょっと違うか メニューの右クリックイベントは掴めるけど その時呼び元のメニューの項目が消えるといってるのか その解決策としてはwxMenuを使わずに menuのウィジェットを自分でエミュレートするしかないとのこと >>599-600 ありがとうございました。 wxMenu を流用できないのは残念ですが、 これで踏ん切りがつけたので、 wxListCtrl を使ったものを試そうと思います。 引き続き、wxListCtrl のような wxControl 派生に対して wxMouseEvent 系のイベントをつける方法を求めていますので 何か参考になることがありましたらよろしくお願いします。 >>601 です。 >>596 について進展したので参考になればと思い報告します。 メニューアイテムの上で右クリックしてポップアップメニューを表示することが可能なクラスが wxPython にありました。 wx.lib.agw.flatmenu がまさにぴったりのクラスでした。 RIGHT_UP のイベントはありませんが、 FlatMenuItem::SetContextMenu(FlatMenu) で >>596 でしたいことが簡単にできます。 自作のために PopupWindow あたりを調べているときに見つけました。 また何かありましたらよろしくお願いします。 サンプルが多すぎて逆にわからないのですが、 ランタイム時にGUIパーツを生成消滅させることって可能ですよね? 例えばユーザが読み込んだファイルによってボタンの数を変化させるなど ありがとうございます 関連するサンプルなどありましたら教えていただけると幸いです そうなんですよね〜でもsample多くてどっから見ればよいか、という感じです まあできるということがわかればとりあえず見て回ります チュートリアルで最初の方から見ればすぐ出ると思う。 デモ実行してみて自分の欲しい機能と似たものを見つけたら「ソースを見る」をクリック。 すいません、見てるものが違うかもしれないので確認させてください チュートリアルとは何を指してますか? デモはdemosフォルダの中にあるプロジェクトですよね?「ソースを見る」とはなんでしょうか? ごめん。 見てるものが違った。 wxPython の方見てた。 wxPythonのDemo見て目星を付けて wxPythonのソースを参考にwxWidgetsでCソース書くのもあり なるほど wxPythonでコードを書いたものがC++に直接変換できたりしたら便利ですね wxGladeみたいに なんか久しぶりにwxスレが伸びてるぞ、新規ユーザー大歓迎 ボタンとかテキストエリアの動的な生成は、wxPanelとかwxSizerを使った簡単なサンプルを作ったら理解できると思う 言葉で説明するよりコード書いたほうがよいけど一応書いとく 例えばボタンを生成・削除しようとする場合 親Panelをparent, 子panelをchildとすると 1. ウィジェットの生成:parentをnewして、必要な分だけchildをnew child = new wxPanel(parent, …); ... 2. ウィジェットの削除:parent.DestoryChildren(); この関数で子ウィジェットを全部きれいに削除できる 説明の意味がわからなければ、まずは適当なチュートリアルサイトに行くべし おすすめ http://zetcode.com/gui/wxwidgets/ >>614 慣れたら直接C++で書けるから多分コンバータは需要無いよ >>615 詳しくありがとうございます 拝見致します >>616 wxGladeも要りませんかね? フローはwxGladeで枠を作って機能をC++で書く感じになるのかと どっちも1992年頃にできた。OSSといえども商業的な成功がコミュニティ形成の鍵。 それ以外はGood Oldを懐かしむロートルか宗教的価値観に支えられているだけ。 GUI比較スレってなんだよね・・・ 比較的な話ってここで展開してもよいものやら というかwxWidgetとQtどっちも使ってる人っているのか 世の中のアプリケーションはQtかAwt/Swingが採用される流れ。 直交性ならgtk。サクッと安定したものを書くならtk。 トイプログラムならSDL+OpenGL。生きるとは残酷なことである。 バイナリサイズでかいですな VC2010でサイズ最適化オプションかけてもHelloWorldで5MB... これはもうどうしようもない感じ? どうしようもないっす ベース部分(wxStringとかwxWindowとか)の定義が容量食ってるから?ではないかという疑惑 うーんなるほど ランタイムで色々判断出来るような設計なんですかねえ そうですねwxWidgetsはRTTIの仕組みが活かされてるみたいなドキュメントはどっかで見た たぶんwxWidgetsの中核であるwxWindowクラスはそんなんばっかしなんだろう ファイル操作系が異様にやりにくい wxString dir_name("some directly name"); dir_name.Traverse(some_traverser,wxString(""),flags); でディレクトリたどりながらファイル抽出できるかなとおもったが flags = wxDIR_FILES だとそのディレクトリの中身”のみ”探す flags = wxDIR_DIRS だとその下の”全ての”階層のディレクトリを抽出する wxDIR_DEFAULT だとその下の”すべての”ファイルを探す なんでこんな仕様なんだ ああわかった ディレクトリが見つかった場合のみその下も探す、ということなんだな するとファイルのみだと当然下なんぞ無いからそれ以下を探すことはなく ディレクトリのみ、とすると下にもいけるから最下層まで探そうとするわけか うーん 連投失礼 Traverserクラスを継承してそのOnDir関数の返り値で制御すればいいということでした 浮動小数点を扱えるsliderってデフォルトではなさそうですか? たとえば 0 - 100 を 10 で割ると 0.0 - 10.0 のレンジになります やっぱそんな感じなんすね 最大値最小値現在値ラベル表示が便利だなーとおもったんですが、小数点付きでやろうと思ったら 自分でラベル付けるしかなさそうですね 右側のボタンを押したら左側のパネルを再描写させたい、など あるイベントから(親でない)ほかのイベントを誘発させたい時ってあると思うのですが その辺に関する記事てどっかにあります? >>634 そのへんはイベント処理の領域になりますね wxWiki見るしかない感じ イメージとしては Sample::LeftPanelRedraw(wxCommandEvent& event); というイベント関数のIDがID_LeftPanelRedrawであった場合 そのイベントは wxCommandEvent e(wxCommandEvent(wxEVT_COMMAND_BUTTON_CLICKED, ID_LeftPanelRedraw)); LeftPanelRedraw(e); で呼べる glcanvasを使ってパネルを描写し、ドラッグに反応するようにしたのですが ドラッグ中に、ポインタがパネルの範囲外に出た時に、反応が止まってしまいます sampleのdragimagではドラッグ中であれば範囲外でもイベントが取れるようですが sampleのopengl/penguinだと取れないようです マウスイベントの接続は両者ともEVT_MOUSE_EVENTSで行っているので 何が違って取れているのかわかりません その辺の事情、どなたかご存知ないですか? わかりました wxWindowBase::wCaptureMouse()を呼び出すと以降座標とイベントが取得されるようです クロスプラットフォームの開発環境について調べてるんですが、wxWidgetsの GUIは外観とかは各プラットフォームのものが使われるんですか?それとも 独自のテーマになってしまうんでしょうか? >>641 各プラットフォームのものが使われます つまりWindowsならWIN32、LinuxならGTK、MacならCocoa それぞれの外観になります 対してQtやTk、JavaのSwingなどは独自のテーマになります >>642 ありがとうございます。他の環境まで概括してくださるとは助かりました。 >>641 敢えてプラットフォームのを使わず テーマ選ぶ方法もあったはず いまこのスレ開いたら、>>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で止めておいた方が良いかも。 wxWidgetsを使って作られたプログラムの一覧ってあったりするのかね? とりあえずAudacityは知ってる おーありがとう 後で見て回る テンプレにあってもいいじゃないかな? wxWidgetsで、フォームを閉じる処理をして実際に閉じるまでの間に発生するイベントとかある? .NETで言うところのOnClosingみたいな感じで。 Windows で、 CrossBlock + MinGW + wxWidget で最も簡単な GUI アプリを基本プロジェクトで作成してみたところ、 MyTest.exe のサイズ:736KB (wxWidgetのDLL) wxmsw28u_gcc_custom.dll のサイズ : 15.9MB MyTest.exe のメモリ使用量 : 7,732KB // TaskManagerの表示 となった。 この基本アプリは、HelpでAboutでメッセージ・ボックスが表示できる ようになっているが、メニュー項目をクリックしてから実際にそれが 出るまで数秒かかる。実験したのはそこそこ速いマシンと速いWindows での事。 ただし、遅いのは最初の一回だけ。 一度でも表示すると後は速い。 Mailer の Thunderbird-Portable なんかもマルチプラットフォーム対応 だけど、起動がかなり遅い。これも巨大な dll を読み込んだりしてる からかな。 起動やメニュー操作が遅くなるのはマルチプラットフォーム化する代償 として負わされるのかも知れん。 こういうツールキットで軽快なアプリを作るのは難しいのかもな。 小規模の自作ソフトでwxWidgetsをスタティックリンクしない理由が分からん わざわざ合計バイナリサイズを大きく、速度も遅くする理由がどこにあるのだろう >>661 なるほど、スタティックリンクにすれば、起動後になってからユーザーの 命令に対する応答が遅れる事はなくなるかもしれない。 起動が遅くなるだけで済むんなら、そっちの方がストレスが少ないかも。 ある程度規模が大きくなるとスタティックリンクだと初回起動が遅すぎになので dllにモジュールを分割してやったほうがいい 起動時のメモリへのロード時間はどうしようもないのでスプラッシュをつけてごまかす CrossBlockでは、monolithic タイプのライブラリをビルドしてから使う ようになってるんだけど、それも遅い原因なのかな。 でも起動後にユーザー入力に対するレスポンスが遅いのはどう説明すれば いいんだろう? 普通の Windows の仕様だと原則、起動時に全ての DLL をロードする。 LoadLibrary()を使えば動的にロードすることも可能は可能だけど、 それをする必要は旧OSでサポートしてなかった新OSのDLLをロードする ような場合は、多言語化のサポートなど。 なるほど、多言語化のせいかも。_("xxx") みたいなのがあったから、 gettext を使ってる。それでリソースを動的ロードしているのか。 何度かアプリ起動しているうちにWindowsのFetchが学習してくれて DLLとか先読みしてくれるようにならないのだろうか >>665 それはなる。 ・ディスクの内容は、メモリにキャッシュされる。 ・同じDLLは、全てのアプリで物理メモリが共有されると聞いたことがある。 # >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。 それより、wxWidget 本家のソース配布に入っている samples を Windows の mingw32 でビルドしてみたところ、全然遅くなかった。 ・アプリの起動は速い。 ・起動後のメニューコマンドやユーザー入力に対するレスポンスも速い。 ・Aboutダイアログも瞬間ではないが、0.3秒程度で、Windows Nativeアプリ でも、その程度の遅さはある場合があるので遜色ない。 CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な ライブラリを使用しているからか。 >>666 ># >>664 は、CrossBlockではなく、CodeBlocksだった。スマン。 なんだと思ったらわりと素人じゃねえかおい >CodeBlocks で作ったものが遅い原因は今のところ謎。やはり monolithic な >ライブラリを使用しているからか。 monolithicってのはwxWidgetsのモジュール全部入りのDLL作るという意味なので遅くて当然 (実際試したことないので遅いというのは初めて知ったが…) 普通は ./configure --prefix=/mingw --enable-shared みたいに指定してビルドするから モジュールごとに分割されたDLLが作成される Windows上で開発する時はMinGW + NTEmacs/eclipse CDTの環境がおすすめ >>667 最後の段落:多分、wxWidgets 本体を MInGW32 用のビルドする際は、 configure は使えない気がする。 CodeBlocks のQuickなんたらRefの説明では、いきなり、 make するように支持されていた。しかも、-fno なんたら dll-export みたいなオプションを付けろと指示。これは、MinGW32のバグで、 付けないと最後のldの段階でldがクラッシュする事をたまたま発見。 ところで話は変わって聞いておきたいのですが、 eclipse では wxWidget のイベントを書くようなときに ・BEGIN_EVENT_MAP に自動的に一行マクロを挿入してくれて ・*.h にもメンバ関数宣言を書いてくれて ・*.cpp にも5行くらいの関数定義本体の雛形を書いてくれ たりしますか? つまり、イベント・ハンドラを追加したとき、 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 はありません? 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 は、アプリ本体のプログラムが複雑なことをしているようなので、 もっと小さく出来る可能性があり。 その説明にac1だの何だの自分以外分からない定義を使う必要があったのだろうか 今から見るとそうかも。 a: Windows Native or MFC b: wzWidgets c: CUI g: GUI r:release, d:debug d:dynamic link, s:static link >>668 >最後の段落:多分、wxWidgets 本体を MInGW32 用のビルドする際は、 >configure は使えない気がする。 なにいってんだCodeBlocksのドキュメントにそう書いてあるだけで 基本autotoolsで作られたソースはconfigureでビルドできるぞ 実際自分はWindows上のmingw32/64、LinuxのクロスビルドからのMinGWでconfigure使ってる なぜMakefileでやれという指示なのかというと、そのほうが簡潔で保守しやすいからだ あとGNU MakeじゃないMakeでもビルドできるようにしたいとかいう微妙なこだわりが有る場合も有る >>669 エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける ソースのひな形自動生成機能は知らんなあ >>670 MinGWビルドでバイナリをストリップしたやつとか比較しないのか >>674 Stripに詳しくないので、言っている意味が分からない。 Stripって Release 用に Build した Binary に対して行っても サイズダウンできたりするの? >>674 Stripに詳しくないので、言っている意味が分からない。 Stripって Release 用に Build した Binary に対して行っても サイズダウンできたりするの? 日本語インライン入力の対応ってまだなの? というか予定自体なくて諦めた方がいい? wxWidgets使ってるEditraってエディタにそろそろ移行できるかなと 思って試してみたら、未だにインライン入力できない >>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 が正常に起動することを確認済み。 >>673 >エディタの補助機能を使うべきだ、Emacsなら矩形範囲選択で一気に書ける 詳しく: スタンド・アローン・コンプレックスと化した馬鹿には無理さんオッスオッス >>679 cua-modeでググって http://qiita.com/yyamamot/items/7efcbfdcccdb5fa45ebe 例えばイベントテーブルとかはこれでザクッと一気に書ける もちろん個々のwxWindowIDとメソッド定義は書かなくてはいけないが クラス名とマクロ定義は同じ文字列の繰り返しなのでだいぶ楽になる >>681 あー、そういう風に沢山のイベントを一気に書きたいんじゃなくて、 開発段階で徐々にイベントを追加して行く際に、 1. *.h のクラス内にメンバ関数宣言 2. *.cpp に EVENT MAP 3. *.cpp に メンバ関数定義の本体 の三箇所にコードを書くのが面倒ということなんだわ。 wxFormBuilderでしかGUIとイベントを設計できない俺には何言ってるのかさっぱりわからんぜよ…… wxAUI のデモ・アプリ wxauitest.exe のサイズは、1,417,216 bytes。 スタンドアロンのアプリで、環境変数からパスを完全に消去しても起動 できた。つまり、ライブラリはDLLを使わずに静的リンクされている。 wxAUIはFloating & Dockingのできる強力なGUI。 >>678 に示した keyboard.exe はキーボードから押されたキーの値を 表示するだけで、上記アプリよりずっとシンプルなのにも関わらず、 1,887,758 bytes と 470,542 bytes も大きい。 理由は不明。 そんなことしなくても DLLの依存関係調べるツールあるのに ちなみにwxWidgetsで作った一番小さいexe探したら65kbのがあった Windows実行形式であっても、コンパイラが、MinGW32 と VC++ でサイズに 大幅な違いが出てくるのかな? >>685 実行ファイルの関数テーブルに何が入っているか nm で確認したら少しはわかるかもね >>688 大幅とは行かないかもしれないがVC++はWindowsのみをターゲットにしているから 基本的にコンパイル後のバイナリサイズは MinGW > VC++ だよね 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 は付けてある。 ちなみに、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 だけで済む。 誤:[Search Directories] の Compiler, Linker, Compiler 正:[Search Directories] の Compiler, Linker, Resource Compiler 誤:Win32のimport libraryは、ライブラリを動的リンクする場合はライブ ラリのDLLが行っているの 正:wxWidgets ライブラリをアプリに動的リンクする場合は wxWidgets ライブラリの DLL 部分が Win32 の import library の リンクを行っているの サイズはどうでもよくないか。exeを使う側としては速度では? あとコア、主要のライブラリのビルドから、ダイナミックリンクを徹底してOSに丸投げしたら小さくなるだろ。 完全テンプレートライブラリにしたら軽くなるんだろうか >>694 でも wxWidgets がやっていることの割にはリンクされるバイト数が多すぎる 感じがする。 基本、Win32をラッピングしているだけなのだから、2MBも必要ない。 ラッピングしてるだけじゃなくマルチプラットフォームのために徹底した抽象化をしてるんでしょ とソースも読まず推測 read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる