5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:2008/06/28(土) 21:49:20
クロスプラットフォーム GUI ライブラリの wxWidgets (旧 wxWindows)についてのスレ。

本家
 http://www.wxwidgets.org/
wxWindows日本語プロジェクト
 http://wxwindowsjp.sourceforge.jp/
Let's wxWidgets
http://dot-gray.s33.xrea.com/
wxWindowsで始めるC++ GUIプログラミング
http://www.h3.dion.ne.jp/~k5_n/wxwin/
wxWidgets でクロスプラットフォーム GUIアプリを作ろう
http://0xcc.net/pub/uu-2004-08/


2 :デフォルトの名無しさん:2008/06/28(土) 21:51:28
wxWidgets 2.8.8 is out !!!
http://wxwidgets.info/node/49


3 :デフォルトの名無しさん:2008/06/28(土) 23:44:21
退かぬ!! 媚びぬ 省みぬ!!

4 :デフォルトの名無しさん:2008/06/28(土) 23:46:50
>3
省みるからバグフィクスが出るんじゃまいか
とマジレスしてみる
そして>1乙

5 :デフォルトの名無しさん:2008/06/29(日) 09:11:25
昔、ソース覗いたけど、今ってどうなってんだ

6 :デフォルトの名無しさん:2008/06/29(日) 15:45:28
今でも、ソース覗いたよ

7 :デフォルトの名無しさん:2008/06/29(日) 19:48:18
wxMSW2.8.7 のwxTE_RICH を指定したwxTextCtrlのインターフェースで、
縦スクロールバーが出るぐらい文字を入力して、適当な位置にキャレットを動かしてEnterを押すと、改行される毎にキャレットがある行がインターフェースの先頭に行ってしまうというバグがあったんだけど、2.8.8でも直ってない・・・ですね。。
wxRichTextCtrlもなんか変なままだし・・泣

8 :デフォルトの名無しさん:2008/06/30(月) 10:54:27
どんどんでかくなってくよぅ
もっと小さくして下さい

9 :デフォルトの名無しさん:2008/06/30(月) 11:33:17
>>7

>>改行される毎にキャレットがある行がインターフェースの先頭に行ってしまうというバグ
sample の wxMSW widget を実行してみたけど、現象がよくわかりません。
普通に動いている気がするのですが…

10 :デフォルトの名無しさん:2008/06/30(月) 23:31:47
>2.8.8でも直ってない
報告した?

11 :7:2008/07/01(火) 22:07:46
>>9
>>10
すいません自分の勘違いかも??
もうちょっと調べてみます。。

12 :デフォルトの名無しさん:2008/07/02(水) 00:37:56
最近になって本格的にWxWidget触り始めたんだけど
サイザーって理解するのに時間かかるな。特にStaticBoxSizer
addで追加するオブジェクトを間違えると、即座にレイアウトが崩れて……

13 :デフォルトの名無しさん:2008/07/07(月) 11:06:47
>>12
wxGlade あたりでレイアウトしてみて
確認してコーディングしてみるのも
いいかもしれませんよ。

14 :7:2008/07/07(月) 12:40:49
>>7
なんか、EVT_TEXTイベントのタイミングでwxTextCtrl::SetDefaultStyle()を使うとキャレットの位置がおかしくなる、ということのようです。

また、別件になるのですが、EVT_TEXTのタイミングで入力されたマルチバイト文字列をwxTextCtrl::SetStyle()を使ってスタイル変更しようとすると、なぜかfalseが返ってきてしまうのです・・。(ASCII文字なら成功する)
仕方がないので、テキストコントロールの中の文字列が変更される時のイベントで、EVT_TEXTよりあとに発生するイベントのタイミングでSetStyle()を使いたいのですが・・EVT_TEXTより後に発生するイベントって何かあるでしょうか??探しても見つかりませんでした。

Timer使うとまた色々不都合があるんですよね・・

15 :7:2008/07/07(月) 12:47:02
>>キャレットの位置がおかしくなる、ということのようです。
おかしくなることがある、ですね。縦スクロールバーが出ている時に改行すると自分のところではおかしくなりました。
Windows XPです。


16 :デフォルトの名無しさん:2008/07/07(月) 15:31:56
バグレポート

17 :7:2008/07/07(月) 18:33:04
英語自信ないっす。。

18 :デフォルトの名無しさん:2008/07/07(月) 21:56:39
>>14
使っているライブラリオプションは UNICODE でしょうか?


19 :7:2008/07/08(火) 00:24:01
>>18
そうです!


20 :18:2008/07/08(火) 13:23:29
>>19
調べてみるけど、ちと時間くださいな。
あと、そういう時は再現できる簡単なソースを書いておくと
調べる人が多いかもしれません。

21 :18:2008/07/09(水) 15:51:13
>>19
調べてみました。
結論から言いますと Windows の問題で wxWidgets 側でなんとかできる
問題ではないですね。(同じようなコードを MFC で書いてもエラーになる)
Microsoft あたりに文句を言えば、いつかは直るかもしれません?

22 :7:2008/07/09(水) 23:24:43
>>20 >>21
(多分前スレからお世話になりまくっていると思うのですが・・)本当に何度もご親切にありがとうございます。
もしかしてwxWidgetsの開発に関わっている方だったり・・?違うか。

Windows自体の問題とのことなのですが、すいません、>>14 では質問していることが2つあったのですが、どちらがWindows自体の問題だったのでしょうか?


23 :7:2008/07/09(水) 23:45:39
あとすいません、また追加で質問で恐縮なのですが・・IMEの変換状態が変化したときにricheditが送出するEN_IMECHANGEというイベントマスクをwxWidgets側で捕まえたいのですが、
Win32APIが送るイベントマスクをwxWidgets側で拾いたい時はどうすればよいのでしょうか??
IMEの変換状態が変化した時のイベントのようなものは既存のwxWidgetsにはなさそうなので、自分で書き足さなければいけないと思うのですが・・。


24 :18:2008/07/10(木) 10:49:04
>>22
残念ながら違います。
こういったライブラリで遊ぶのが好きなだけです:-)

で、>>14 の質問の
>また、別件になるのですが、EVT_TEXTのタイミングで入力された
>マルチバイト文字列をwxTextCtrl::SetStyle()を使ってスタイル変更
>しようとすると、なぜかfalseが返ってきてしまうのです
この件は Windows の仕様のようです。(MFC でも同じことが起きます)

EVT_TEXT(Windows の EN_CHANGE)で、SetStyle(MFC の
CRichEditCtrl::SetSelectionCharFormat 等)でも同じエラーになります。

ですので、現状では Windows の仕様なのでいかんともしがたいかと。

EVT_TEXT(EN_CHANGE)の後に飛んでくるメッセージは特にないようです。

25 :18:2008/07/10(木) 11:53:44
>>23
独自のメッセージを持ってくる方法があった気がしたけど
きれいさっぱり忘れましたorz
一番手っ取り早い方法は wxTextCtrl::MSWCommand の
継承メンバを作っちゃう方法かな?

26 :デフォルトの名無しさん:2008/07/10(木) 12:18:56
ていうか 7 さんはそこまで Windows べったりのことをするのなら wxWidgets である必要がない気が...

27 :デフォルトの名無しさん:2008/07/11(金) 01:45:57
>>24 >>25
毎回ありがとうございます。
http://docs.wxwidgets.org/stable/wx_eventhandlingoverview.html#customevents
この辺りよんでるんですが・・なかなか書いてあることが理解できません。難しいですね・・

>>26
最近ようやくそう思い始めました汗 しかし、一回手を出してしまった以上他のに乗り換えるのはいやだなと・・

また不具合の話になるんですが、どうも wxTextCtrl::SetStyle() とか GetStyle() を使うと、該当箇所の文字列が一瞬青く反転してしまうようです・・(一瞬選択状態になっている?)
これもけっこう痛いです・・

28 :デフォルトの名無しさん:2008/07/11(金) 07:16:25
>>27
>しかし、一回手を出してしまった以上他のに乗り換えるのはいやだなと・・
世の中見切りの付け所ですよ。

29 :デフォルトの名無しさん:2008/07/11(金) 08:56:57
今の時代の見切りは、Winモンリー開発を見切るんであって、
クロスのWxWidgetsに手を出すのは正しい。
他に乗り換える場合でもクロスGUI。

30 :18:2008/07/11(金) 10:53:29
>>27
何か理由(納期とか…)が無い限り、楽しみながらやるのがいいかと。

>どうも wxTextCtrl::SetStyle() とか GetStyle() を使うと、
>該当箇所の文字列が一瞬青く反転してしまうようです・・
>(一瞬選択状態になっている?)

wxTextCtrl::SetStyle() 内部では、
1 指定範囲を選択
2 EM_SETCHARFORMAT を SCF_SELECTION で SendMessage
3 指定範囲を戻す
という動作をしているからです。
EM_HIDESELECTION を SendMessage してやればいいだけなので
がんばって本家にレポートしてみるとか。

31 :18:2008/07/11(金) 10:59:25
>>27
順番が逆になってしまった。

>http://docs.wxwidgets.org/stable/wx_eventhandlingoverview.html#customevents
>この辺りよんでるんですが・・なかなか書いてあることが理解できません。難しいですね・・

wxEvent 関連を使った方法は私もよくわかりません:-p
そっちではなくて、wxTextCtrl を継承したクラスを作って、MSWCommand を
継承しちゃえばいいかな?ってことです。
class myTextCtrl : public wxTextCtrl
{
public:
virtual bool MSWCommand(WXUINT param, WXWORD id) {
 if ( !wxTextCtrl::MSWCommand( param, id ) ) {
  switch (param) {
  case EN_IMECHANGE:
   〜
   break;
  default:
   return false;
  }
 }
 return true;
}
こんな感じ?
やってみたことないからあっているかどうかの自信はないけど。

32 :デフォルトの名無しさん:2008/07/11(金) 20:02:36
wxMSW以外でもコンパイル通るのかそれ?

33 :デフォルトの名無しさん:2008/07/11(金) 23:12:43
>>32
そりゃ当然 #ifdef とかで囲むんだろう

34 :18:2008/07/12(土) 18:50:28
>>32
EN_IMECHANGE をキャッチしたいとのことだったので
Windows 専用で大丈夫かと思いました。
X や MacOS だと IME 系の処理ってどうやるんでしょうね。

35 :27:2008/07/14(月) 02:20:06
毎度ありがとうございます。。。

>>何か理由(納期とか…)が無い限り、楽しみながらやるのがいいかと
特に納期などはないんですが、なんとしても作りたいものがあってやってるんですがはかどらなくて悶絶してます泣

IMEに入力された文字列のフォントを毎回設定するために渋々win32apiをいじっているのですが、ウィンドウのハンドルを取得するFindWindowW()関数でウィンドウのハンドルがうまく取得できたなくてはまっています。。
(このハンドルがないとIMEにアクセスできないようなのです。)
FindWindowW()の第一引数に該当ウィンドウを生成する時に使っているクラスを指定しなければいけないみたいなんですが、
wxTextCtrlとかではだめで、もっと深い階層にあるwin32apiウィンドウ生成クラス?を指定しなければいけないみたいなんですが、それが何なのか分からなくて止まってます。。

>> 2 EM_SETCHARFORMAT を SCF_SELECTION で SendMessage
>> がんばって本家にレポートしてみるとか。
これはライブラリがそういう仕様になっているということなんですよね。
これを直すのもまた大変そうですし、直してもちゃんと本家でパッチあててもらって公開してもらわないと使えないんですよね。。

なんかもう作りたいプログラムの完成が果てしなく遠いような気がしてきました。
そもそも楽するためにwxWidgetsっていうフレームワークを使っているのにいつのまにかwin32apiをいじる羽目になっているし・・
なんのためにラッパーを使っているのか分からなくなってきました。

悲鳴に近い書き込みすいません。
Visual C++ に呼ばれている気がします。。。

36 :デフォルトの名無しさん:2008/07/14(月) 07:45:51
> なんのためにラッパーを使っているのか分からなくなってきました。

そりゃ根本的に使うものが間違ってるからだろ。
WindowsべったりでWindowsでできることは全部できなきゃダメとか思いながら使
うもんじゃねーよ。

37 :デフォルトの名無しさん:2008/07/14(月) 08:37:19
こういうクロスプラットホームので日本語入力周りが細かく操作出来ると思うのが甘いんじゃないかと思います ... 開発者の大多数が英語環境なわけでね。

とにかくあなたのやりたい用途には日本語周りのサポートの厚いフレームワークをつかわないとだめそう。べつに急に Win 32 API までおりる必要はないわけで。

Windows なら .Net とかつかったほうがいいんじゃない?
Delphi とかも昔はよかったのかも。

38 :デフォルトの名無しさん:2008/07/14(月) 10:26:13
Lazarusもなんか微妙なんだよねぇ。
BorlandがKylixを見捨ててなければ、クロスプラットフォームアプリの
大本命になれたかもしれないのに。

39 :デフォルトの名無しさん:2008/07/14(月) 10:37:25
>Windows なら .Net

そ・れ・は・ない

40 :18:2008/07/14(月) 10:56:40
>>35
wxWidgets の話題から外れるので、軽くだけ。
何をやりたいかよくわからなくて想像だけど、
そういうことをやりたいときは WM_IME_COMPOSITION をとらえて
ImmGetContext から HIMC を取得し、Imm* 系の API を使うんじゃ
ないかな?
wxTextCtrl のようなコントロールを駆使してやるのは難しいと思いますよ。

41 :デフォルトの名無しさん:2008/07/14(月) 12:18:53
>>39
37 ですが、見当外れだったらすいません、日曜 Cocoa 屋さんなもので ...

42 :35:2008/07/14(月) 13:16:44
レスありがとうございます。

>wxWidgets の話題から外れるので、軽くだけ。
すいません、そうですよね。。ありがとうございます。
>wxTextCtrl のようなコントロールを駆使してやるのは難しいと思いますよ。
やはり・・

>> Windows なら .Net
> そ・れ・は・ない
いまさらVisual C++ とかはあんま賢くない選択肢なんでしょうか。

> こういうクロスプラットホームので日本語入力周りが細かく操作出来ると思うのが甘いんじゃないかと思います ... 開発者の大多数が英語環境なわけでね。
それに気づくのが遅すぎました泣
QTなんかはどうなんですかね・・日本での実績もあるのでwxWidgetsよりはマルチバイト文字周りも大丈夫そうですが。


結局開発環境で何を採用すればいいのかという導入部での問題にまたぶつかってしまいました。
最初は、これからはマルチプラットフォーム対応じゃないとと思ってwxWidgetsを選んでみたんですが、結局まだほとんどの日本人はWindowsを使っているわけで、まだしばらくはWindowsをほとんどの人が使っていくんじゃないかとも最近思うので、
素直にVisual C++ から入ればよかったのかなとか思い始めてるんですが・・

こういう話題NGだったらスルーしてくださひ。

43 :デフォルトの名無しさん:2008/07/14(月) 13:19:24
>素直にVisual C++ から入ればよかったのかなとか思い始めてるんですが・・

Windowsソフトを作るにしてもVC++はやめといた方が良い。
M$社内でも使われなかった該吉設計MFCを使うか、
ドトネトとC++を混ぜるというそれだけでウンザリ、
といった環境しかない。

44 :デフォルトの名無しさん:2008/07/14(月) 13:55:31
>>42
>最初は、これからはマルチプラットフォーム対応じゃないとと思ってwxWidgetsを選んでみたんですが、結局まだほとんどの日本人はWindowsを使っているわけで、まだしばらくはWindowsをほとんどの人が使っていくんじゃないかとも最近思うので、

会社の仕事でソフトを書いてるなら他の人が何を使ってるかは重要だけど、
自分ひとりで使うなら何で組んだって勝手だよね。
wxWidgets がすきならそれをつかえばいいし、プラットフォームべったりでも好きなフレームワークがあればそれを使えばいいんだと思うけども、
どうも 35 さんは日本語入力周りをいじりたいというクロスプラットホームには不向きな題材をやりたいようだから...
やっぱやりたいことに即した言語/フレームワークを使うべきだとおもいます。

でもVisual C++ はよくないと思います。C++/CLI は変態で面白い言語だとは思うけど。

45 :デフォルトの名無しさん:2008/07/14(月) 14:07:06
>思ってwxWidgetsを選んでみたんですが

この苦難を乗り越えてこそ、
アプリとかのすぐれたデザインパターンを発見できるだろうし、
ソフトウェア資産になると思うんだが。

それが”WxWidgetsを組み込んだ場合の優良なデザインパターン”となるか、
”質問者の作成するはソフトウェアの要素からWxWidgetsが外される”ことと落ち着くか、
それは自分で決めることだけど。前者も無理じゃないと思うぞ。

46 :35:2008/07/14(月) 14:24:32
どもです。
Visual C++ 人気ないですね。。MFCとか.NETが人気ないってことなんでしょうか。
ATL/WTL ってのがVisual C++ で使えるみたいなんですがこれはけっこう評価が良いような??

あとはVisual C# とかですかね。。

>>45
まだ自分はデザインパターンとか見つけられるレベルではない気がします。。


47 :デフォルトの名無しさん:2008/07/14(月) 14:35:41
別にVC++で問題ないよ。SDKでガシガシ書け。
どうせどんなGUIライブラリ使っても、細かいところはAPI直に触らなきゃならないんだから。

48 :デフォルトの名無しさん:2008/07/14(月) 14:49:18
VC++/SDKなら問題無いかも。
それならその中にWxWidgets使っても無問題。
MFCはやめとけ。
1回生成されたダイアログを使ったソースを見てみれば、
”これ何語?”って感じであきらめることになるだろう。

ドトネトもやめとけ。作るものに限界があるし、そうだと、作っててつまんない。

49 :デフォルトの名無しさん:2008/07/14(月) 15:04:36
>まだ自分はデザインパターンとか見つけられるレベルではない

どっちにせよ、アプリの構造はつねに意識してないとね。
どういう構造が良いのかわかってないと、プログラム修正して良くなったのか悪くなったのかわからんだろ。

50 :デフォルトの名無しさん:2008/07/15(火) 02:39:38
自分か身内だけで使うようなちょっとしたものだと、
C#に.NET3.0↑で書くのが楽すぎる
Windows専用になっちゃうんだけどさ

ってスレ違いだな

51 :デフォルトの名無しさん:2008/07/15(火) 04:26:43
>>46,35
以前に少し使った程度だけど、WTLは結構いい感じだったよ。あとwindowsで
コード組むなら、やっぱりVC++がいいと思う。単純にwindowsとの相性がいいのと
windowsで実行する場合、実行速度が速い。(独特な部分もあるので、注意が必要だけど)
将来移植するかもしれないけど、当分windowsメインなら自分でラッパークラスを作って
移植の時楽になるようにしておくのがいいんじゃないかな。

MFCはやっつけで作るには楽だけど、腰を据えて作る場合はなんか
いらいらすることが多くて、自分はあんまり使いやすく感じなかった。
構造覚えるのも労力かかるし、わざわざ使うことないんじゃないかな。

C#(というか.NET)は、細かいところにこだわりを持つ性分なら薦めない。
使いやすいけど、細かいことにこだわると、結局API叩くことになるから。
あとやっぱり、もっさりした感じになりやすいね。

ついでに書くと、Qtはフリー版で作ったものは、ライセンスがGPLになるのと
バージョンがあがった時に互換性がなくなった、変なプリプロセッサを通して
コンパイルするなどが嫌で、使うのやめたことがある。作り易そうではあるんだけどね。

52 :デフォルトの名無しさん:2008/07/15(火) 08:05:00
>>51
で、wxWidgetsはどうなんだ?

53 :デフォルトの名無しさん:2008/07/15(火) 20:30:58
そういえば、ここはwxのスレだった。
wxは以前に調べた限り、C++でクロスプラットフォームの開発をする場合は
一番妥当なライブラリだと思うよ。
日本語の入力が使えて、継続的に開発されていて、GUIの見た目がOSと
同じようになる。ある程度の実績があり、ライセンス的にもあまり
縛りが強くないってなると、wxしかなかった。
IME周りや日本語フォントなど細かいことをやるには問題があるかもしれないけど。

自分はクロス開発する必要があるものはwxを使って、api叩く必要がある場合は
ラッパークラスを作るようにしている。
あと日本語周りを細かく操作したいなら、どうせAPIを使うことになるから、
それが楽になるライブラリを探すよりは、そのあたりのAPIの使い方を
調べたほうが近道だし、応用が利くと思うよ。

54 :デフォルトの名無しさん:2008/07/19(土) 05:41:43
そうだね

55 :デフォルトの名無しさん:2008/07/19(土) 21:07:43
ところで、暇つぶしに、wx使ってどこまでできるの挑戦で、こんなのつくってみたんだ。

http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/ugmail/Doutor/src/?sortdir=down



56 :デフォルトの名無しさん:2008/07/20(日) 04:59:33
http://ugmail.sourceforge.jp/

57 :デフォルトの名無しさん:2008/07/25(金) 16:02:55
ほしゅ

58 :35:2008/08/01(金) 15:58:28
ご無沙汰です。挫折してしばらく何もしていなかったのですがまた最近やり始めています・・。
結局VC++はIDEの使い方を覚えるのが面倒で、またwxWidgetsに戻ってきてしまいました。

>どうも wxTextCtrl::SetStyle() とか GetStyle() を使うと、
>該当箇所の文字列が一瞬青く反転してしまうようです・・

この問題は、
(void) ::SendMessage(GetHwnd(), EM_HIDESELECTION, 1, 0) ;
wxTextCtrl::GetStyle(position, style);
(void) ::SendMessage(GetHwnd(), EM_HIDESELECTION, 0, 0) ;
こんな感じでGetStyle()をオーバーライドしたら解決しました。win32APIを直書きすればこれぐらいの問題ならば解決できたようです。

今まだ悩んでいるのがEN_IMECHANGEやWM_IME_COMPOSITION を捕捉するところです。
>>31さんに提示して頂いたように
class myTextCtrl : public wxTextCtrl
{
public:
virtual bool MSWCommand(WXUINT param, WXWORD id) {
 if ( !wxTextCtrl::MSWCommand( param, id ) ) {
  switch (param) {
  case EN_IMECHANGE:
   〜
   break;
  default:
   return false;
  }
 }
 return true;
}

みたいな感じで色々試してみているのですが、このやり方だとどうもうまく捕捉できません。 これらのイベントの捕捉のしかたが分かるかたいらっしゃいましたらご教授頂けると幸いです・・m(_ _)m


59 :35:2008/08/01(金) 16:00:52
>>47 >>48 >> 49 >> 50 >> 51
ありがとうございますm(_ _)m お礼がめちゃくちゃ遅くなってすいません。
結局VC++とかWTLじゃなくてwxWidgetsをまだ使ってます。。

60 :18:2008/08/02(土) 16:36:53
>>58
あれ?駄目なのかな。
ちとしばらく忙しくなるので、気長に待ってみて…

61 :デフォルトの名無しさん:2008/08/02(土) 21:37:47
>>58
MSWCommand の先頭で、処理してもだめなのか?

wxStyledTextCtrlの場合でやったときは、

WXLRESULT wxStyledTextCtrl::MSWWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam)
{
  WXLRESULT ret;

  switch(nMsg)
  {
    case WM_IME_・・・・
     //じぶんでつくった処理
     break;
    default:
      ret = wxControl::MSWWindowProc(nMsg,wParam,lParam);
      break;
  }

  return(ret);
}

なかんじでできたよ





62 :35:2008/08/04(月) 13:01:51
レスありがとうございます。

MSWWindowProc()の方を試してみたら、VM_IME_COMPOSITIONを捕捉することが出来ました!ありがとうございましたm(_ _)m
EN_IMECHANGE、VM_IME_CHAR、VM_CHAR はなぜか捕捉出来ず。

いまやりたいことが、「VM_IME_COMPOSITIONのタイミングで、IMEで編集中の文字列のフォントを変更する」ということなのですが、
VM_IME_COMPOSITIONを捕捉できてなんとかなったと思ったのですが、VM_IME_COMPOSITIONのタイミングでwin32APIの ImmSetCompositionFont(hIMC, lf) を使っても、フォントが変更されませんでした・・。
1が返ってきているので関数自体は成功していると思うのですが・・。

例えば、テキストインターフェース上で、太文字で強調表示させた文字列の直後にキャレットを置き、そこでIMEをONにし、キーストロークによって文字を打ち込むと、
直前の強調表示された文字列のフォント(太文字)がIMEのフォントにも継承されてしまうようで、
それをどうにかしたくてVM_IME_COMPOSITIONのタイミングでIMEの編集中の文字列のフォントを強制的にデフォルトのものに変えてしまおうという考えだったのですが・・

アドバイス頂けると幸いです。

63 :35:2008/08/04(月) 13:56:38
> wxStyledTextCtrlの場合でやったときは、
wxStyledTextCtrlって、IMEをONにしたときの入力が正常に動かなくなかったですか?

自分の環境では変換待ちの文字列が常に一番上の行に出てしまって、それが嫌でwxStyledTextCtrlを使うのはやめたという経緯がありました。

64 :デフォルトの名無しさん:2008/08/04(月) 20:01:03
「自分の環境」とは?

65 :デフォルトの名無しさん:2008/08/05(火) 00:14:39
>>63
ああ、IMEの処理は実装されていないから、そうなる。

そもそも、IME関係はOS依存?FEP依存?のようで、wxWidgets に対応するものはない。

Scintilla の場合は、Plat??.cpp でマルチプラットフォームを実現してるのだが、
(wxStyledTextCtrlでは、PlatWX.cpp がそれに該当する)
マルチプラットフォーム化する必要のために、IMEの処理を移植できなかったのかと思う。



66 :65:2008/08/05(火) 00:19:11
あと、EN_IMECHANGE、VM_IME_CHAR、VM_CHAR の処理はwxWidgets のソースを見たほうがはやいな。
wxWidgets のソースは簡単だから、そっちをあたることをお勧めする。



67 :デフォルトの名無しさん:2008/08/12(火) 13:24:03
wxJoystickを使うと、レジストリのHKLM\SYSTEM\.. というのを読みに行って失敗する・・・。
HKLM\ってうちのマシンには見当たらない。またwxJoystickEventがEVT_JOYSTICK_EVENTSで拾えない。
GetNumberJoysticksはなんか値が返ってきているから何かしらJoystickは見えているはずなんだけど。
コンパネのゲームコントローラはちゃんと認識しているのでHWの故障でもない。
さぁどうしよう。
飛ばしてwxMediaで遊ぶか。



68 :デフォルトの名無しさん:2008/08/12(火) 20:12:17
HKLMってHKEY_LOCAL_MACHINEのことだけど

69 :デフォルトの名無しさん:2008/08/20(水) 19:47:49
何でだろう、EVT_PAINTを登録するとCPUがブン回る・・・
samplesのプログラムはそうならないけど、何が違うのか分からない。
頭悪いな俺。

70 :デフォルトの名無しさん:2008/08/21(木) 06:59:56
wxPaintDC使ってないだろ

71 :69:2008/08/21(木) 10:01:31
wxPaintDC dc( this );
とするべきなところを
wxPaintDC dc;
と書いていました・・・。
直したら、ちゃんと動きました。
スレ汚ししてすみませんでした。


72 :デフォルトの名無しさん:2008/08/23(土) 16:37:06
質問です
wxGridはデフォだとマルチセレクト且つダブクリで編集モードになりますが、
シングルセレクトにしてワンクリで編集モードに移行するようにできますか?

IDEとかRADのプロパティ表示みたいなことをやりたいんです。
DialogBlocksが多分wxWidgetsで組まれてると思うのであれがそのまま使えればいいんですけど
そのまんまのクラスって無いですよね?

73 :72:2008/08/25(月) 22:14:35
探してみたらwxPropertyGridっていうまんまのコンポーネントが見つかりました。
wxCodeに載ってなくても探せば使えるコンポーネントって結構ありますね

74 :デフォルトの名無しさん:2008/08/28(木) 17:27:01
で、クロス開発する場合、IDEはどれが一番良いの?

wxDev-C++を使ってるけどバージョンうpされないorz

75 :デフォルトの名無しさん:2008/08/28(木) 17:36:46
とりあえず、wx-Dev C++ と Code::Blocks は、どちらが良い?

76 :デフォルトの名無しさん:2008/08/28(木) 18:46:17
GUI作成できるのは、
・wx-Dev C++
・Code::Blocks
・wxGlade
だけでつか?

77 :デフォルトの名無しさん:2008/08/28(木) 22:40:12
>>74
wxDev-C++はHPで近いうちに更新するっていってたよ
>>76
そんなあなたに、このページを送ろう
ttp://wiki.codeblocks.org/index.php?title=Comparison_of_wxSmith_features

78 :74:2008/08/29(金) 10:07:05
>>77
え”、更新ですか!wx-Devは大好きなので嬉しい。

そのページ凄すぎ。
結構1年近くググルでwx系を検索してたんですが3つ4つしか把握できなかったのに、
そのページで全部そろうじゃん。

こんなにいっぱいあるとは。。。

商用のは一旦除いて(商用でもC++ Builder並に良いものなら買うけど、決定打が無さそうなふいんき)、
使ってないやつで良いのがあるかもしれないのでまた調査。

79 :61:2008/08/29(金) 21:03:27
>>76
私的には
Visualwx
ttp://visualwx.altervista.org/indexit.php

あとは、wxStudioとか
http://wxstudio.sourceforge.net/




80 :デフォルトの名無しさん:2008/08/30(土) 13:22:02
dialogblocksが挙がってないのは有料だから?

81 :デフォルトの名無しさん:2008/08/30(土) 13:25:58
すでに72で挙がってるからですな・・・スマソ。

82 :76:2008/09/01(月) 09:19:29
>>79
VisualWxってえらい変わりましたね。
以前はコンパイラ起動できなかったような。

83 :デフォルトの名無しさん:2008/09/01(月) 13:19:08
どれが良いか投票とか、
使える・使えないレビュー、
きぼんにゅ。

84 :デフォルトの名無しさん:2008/09/02(火) 17:15:22
どのIDEが好き?

85 :デフォルトの名無しさん:2008/09/03(水) 00:19:27
まだ、これってIDEやRADがないんだよねー。残念ながら。

俺は今、MinGWのCodeBlocksを入れようと思ってんだけど、
wxmsw28??_core.lib(libwxmsw28??_core.a)や、
wxbase28??.lib(libwxbase28??.a)がないって怒られる
んだけど、下のサイトのようにwxWidgetsをビルドしても
ライブラリが生成されないんだけど。なんで?

http://python.matrix.jp/apps/code_blocks.html

もっと簡単なクロスなIDEはないもんかね?

86 :デフォルトの名無しさん:2008/09/03(水) 01:18:15
趣味プログラミングでしかないけれど、wxFormBuilder 3はフォームデザインのみとはいえ使い勝手いいよ。
自分で書くコードと、wxFormBuilderが生成するコードが、完全に分離されるところが好き。
Makefileは手書き、ソースコードエディタはVim。開発は主にLeopardで行い、一回のmakeでWin/Mac用バイナリを生成……という感じ。
IDEって、突然バージョンアップが止まったり、なんだか変なものを導入したのか
不安定&低速になったりとあんまり信用できない感じ。なんていうか、Delphiで懲りた。

87 :デフォルトの名無しさん:2008/09/07(日) 00:17:44
>>85
そでだけだとよくわからんけど、
debugのバイナリ作ってないのに
デバッグビルドしようとして同じようなことになったことはあるな

Code::Blocksよりdialogblocksのほうが使い易いと思う
タダ版だとカスタムクラスが1つしか登録できないとか
RADツールで使えないクラスがあったりするけど
その辺は勉強もかねてエディタで乗り越えようとすれば問題なし

88 :デフォルトの名無しさん:2008/09/11(木) 18:17:31
wxWidgetsで非矩形ウィンドウや半透明ウィンドウは扱えるのでしょうか。
また扱える場合は関連するメソッドを教えていただけると有り難いです。


89 :デフォルトの名無しさん:2008/09/11(木) 22:13:46
>>88
リージョンは使えるよ。
半透明ウィンドウは、以前そんな話があったみたいだけど、
Windows以外のプラットフォームで出来ないのもあるみたい
なので、実装されなかったみたい。

90 :88:2008/09/11(木) 22:38:14
>>89
なるほど。どうもありがとうございます。
対応プラットフォームが多いと実装もやっぱり大変なのでしょうねぇ。

91 :デフォルトの名無しさん:2008/09/12(金) 11:35:27
IDEランキング調査スタート!

92 :デフォルトの名無しさん:2008/09/12(金) 12:45:41
                    ,. -‐ ' ´  ̄ `` ' ‐- 、
         ,. -─ ‐- 、   /             ``' 、
        ∠-‐' "´  ̄ ` `'‐- 、               `'‐、
      /´             ヽ、               `'‐ 、__
    , ‐'       (⌒'‐- 、         \
 -='´        ='イ   ヽ.       ヽ
 /      ヽ、=_,‐''´   、_,ノ           ヽ
. i  、  ヽ、_, /,. _-,=‐、ゝ'            ',
.{  ゞ_=、<.  ヽ-' ,、r‐;、彡‐==/ニ.ヽ   }-‐- 、            /
 \ ', 、y=;'、    ´ゞ=''_,.´ /  F、ヽ ',  ./    \          /
   \ヽ`ゞッ /       ̄  {   |´ノ / ∠      \          ,/
    `}  ̄〈,. -‐、        !  ヽ/ / `、      `'‐-、ニ、_,./
      !   `         '、  ヽ. /    `'‐- ..,,j-‐'"´
     ヽ.   ' ´ ̄`       ヽ  ∨
.      \   '"     ,.  }  ∧
        ヽ. ____, ,-‐'"  / ,./ ‐ヘ
           )_,,.ハ <_,. -'    \___,,,.. ..,,
           ´    ト、 |       |  /´    ``ヽ.
          _,. -‐'´j ヽ!      ィ /´          ト、
        /´|     i.  ヽ!    ///   _,,,.. ....., 、   |i
       |   |    |\ __  ./ / {,. -‐´ __   `  !.}
     ,-ソ   !    !  /  Y´  /くン-─/´ _,,.. -    / |
 ,. へ'´ 、    リ   ! />-<ヽ. ∠ノ   ̄``'´       / i
‐ 、_ 、_  ヾ   ノ   !' ´     `/                /   !

93 :デフォルトの名無しさん:2008/09/12(金) 15:26:54
                _
         _, - ' ´ ̄ ̄   ̄ ヽー -、_
        /                `ー 、_
      /                _   `ヽ
     /                /´  `ヽ,  `i
    /                 l      i   ヽ
   i                  ヽ、  (_).ノ    ヽ
   | l l    |  /l /l | ハ   /l    ̄       ヽ
    ', l ヽ. ハ  |ヽ| ヽ 、 l ヽ、 l ヽ           ',
    ヽヽ、 _-ヽヽヽヽ、 >_ニ==`ー-、j           i
     冫、 _v ーテ、    - 'テtァ-  ',               |
    /   ヽ .,ヽ゚ノ    ヽヽ=゚'´  ヽ           !
    i      !  /        / ̄           i
    /     ',  ー       /             l
    !     ヽ  ー - -    !             /
    \     \      _ ヽ           _ /
     `ー --'-'- `ー -‐ i ´   `ー'- -'-'-'-'‐'´
                  |      |
                  |      ヽ、
         _____ノ        `ー - -、_
        ヘ                _, - '  `ー、
       /  \          , - ‐ ' ´ /  ̄ ̄  ヽ
       l     ヽ 、 _ , - ‐ ' ´    /         i
        y              /          |
        /                /            l
     /             /       /    /
      (        ` y ´ /       /     /

94 :デフォルトの名無しさん:2008/09/12(金) 16:09:32
Libファイルを作成後に
sampleをコンパイルしてみようと思ったんですが
未解決の外部シンボル
だらけになってしまいます。
どうもまったくlibファイルを認識していないのか何なのか。

sampleはそのままの状態でコンパイルしてはいけないんでしょうか?

95 :デフォルトの名無しさん:2008/09/13(土) 08:52:45
あのさ、こっちだってエスパーじゃないんだから、
自分がどういう環境で何をやってるか相手に判ってもらおうっていう気はないわけ?

96 :デフォルトの名無しさん:2008/09/13(土) 09:46:27
原因を追求する気があるならあんな書き込みはしないだろ。

97 :デフォルトの名無しさん:2008/09/13(土) 23:03:26
wxwidgetsのストリング関係のクラスは
日本語使える(漢字)?

98 :デフォルトの名無しさん:2008/09/14(日) 00:07:06
>>97
使える。Unicode モードと、環境依存エンコーディング決めうちモード(なぜかANSIモードとよばれる)があるよ。

99 :デフォルトの名無しさん:2008/09/14(日) 05:53:11
後者は基本的にユニバイト環境しか考えていない。
たとえばファイルのパス操作など、セパレータが \ かつ文字コードがCP932な
変態環境では問題が生じうる。

100 :デフォルトの名無しさん:2008/09/14(日) 12:21:10
94です
すいません。8時間ぶっ通しで1つの進展も無く悩みすぎて色々おかしくなってました。
2日寝てようやく冷静になりました。

wxMSWのセットアップを使用して、WindowsXpにxwWidgetsをインストール後
VisualC++2005Expressに、\build\msw\ws.dswを読み込ませ各種libファイルをビルドしました。
この時点でエラーはありません。

その後、サンプルをビルドしてみようと
\samplesフォルダにある、samples.dswを読みこんでそのままビルドしてみましたが、
すべてのlib内の関数が「未解決の外部シンボル」と出て認識してもらえませんでした。

試しに、他の\samplesフォルダ内の
各サンプルの.dspファイルを直にVC++2005Expressに読み込んで、同じ様にビルドしてみましたが
すべて同じ症状でした。

生成したlibファイルの存在する\lib\vc_libにはリンク設定はしてるようですし、
インクルードディレクトリの設定にも問題があるようには思えませんでした。

sample内の.dspファイルはそのままの状態でコンパイルしてはいけないんでしょうか?

101 :デフォルトの名無しさん:2008/09/15(月) 23:45:58
Libのモード(リリースビルド、デバッグビルドとか)が、
sample のがあってます?

それと、wxwidgetsのversionは、2.8.8だよね?
とりあえず、VC2003とVC2008の場合は、動作しますよ


102 :デフォルトの名無しさん:2008/09/16(火) 22:11:41
94です。
助けありがとうございます。

wxwidgetsのversionは、2.8.8です。
Libのモード(リリースビルド、デバッグビルドとか)
のパスや名称は合っているようです。

http://forums.codeblocks.org/index.php?action=printpage;topic=7140.0
にあった事例のようです。
I now compiled wxwidgets with VS2005 and
I am now able to build the samples,
but with new projects I still have problems.
It seems that the wizard does something wrong
- the linker wants to have wxmsw28d.lib
but I cannot find it on my system.
I have a lot of wxmsw28d_xxxxx libs...
という話しで
解決方法は
wxmsw28d.lib is for Monolithic debug builds;
you seem to have a Multilib build.
MultiLib is the opposite of Monolithic.
In the wizard un-check Monolithic or you need to build wxWidgets
as a Monolithic build.
とのことです。
つまり、wxmsw28d.libが生成されなければならないのに、
複数に分かれたwxmsw28d_xxx.libが生成されてしまうという問題です。
1つのwxmsw28d.libにまとめられれば、この問題は解決しますが
話が理解できません。
チェックを外すべきMonolithicとは何なのでしょうか?
どうすれば1つにまとまるんでしょうか?

103 :デフォルトの名無しさん:2008/09/16(火) 23:22:59
94 氏とは別件だけど、2.8.8をMinGWでコンパイルで、ライブラリ(〜.a)を
作成したまでは良いんだけど、リンクエラーが出ます。

ヘッダが無いとかが、原因ですかね?

〜\wxWidgets\lib\libwxmsw28d_core.a(corelib_imagjpeg.o):..\src\common\imagjpeg.cpp|238|undefined reference to `jpeg_std_error'

104 :デフォルトの名無しさん:2008/09/17(水) 00:36:56
>>102
ビルドが出来るってことは、WindowsSDKは大丈夫なんだね。
スタートメニューから、Visual Studio Tools でコマンドプロンプトを開ける?
開いたら、cd wxWidgetsのディレクトリ\build\msw して、
nmake /E MONOLITHIC=1 makefile.vc
してみて。

105 :デフォルトの名無しさん:2008/09/17(水) 00:39:20
>>103
undefined referenceが出る場合は、そのシンボルの実態が無いって事だから、とりあえずリンクするライブラリ不足を疑うと良いよ。
jpeg_std_errorでググると、libjpegの中の関数だってわかるから、g++のコンパイルオプション(というかリンクオプション)に -ljpeg を
付けて再チャレンジして見て。

106 :デフォルトの名無しさん:2008/09/17(水) 09:11:10
>>103があと数回は同じ質問を繰り返す様が見て取れるようだ。

107 :デフォルトの名無しさん:2008/09/17(水) 23:25:19
>>104
94です。
たびたび助かります。

104を試したところ
しばらくコンパイルが通った後、
..\..\src\msw\utils.cpp(173) : error C2143: 構文エラー : ')' が '__stdcall' の前
にありません。
..\..\src\msw\utils.cpp(173) : error C2059: 構文エラー : ')'
..\..\src\msw\utils.cpp(175) : error C2143: 構文エラー : ';' が '*' の前にありま
せん。
以下エラー略〜〜な状況です。

この173行目は
typedef int (PASCAL *WSAStartup_t)(WORD, WSADATA *);
こんな内容です。PASCALかWORDかWSADATAのどれかが、定義されていないと思われるんですが、
VCのオプションでも、SDkへのパスは設定してありますし、
Microsoft Platform SDK\SetEnv.Cmdは実行済みなので(試しに直前にもやってみたけど結果は同じ)、
SDKのパスが通っていないとは思えないです。

おそらく、これが最後の関門だと思います。
どうかもう一度よろしくお願いします。

108 :デフォルトの名無しさん:2008/09/18(木) 00:09:03
>>107
__stdcallは、PASCALというマクロが展開された結果。
その前に ')' が必要といわれてるんだから、問題になってるのはそこより手前
本当にそのコンパイルエラーの手前にWarningかエラーない?

109 :デフォルトの名無しさん:2008/09/18(木) 00:33:20
>>107
というか、MONOLITHIC=0がデフォルトなんだから、MONOLITHICじゃないライブラリ使えば良いじゃない。
1. wx_dll.dswを開いて、構成をDLL Unicode Releaseを選択してソリューションをビルド
2. samples.dswを開いて、構成をDLL Unicode Releaseにしてソリューションビルド
で、普通にいけるぞ?

110 :デフォルトの名無しさん:2008/09/18(木) 01:05:55
94です。
>>108
warning C4068: 不明なプラグマがありました。
というwarningが大量にありました。
>>109
>1. wx_dll.dswを開いて、構成をDLL Unicode Releaseを選択してソリューションをビルド
この時点で未解決の外部シンボルの嵐で全然ダメです。
wx_dllは他の構成でも全然ダメでした。

もしかして、何かおかしなことが起こってますか…??

111 :デフォルトの名無しさん:2008/09/18(木) 01:21:30
>>110
とりあえず、WindowsSDKとVC++2005消して、新しい環境を構築しなおせ。
VC++2008Express SP1
Windows SDK for Windows Server 2008 and .NET Framework 3.5

112 :デフォルトの名無しさん:2008/09/19(金) 00:14:55
そうします。
やっぱり何か異常な状態なんですね。

113 :デフォルトの名無しさん:2008/09/21(日) 00:19:51
すいません。Code::Blocks+MinGW+WxWidgets2.8.8の環境構築について
解説しているサイトはないですか?ググったのですが見つからなくて
困ってます。

114 :デフォルトの名無しさん:2008/09/22(月) 17:26:08
wxPythonでのトラブルですがwxWidgets絡みなので
ここで質問させてください。
wxWidgetsのDLLをUPX圧縮した状態でwxを使うツールを
2重起動するとOS毎固まる症状が出ています。
調べた限りではwxのどのDLL,pydを圧縮しても
同じ症状が出るようです。

OS Win98
WxWidgets 2.8(wxPython2.8.7.1 本家のWin版)
UPX 2.0.3

AVSP(1.3.6 python2.4 wx2.6)ではUPX圧縮してあっても
多重起動できているのでバージョンの問題かも
しれませんが、ツールを一纏めにして配布する
予定なので出来るだけ圧縮して使用したいのです。
御教示お願いします。


115 :デフォルトの名無しさん:2008/09/23(火) 08:32:34
ツールを一纏めにして最後にZIP圧縮して配布すればよい。UPX圧縮したのを一纏めにするのとほぼ同等の効果がある。
というより何形式であれ圧縮されたファイルはそれ以上ほとんど圧縮されない。何故なら圧縮されているからだ。

116 :デフォルトの名無しさん:2008/09/23(火) 09:18:59
wxWidgets 2.8.9 リリースされたみたい。

117 :デフォルトの名無しさん:2008/09/23(火) 10:15:22
コンパイルするのまんどくさいんで
誰かランタイムとヘッダだけまとめて配布してくれ

118 :デフォルトの名無しさん:2008/09/23(火) 10:19:43
>>115
圧縮されてるから圧縮されないんじゃないよ
均一にどの視点から見ても完全にランダムなデータになってるから圧縮出来ないんだよ
同じデータでも圧縮する前に可逆な方法でランダムに入れ替えたデータでやるとまったく圧縮出来ないよ
圧縮率の上下はいかにランダム性を生ませないような構造にデータを持っていくかが味噌なんだ
最近の圧縮アルゴリズムなんてとっくの昔にエントロピーなんて越えてるし

119 :114:2008/09/23(火) 17:35:09
>>115
pythonの場合はスクリプトなので起動時のロード時間が
非常にかかります。wxWidgetsのライブラリは
テキストが多く含まれているので圧縮すると半分くらいの
大きさになりロード時間がかなり削減できます。
今回は圧縮率よりもロード時間を気にしています。

念のために。UPX圧縮による実行時のメモリ浪費は
気にしなくて結構です。


120 :デフォルトの名無しさん:2008/09/23(火) 17:53:39
スレ違いで申し訳ないのですが、widestudioを使ったことがある方っていますか?
IDEも付いている至れり付くせりな感じなのでいいんではないかと思うのですが、あまり稼動実績が見当たらないのですよね。
wxWidgetsと比べてどんな感じかとか、使ったことある方いらっしゃったら教えて頂けると嬉しいです。

121 :120:2008/09/23(火) 18:02:58
すいませんwidestudioのスレあったのでそっちいきます。。
と言ってもここでも色々意見頂けるとありがたいのですが。

122 :デフォルトの名無しさん:2008/09/24(水) 03:36:42
widestudioはwx以上に使われてない感があるな〜
見た目がOS標準じゃないのがちょっと・・・
OS標準よりもかっこよければ、非ネイティブでも許せるんだけども


123 :デフォルトの名無しさん:2008/09/25(木) 13:45:50
>>116
おっ、まじですか
そろそろ汎用的なXMLPerserキターかな?一寸見てこよ。

つか、>>91-93が完全に空気になっているのに吹いた。

124 :デフォルトの名無しさん:2008/09/25(木) 20:11:40
>>122
ありがとうございます。
うーん、やはりそんな感じなんですね・・

125 :デフォルトの名無しさん:2008/09/28(日) 13:43:04
WxWidgetsについて質問させてください。

Windows上で、WxRubyを使ってアプリケーションを作っているのですが
そのアプリケーションの中で、時間のかかる作業(多くのファイルのコピー)を始めると
作業中にウインドウが固まってしまいます。
(ウインドウ上のボタンが押せない&他のウインドウをアクティブにすると、元のウインドウを表示できなくなる)

定期的にupdateメソッドを実行してみたりもしたのですが
表示が更新されるだけで、固まる問題は解決しませんでした。

WxWidgetsにおいて、時間のかかる作業をやりたいときの
定石のようなものはないでしょうか?

126 :デフォルトの名無しさん:2008/09/28(日) 14:04:17
処理を分割してタイマーか何かで少しずつ進めるか、処理を別スレッドにする。
wxWidgetsに限らず大抵のウィンドウシステムではこうなるわな。

127 :125:2008/10/01(水) 15:40:25
ありがとうございました!
Rubyスレッドの中で処理を実行して、WxTimerで10msおきにスレッドに処理を回すことで
余裕を持って動くようになりました

128 :デフォルトの名無しさん:2008/10/01(水) 20:22:11
MinGWでwxwidgetsをコンパイルして使えるところまで来たと喜んでいたんですが、
簡単なサンプルで
C:/wxWidgets-2.8.9/include/wx/chkconf.h:103:9: #error "wxUSE_DYNLIB_CLASS must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:111:9: #error "wxUSE_EXCEPTIONS must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:119:9: #error "wxUSE_FILESYSTEM must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:127:9: #error "wxUSE_FS_ARCHIVE must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:140:9: #error "wxUSE_DYNAMIC_LOADER must be defined."
C:/wxWidgets-2.8.9/include/wx/chkconf.h:148:9: #error "wxUSE_LOG must be defined."
・・・
というようなエラーが出てします。原因は何が考えられますか?

ちなみに付属のサンプルはmakeコマンドでビルド出来ました。コンパイル時の
オプションの問題なのでしょうか?

129 :デフォルトの名無しさん:2008/10/02(木) 11:12:59
>>128
MinGW 使ったことないから外しているかもだけど
setup.h は include している?

130 :デフォルトの名無しさん:2008/10/02(木) 11:25:01
`wx-config --cxxflags --libs`とか?

131 :デフォルトの名無しさん:2008/10/02(木) 11:45:58
>>128
samplesフォルダのminimalはコンパイルできる?

132 :デフォルトの名無しさん:2008/10/02(木) 11:47:49
ああ、makeで出来たって書いてあった、すまん。
コンパイル時に打ったコマンドをさらした方がよいと思われ。

133 :128:2008/10/02(木) 14:05:05
レスありがとうございます。
windows上でプログラム作るときは、やはりVC++使ったほうがいいのかなと思って
開発環境を変えようかなと思っています。
>>129
setup.hはインクルードしてませんでした。たぶんコレが原因…
>>132
make時は、
ttp://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.8.6_to_develop_Code::Blocks_(MSW)
を参考に、mingw32-make -f makefile.gcc MONOLITHIC=1 SHARED=1 UNICODE=1 BUILD=release
を使ってました。コンパイル時にはNetBeansを使っていたのですが、もうアンインストールしちゃったので分かりません。
NetBeans、もっさりしすぎです・・・

134 :128:2008/10/02(木) 14:15:34
連投すみません。setup.hが原因の場合、includeパスにwx.hがおいてあるフォルダを
設定していたら、そこにsetup.hを放り込んでおけば良かったのでしょうか?

サンプルのminimalをmakeは出来たのに、自分でコンパイル出来なかったということは、
インクルードパスの設定が不十分でsetup.hが見つからなかったことですよね。たぶん

135 :デフォルトの名無しさん:2008/10/02(木) 17:56:59
>>134
wxは複数のバージョンや条件(Unicodeだとかデバッグだとか)でビルドしたライブラリ
を置いといて、wx-configにオプションを与えることで設定通りの条件のsetup.h
だとかライブラリだとかが使われるコンパイラ引数を出してくれるようになってる。
なのでsetup.hを手前で適当に放り込むなんてのはしない方がよい。
ファイルがどこにあるか調べ上げて自分でパスを列挙するなんてのとは違う。

136 :134:2008/10/02(木) 19:11:22
>>135
wx-configはちょっとしたプログラムを作るためのもので、まともなプログラムを
作る場合はmakefileにインクルードパスなどを細かく書くものだと思っていました。

`wx-config`はcygwin,linuxあたりでは使えると思うのですが、windowsの
開発環境(VC++,eclipse,netbeans等)で、コンパイルオプションに指定して
動くものなのですか?

137 :デフォルトの名無しさん:2008/10/02(木) 19:21:13
もともとMinGWって言ってるじゃねーか。
なんでVCが出て来るんだよ。

138 :デフォルトの名無しさん:2008/10/02(木) 19:39:53
> まともなプログラムを作る場合は

もっとマシな人間をアサインする

139 :デフォルトの名無しさん:2008/10/02(木) 19:47:32
>>137
確かに、それは私が悪いんですが、wxwidgets自体がクロスプラットフォームな
ライブラリじゃないですか。そうすると、VCで使う人もいるだろうし、
VCの場合はどうするのか気になったんです。

結局、'wx-config'はcygwin上からでしか使えないのですか?


140 :132:2008/10/02(木) 19:51:52
wx-configは、makefileに細かく設定するのがめんどくさいから使うもの。

wx-configはWindowsのコマンドラインからは使えないので、使えるようにするためのツールがMSYS。

MSYSからwx-configを使ってコンパイルしてみなされ。

ちなみにwx-configをくくってるのは半角のバッククォートだよ?Shift+@で。コマンド置換とかで調べてみ。
gccのオプションとかについても調べましょう。

141 :デフォルトの名無しさん:2008/10/02(木) 20:06:45
>>140
回答ありがとうございます。
バッククォート間違ってたorz

どうもいくつか腑に落ちないことがあって、ヘッダファイル除いてみたり
してたんですが、根本的に間違えてるかもしれないです。足掻いてみます。
お騒がせしました。


142 :デフォルトの名無しさん:2008/10/03(金) 11:02:20
>>139
VisualStudio の場合、基本的には.dspなんかを使うんだけど
それが build/msw フォルダに入っている。
で、その中で include パスの設定なんかが入っているので
そのままコピーするなり好きなように設定すればOK


143 :デフォルトの名無しさん:2008/10/04(土) 23:14:11
WxWidgetsってIDEで使うの難しいよ。
私のスキルがないのもあるけど、今までEclipse+CDTやCode::Blocksと
環境づくりができなかったよ。もっと簡単にできないと普及しないんじゃ
ない?wxDevC++は簡単だったんだけど、デバッグに難ありじゃ使えない…。

144 :デフォルトの名無しさん:2008/10/04(土) 23:27:38
今、wxDev-C++のサイト見てきたけど、Web Update したら Ver7相当になるのかな?
そろそろ、バージョンアップの日は近い??

145 :デフォルトの名無しさん:2008/10/06(月) 22:31:49
いや、普及しないのはきっとバイナリが馬鹿でかくなるせいだ。
ちょっとしたアプリでも2M以上になるんじゃ恥ずかしくて公開できない。

146 :デフォルトの名無しさん:2008/10/06(月) 23:04:03
今時実行ファイルがでかいぐらいで恥ずかしがることもあるまい
.NET Frameworkが必要と言った瞬間に文句を付けてくるような奴がいる世の中だ
別途インストールが必要ないのは利点だぜ

147 :デフォルトの名無しさん:2008/10/06(月) 23:33:03
.NETの必要な400KBのプログラムよりは
単体で動く4MBのプログラムの方が良い

148 :デフォルトの名無しさん:2008/10/07(火) 06:34:26
.NET嫌いのエンドユーザーって、実際的なことではなく、
「こう言っとけば"わかってる奴"みたいに響くらしいぞ、うひひ」
的な動機で文句言うからなぁ。
毎度文句を言うくらいならランタイムをインストールしたほうが早いのに、
意地でもそれをせずに「.NET対応だと困る自分」を死守してるだろ、彼らw

149 :デフォルトの名無しさん:2008/10/07(火) 08:28:52
>>148
そのインストールが面倒だから文句言ってるんだよ、分かれよそのくらい
インストールだけで時間かかるし
バージョンアップが必要になることも多いし
別PCで動かそうとしたときに面倒だし

150 :デフォルトの名無しさん:2008/10/07(火) 09:06:41
>>149
インストールより「.NET対応だと困る状態」を維持して
毎度毎度困り続けるほうが面倒だろって言ってるんだよ、分かれよそれくらい。

151 :デフォルトの名無しさん:2008/10/07(火) 09:10:22
初回起動が遅いのが.NETの最大の難点だと認識している
二番が移植性、インストールの問題は三番目

152 :デフォルトの名無しさん:2008/10/07(火) 09:10:57
.NETの要る要らないでソフトの作者を叩いたり
ネットで喧嘩したりする時間とやる気はたっぷりありますが、
インストールする時間とやる気はまったくありません、それくらい分かってください。

とか言われても、「分かりません」としか言い様がないんだよね。

153 :デフォルトの名無しさん:2008/10/07(火) 09:13:23
>>151
初回起動の問題が圧倒的だよね。
そういう「実際的な問題」なら話はわかるし、俺もそれは好きじゃないから、
.NETは趣味の開発では避けてるよ。

154 :デフォルトの名無しさん:2008/10/07(火) 09:23:03
>>150
仮にWindowsユーザー全員がインストールしたところで、.NETの方がバージョン上がるから同じ事だ

155 :デフォルトの名無しさん:2008/10/07(火) 09:38:57
それが同じじゃないことに気付かないのは>>148の内容の人ですね、キミは

156 :デフォルトの名無しさん:2008/10/07(火) 10:14:45
もう既に、この会話のほうが、インストール作業より時間的にも長く
キーボードを叩く量=人間側の労働コストも多くなってるからね。

これは自発的にやれるけど、インストールはやれません、は通用しないよ。

157 :デフォルトの名無しさん:2008/10/07(火) 10:15:14
>>152
何でマイクロソフトは Windows Update で強制的に .Net をインストールさせないんだろう?そしたらこういう文句もでなくなるはずだよね。

158 :デフォルトの名無しさん:2008/10/07(火) 10:27:25
ヒント:M$は製品にドトネトを使わない、MFCを使わない、VBを使わない

159 :デフォルトの名無しさん:2008/10/07(火) 10:28:50
>>157
Vistaでプリインストールされているので自然に普及するという計算だった
しかしそのVistaがあんまり・・・

160 :デフォルトの名無しさん:2008/10/07(火) 10:46:09
ヲイヲィ、変な門すすめんじゃねーよw

ヂャヴァ以下じゃねーか(怒

>ttp://pc11.2ch.net/test/read.cgi/prog/1143203111/863
>VB.netがしょぼすぎるんでC#.netを始めた。
>Javaと同じ割りに選択肢が乏しくてメリットがないように感じる。
>俺、間違ってるかな?

161 :デフォルトの名無しさん:2008/10/07(火) 11:01:39
先ずはM$に製品にドトネトを使うように説得してみてはどうだろうか?
話はそれからだ。

162 :デフォルトの名無しさん:2008/10/07(火) 12:33:54
誰も勧めちゃいないと思うんだが

163 :デフォルトの名無しさん:2008/10/07(火) 13:01:55
たしかにドトネトを勧めるなんてテラ悲惨すぐる。
そんな痛い香具師いねーかw

164 :デフォルトの名無しさん:2008/10/07(火) 19:48:04
なんか本題からずれてきてるぞ
問題はWxWidget使った実行ファイルのサイズだろ

165 :デフォルトの名無しさん:2008/10/07(火) 20:33:30
wxTNGがリリースされれば、ファイルサイズはWTLなみに小さくなるはず。
ttp://wiki.wxwidgets.org/Development:_wxTNG


166 :デフォルトの名無しさん:2008/10/08(水) 22:46:13
なんでこんなに盛り上がってるんだw

167 :デフォルトの名無しさん:2008/10/09(木) 19:02:42
>>143
NetBeansで出来た。他のIDEでもいけると思う。コンパイラとリンカのオプションに
wx-config --cflags と wx-config --libs で出力される文字列コピーしてウマー
NetBeansの場合、Runで実行するときにはLD_LIBRARY_PATHに共用ライブラリしていしないといかんけど


168 :デフォルトの名無しさん:2008/10/10(金) 03:02:54
>>165
wxTNGの完成予定時期ってどっかに書いてる?

169 :165:2008/10/10(金) 07:52:16
>>168
本来はwxWidgets3.0で対応する予定が、3.0では却下されたみたい。
ttp://garrys-brain.blogspot.com/2007/11/wxwidgets-30-in-new-year.html

次々メジャーバージョンの4.0では対応してくれると信じたいけど…。
あと、ちゃんと読んでないけど、wx-discussでの関連すると思しき記述。
ttp://lists.wxwidgets.org/pipermail/wx-discuss/2007-October/thread.html

170 :デフォルトの名無しさん:2008/10/11(土) 01:38:46
>>169
しばらくは現状の仕様のままということですか。
3年後くらいには出てるかもしれないね。
まあ、今のままでも若干MFC臭がするくらいで、そう不便でもないとも思うが。

171 :デフォルトの名無しさん:2008/10/11(土) 12:56:58
>>167
すいません。wxのコンパイルから、NetBeansの環境設定まで
初心者に分かり易く書いてもらえないでしょうか。

実行ファイルのサイズが大きくなるのは全然平気。使う側も意識しないだろうし。

172 :167:2008/10/11(土) 17:41:22
>>171
どこら辺が分からない?
全部書いてもいいけど、長文になるだろうから質問に答えていく感じの方が



173 :171:2008/10/13(月) 01:11:57
NetBeans wxwidgets でぐぐったら良い記事見つけたので
良いや。それ見て、eclipse+CDT+MinGW+msys+WxWidgetsで
環境できたし。

174 :デフォルトの名無しさん:2008/10/13(月) 08:34:47
NetBeansじゃねぇw NetBeansはMakefile書かなくていいから楽だけどなぁ

175 :デフォルトの名無しさん:2008/10/14(火) 09:14:31
>>173
結局、お前には
「ググレカス」
って返事しとけば良かったってことだな

176 :デフォルトの名無しさん:2008/10/19(日) 14:13:35
wxglade使って、骨組みだけパパッと作りたいんですけど、
ボタンなどの部品をフレーム一杯に配置するにはどうすれば
いいですか?サイズに-1,-1を設定するとOS毎のデフォルトサイズが
適用されるみたいですけど、パネル・フレーム一杯に配置する
特定のパラメータってないんでしょうか?

177 :デフォルトの名無しさん:2008/10/19(日) 15:23:26
>>176
サイザー内の部品について
proportionを1以上にすると、サイザーの方向に伸びる
(サイザー内に複数の部品があれば、proportionの値が大きいほど幅を取る)
Alignment - wxEXPANDをオンにすると、サイザーの方向と垂直に伸びる

178 :デフォルトの名無しさん:2008/10/19(日) 16:03:11
>>177
出来ました。ありがとうございます。
wxGladeって書いてましたが、よく見たらwxFormBuilderでしたw。
ubuntuで適当に入れたから、wxgladeと思い込んでたけど、
今はwxFormBuilderの方がメジャーなんかなぁ

179 :デフォルトの名無しさん:2008/10/19(日) 17:15:05
自分はDialogBlocksが一番好き

180 :デフォルトの名無しさん:2008/10/22(水) 12:55:03
wxWidgetsアプリのファイルサイズはまあ許容できるけど、
minimalサンプル実行時のメモリ使用量が40MB近くってどういうことだ?

$ wx-config --list
Default config is gtk2-unicode-debug-2.8

だけど、debugビルドだから?

181 :デフォルトの名無しさん:2008/10/22(水) 22:43:01
DialogBlocksいいよな
軽いしコメント消せば余計な補完しないし
最初はテキストエディタで直接弄った箇所を
消されたりしてその良さがわからんかったけどな

182 :デフォルトの名無しさん:2008/10/23(木) 00:16:17
DialogBlocksの宣伝するのなら、環境構築のやり方教えてちょ。

183 :デフォルトの名無しさん:2008/10/23(木) 10:12:52
>>182
今、試してみた。
環境がwindows+visual C++なら、dialogblocksインスコすれば
勝手にコンパイラとかの検知はしてくれるみたい。あと手動で、
Settings->Path->WXWINに、公式サイトから落としてきたwxMSWを
解凍したフォルダを設定すればいけたよ。ただ、ビルドオプションが
ReleaseとDebugしかないってのは…。Unicodeを設定する方法とかあったら
補足よろしく



184 :デフォルトの名無しさん:2008/10/23(木) 14:15:51
>>182
おう、興味をもってくれる人が出てくるのを待ってたぜ
ttp://www.anthemion.co.uk/dialogblocks/download.htm
で、
DialogBlocks 4.27 Developer Bundle for Windows NT/W2K/XP/Vista (Unicode).
を落としてインストールだ。
DialogBlocks、wxWidgets、MinGWがいっぺんにインストールできる

wxwidgetsとMinGWは共にデフォルトのパスにインストールを推奨
MinGWはG++とMinGW-Makeを選択すること。
Webインストールで、たまにファイルが落ちてこないことがあるが
何度かリトライすればインストールできるのでキャンセルはしないこと。
DialogBlocksからwxWidgetsをコンパイルできるのでMSYSはいらない。

すでにwxWidgetsとMinGWをインストールしている場合は
DialogBlocks初回起動時にウィザードがでてくるのでそれに従って
それらのパスを指定するだけ
Bundleをインストールした場合は自動的にパスが検知されてる

細かい選択肢がインストールの間にいくつか出てくるのでダレないこと。
知ってるかもしれないがwxWidgetsのコンパイルもえらい時間がかかるので
やっぱりダレない事。
あとDialogBlocksは言語が選べるけど英語かドイツ語しかない
だけど基本的なことは他のIDE(Visual Stadioとか)とほぼ似通っているので
なんとなくで判るはず。

これでProjectを作れるところまでいける。正味2時間ぐらい。

>>183
View→Settings→Configration→Add でいけない?

185 :デフォルトの名無しさん:2008/10/23(木) 17:45:16
>>184
unicode設定できたサンクス。
にしても、高機能過ぎない?コンパイル出来ることにビビッたんだけどw

186 :デフォルトの名無しさん:2008/10/23(木) 19:46:17
結局簡単な設定とかだけで日本語が通るwxWidgets向けIDE/RADはないってことでFA?

187 :デフォルトの名無しさん:2008/10/23(木) 20:56:39
ないんじゃね
意味が二つ取れるけどとりあえずないんじゃね

188 :デフォルトの名無しさん:2008/10/23(木) 21:54:57
gccは--input-charsetと--exec-charsetで、
windresは--languageでASCII以外が通るってことみたいだから
あとはIDE/RADがSJIS or UNICODEで編集・出力できるか、
にかかってるんじゃないかと思ったのよ

189 :デフォルトの名無しさん:2008/10/24(金) 01:05:42
>>184
一回、インストールしてみるわ。

190 :デフォルトの名無しさん:2008/10/24(金) 09:14:50
>>184
超乙!

191 :デフォルトの名無しさん:2008/10/31(金) 23:38:41
誰か、DialogBlocksを日本語化してくれ。

192 :デフォルトの名無しさん:2008/11/01(土) 10:20:10
>>191
がんばれよ
ttp://www.poedit.net/

193 :デフォルトの名無しさん:2008/11/01(土) 10:24:44
つかさ、クレクレばっかじゃなくてもっと話題が広がる振り方ないの?
まあバリバリのwxプログラマはwxcomunityで英語で意見交換してんだろうなぁ


194 :デフォルトの名無しさん:2008/11/01(土) 16:51:08
してる人いるのかなぁ。
個人的にマルチバイト周りの強化して欲しいと思ってるが英語でメールするのが億劫でいまだしていない。

195 :デフォルトの名無しさん:2008/11/01(土) 23:27:23
>>194
「して欲しい」というのがまず間違ってるんでないの。オープンソースなのに。


196 :デフォルトの名無しさん:2008/11/02(日) 00:25:42
べつに間違ってはいないと思うけど
オープンソースだからパッチ書かずに要望出すな、ってことはないでしょ
パッチ出した方が早いってだけで

197 :194:2008/11/02(日) 01:40:50
今んとこそこまでやれるレベルのプログラマではないので^^:

198 :デフォルトの名無しさん:2008/11/02(日) 01:45:24
具体的にマルチバイトのどのあたりを強化して欲しいの? >>197
ユニコードでやっとけばとりあえず問題ないとおもうんだけど。

199 :デフォルトの名無しさん:2008/11/02(日) 02:51:18
ユニコードが使えない環境で今更作りたくないな

200 :デフォルトの名無しさん:2008/11/02(日) 03:05:30
話題が広がらないのは、もうwxWidgetsが枯れてるからじゃない?
MFCからの蓄積があるから、基本的なデザインで悩むとこなんてほとんどないし、
個々のクラスの使い方もドキュメントを見れば一発だから。
wxTNGは熱くなれそうだけど、一部でしか盛り上がってないからどうしようもない。
MFC上がりのおっさんが、クロスプラットフォームな何かを
経験を生かしてさくっと作るライブラリってことでいいじゃない。

201 :デフォルトの名無しさん:2008/11/02(日) 03:54:45
ML読んでればわかるけど、文字を表すのに1バイトで足りない文化圏の人は素直にUnicodeビルド使ってねというのがVZたちの基本的スタンスよ。

202 :デフォルトの名無しさん:2008/11/02(日) 22:51:35
VZってVadim Zeitlinのことだよね
Samplesでよく見かける
関係ないけどこの人たちが8年前に書いたソースで勉強してるんだなあと思うと
先駆者との距離の開きに焦りを覚えるよ

203 :デフォルトの名無しさん:2008/11/02(日) 23:42:27
まあUnicode使用は妥当だろうな。
ShiftJISはダメ文字問題が面倒臭すぎる。

204 :デフォルトの名無しさん:2008/11/04(火) 02:27:04
Unicode問題、よく言われてるけど、
正直、いまのままでもあまり困ってない。
(wxString て言ったって、setup0.hを変更すれば std::stringになるのだし・・・。)
具体的に、何に困ってるの?


205 :デフォルトの名無しさん:2008/11/17(月) 06:50:39
ライブラリのビルドで--disable-threadsをつけるのが常みたいですが
スレッド作らなきゃいけない場合どうしてますか?

206 :デフォルトの名無しさん:2008/11/25(火) 13:59:57
結局Mac OS X でwxする場合、どの開発環境が良いんだろうね?

207 :デフォルトの名無しさん:2008/11/26(水) 17:03:52
正直ほかの環境で wx で書いて出来たものを持ってきてからコンパイルして
微妙にいじるのが正しい気がする。
OS X 専用なら wx で書く必然性が全くない。

wxPerl と wxPython は標準の OS X にインストールされているのでそれを使うのが正解かもしれない。

208 :デフォルトの名無しさん:2008/12/07(日) 03:36:00
パソコン変えたので新しくwxWidgetsインストールしようとしたら./configureで失敗します・・。
windows xp professional
msys 1.0.10
mingw 5.1.3
wxMSW 2.8.8
で、MSYSから
./configure --disable-threads --enable-monolithic --enable-unicode
を実行すると

please set CFLAGS to contain the location of windows.h

というエラーが出て止まってしまいます。。
どなたかお助けください。。m(_ _)m

209 :208:2008/12/07(日) 03:38:10
MinGWはc:/msys/1.0/mingw にインストールしています。
CFLAGS=c:/msys/1.0/mingw/include
とかやってみてから./configure してみても変わりませんでした。

210 :デフォルトの名無しさん:2008/12/07(日) 04:28:28
w32apiは正しくインストールされてるのか
#それに CFLAGS はコンパイラオプションで直接ディレクトリを代入しても認識しないと思うがたぶん

211 :デフォルトの名無しさん:2008/12/07(日) 05:55:09
mingwを後から入れたってことだからmsysから/mingwへのパスが通ってないとか?
c:/msys/1.0/etc/fstabに
c:/msys/1.0/mingw /mingw
って入れとけば間違いないかも
mingwはインストーラーで全部チェック入ってれば問題ないと思う
あとビルドするときはビルド用のディレクトリ作って、その中から../configureした方がいいよ

212 :208:2008/12/07(日) 13:45:21
ありがとうございます。
いろいろ試してみているのでがまだ解決しません。
msysからgccとかでコンパイルはできるので、mingwのパスは大丈夫そうです。
./configure 途中の出力見てると、どうもSegmentation fault がでまくっている感じのようです。
これのせいかなと思うのですが、Segmentation fault ってのは要は他のプログラムと競合しているということなのでしょうか??
バックグラウンドで動いてるプログラムを停止したりしてみながらいろいろ試しているのですが・・

213 :208:2008/12/07(日) 14:18:59
./configureを走らせるタイミングによってエラーの結果が変わります。
一回 segment fault 吐きながらも最後まで./configure が終わったのですが、案の定make でエラー終了しました。
どうしたものか・・

214 :デフォルトの名無しさん:2008/12/07(日) 14:55:01
そのエラーメッセージを書かないことには・・・。

215 :208:2008/12/07(日) 15:31:27
エラーの内容毎回変わります・・

216 :215:2008/12/07(日) 23:47:45
エラー吐きまくりつつもなんとか簡単なプログラムはビルドできるようになりました。
ありがとうございました。
しかしMSYSがなんかおかしいのか・・

217 :デフォルトの名無しさん:2008/12/08(月) 00:06:23
>>216
それはビルドできるようになったとは言わない

218 :デフォルトの名無しさん:2008/12/08(月) 10:47:15
>>216
ハードディスクがいかれているんじゃない?
chkdsk してみた?
Segmentation fault ってのは例外が発生しているんだけど
普通は起きないようなエラーだから、ハードウェア的なトラブルなんじゃない?

219 :デフォルトの名無しさん:2008/12/08(月) 11:57:47
configureを使用しないという選択はないのか…

220 :215:2008/12/08(月) 16:40:27
ご親切にありがとうございます。

>それはビルドできるようになったとは言わない
wxWidgetsのインストール時にエラー吐きまくっているが、簡単なプロジェクトのビルドはできるようになったということです。
たぶんコンパイルできなかったスタティックリンクライブラリがかなりたくさんあるのでもちろんどうにかしなければと思ってはいるのですが・・

>>chkdsk してみた?
chdsk 知らなかったのでやってみたところ、破損ファイルを回復しています・・みたいのが一つでたのですが、
その後./configureしてみてもやはりSegmentation fault は出ました。
ハード的になんかおかしいってことなんでしょうか?

そもそもMSYSのインストール時点で
Couldn't reserve space for cygwin's heap
という変なエラーが出てるんですよね。
この症状は報告例があって、調べてなんとかMSYSは動くようになったんですが、
もしかしたらそのせいでMSYSが完全に正常には動かないような状態になっていて、それでwxWidgetsの./configureでSegmentation fault が出まくるのかなと思ってたのですが・・関係ないでしょうか?

>configureを使用しないという選択はないのか…
そんなことできるんですか??

221 :デフォルトの名無しさん:2008/12/08(月) 23:57:59
>>220
一旦、すべてアンインストールして、一からやり直したほうが早いんでないかい?

MinGW、msys、環境設定、wxWidgetsのインストール全て。

以下で親切に解説されてますよ。

ttp://labs.unoh.net/2008/09/idegui.html

222 :デフォルトの名無しさん:2008/12/09(火) 03:18:56
ドキュメントにmakefileを直接使う方法ってのが載ってるじゃん
俺はむしろMinGW環境ではこっちが標準だと思ってたんだけど

MSYSからじゃなくてコマンドプロンプトからになるけど
mingw\binに環境変数でPATH通してから
> cd c:\wx\build\msw
> mingw32-make -f makefile.gcc BUILD=release SHARED=0 MONOLITHIC=1 UNICODE=1 USE_THREADS=0
みたいにビルドできるよ

つか、install-msw.txtくらい読むものじゃないの…?

223 :デフォルトの名無しさん:2008/12/12(金) 00:42:03
結局どうなったんだ…?
つかmakefileを直接使う俺は異端なのか…?

224 :デフォルトの名無しさん:2008/12/15(月) 07:49:17
wxHtmlWindowに日本語を含むHTMLを読み込ませて、
マウスドラッグで日本語を選択するときに場所によって文字が化けるんですが、化けないようにする方法はありますか?

225 :デフォルトの名無しさん:2008/12/15(月) 08:04:50
ユニコードビルドにしたら改善しない?
それで駄目なら wx のソースをいじらないとどうしようもない気がする。
というか wx で日本語がきめ細かく動くことを期待してはいけない。

226 :デフォルトの名無しさん:2008/12/16(火) 03:15:54
DialogBlocks固有の問題だと思うんだけれども、
wxTextCtrlの初期値に"_"が含まれてると、"%"になっちゃう。
使わなければ良いだけなので回避してるんだけど、ちょびっと気持ち悪い。

227 :デフォルトの名無しさん:2008/12/25(木) 05:08:59
こんなに至れりつくせりなライブラリなのに
日本では全然盛り上がらないな。

228 :デフォルトの名無しさん:2008/12/25(木) 09:46:19
>こんなに至れりつくせりなライブラリ

どこが?

>日本では全然盛り上がらないな

海外では流行ってるのか?

229 :デフォルトの名無しさん:2008/12/25(木) 09:53:38
Ubuntu 8.10 で、 wxGTK ダイアログ中のテキストボックス上で Atok X で変換すると、
確定するときに Enter キーを押すと OK ボタンが押されてしまう。

GTKアプリではこんなことが起こらないから、 wxGTK の input method あたりが
何かおかしいんだろうけど、何が悪いのかさっぱり判らない。

230 :デフォルトの名無しさん:2008/12/25(木) 14:28:58
>>228
C++
オープン
クロプラ
日本語可
GUIウィジェット網羅
非GUI系ラッパも豊富
豊富なドキュメント
RADの充実
スタティックリンク可
多ビルド

これだけのものは他にないな。

>海外では流行ってるのか?

はい。

231 :デフォルトの名無しさん:2008/12/25(木) 23:04:51
>これだけのものは他にないな。
Qt ...

232 :デフォルトの名無しさん:2008/12/25(木) 23:13:21
流行らないのは、「クロスプラットフォームなGUIアプリ」のニーズが
少ないから

ポータブリティがタダで(犠牲なしに)手に入るのならいいが、残念ながら
そうではないしな

233 :デフォルトの名無しさん:2008/12/26(金) 00:34:10
宣伝してないのと日本語資料が無きに等しいからだろう

234 :デフォルトの名無しさん:2008/12/26(金) 08:55:58
>>231
やっぱ、Qtってメチャクチャ良いの?

クロスプラットフォームの開発にwxDev-C++でやってるんだけど、
C++ Builderには遠く及ばない感じがして。。。

235 :デフォルトの名無しさん:2008/12/26(金) 14:03:04
230に
ライセンスがうざくない
OSネイティブのTKで動く

も入れるとQtは却下だな。

236 :デフォルトの名無しさん:2008/12/26(金) 14:41:05
>>235
Mac OS X 上では ネイティブ度?は Qt のほうがマシだベ。
まあ誰も wxMac をつかってなさそうでメンテされてないからだろうけど。

237 :デフォルトの名無しさん:2008/12/26(金) 19:47:15
VCL
○C++(少しDel臭いがMFCよりはマシ)
×オープンソース
×クロスプラットフォーム
◎GUIウィジェット
◎非GUIラッパ
○ドキュメント
◎RAD
○スタティックリンク可

MFC
○C++(かなりインチキ臭いマクロとか多いが)
×オープンソース
×クロスプラットフォーム
×GUIウィジェット
○非GUIラッパ
○ドキュメント
×RAD
○スタティックリンク可

WTL
◎C++
◎オープンソース
×クロスプラットフォーム
×GUIウィジェット
○非GUIラッパ
×ドキュメント
×RAD
○スタティックリンク可



238 :デフォルトの名無しさん:2008/12/26(金) 19:47:55
誤爆った

239 :デフォルトの名無しさん:2008/12/26(金) 21:23:30
なんでスタティックリンク可不可って問題なの?
Windows でもインストーラ書けばいいのでは?
Linux だったら .rpm とか .deb でいいし、
OS X なら .app パッケージに全部つっこめばいいよね...

240 :デフォルトの名無しさん:2008/12/27(土) 00:28:37
ある時見つけた便利そうなソフトがインストーラしかないと知ってスルーした経験ない?

241 :デフォルトの名無しさん:2008/12/27(土) 01:14:27
できないよりはできたほうがいいな。

242 :デフォルトの名無しさん:2008/12/27(土) 10:54:50
>>240
ないけど...
ていうかインストーラ無いやつは Program Files 内に入らなくて
自分でフォルダ管理しないといけないからウザイ

243 :デフォルトの名無しさん:2008/12/27(土) 15:19:17
会社とかで、さっくりと作ったアプリを
もらった時とかに、インストーラーがあると逆にうざくて
しょうがないときとかない?

何で、わざわざインストールが必要なんだ?とか

244 :デフォルトの名無しさん:2008/12/27(土) 15:57:20
そんなことより Windows Update がうざい

245 :デフォルトの名無しさん:2008/12/27(土) 16:13:48
ちょっと試してみるだけだったり、気に入らなければすぐアンインストールする
つもりのことが多いから、インストーラ無しのほうがいいな

フリーウエアでインストーラ付きだと、インストールするのをやめることもある
いやな予感がするときとか

246 :デフォルトの名無しさん:2008/12/27(土) 16:23:45
インストーラが本当に必要なレベルの大型ソフトなんて個人では作らんよ

247 :デフォルトの名無しさん:2008/12/27(土) 17:01:06
あとスタティックリンクできないと
なんのライブラリつかってるかもろばれじゃん。
有用なライブラリは同業者に教えたくないし。

248 :デフォルトの名無しさん:2008/12/27(土) 17:33:01
>>247
その発想はなかったわwww

249 :デフォルトの名無しさん:2008/12/27(土) 19:53:37
そうか、インストーラ拒否症のひとって多いんだな。
自分がそうでないからわかってなかったが、
今後はスタティックリンクするようにしよう...

250 :デフォルトの名無しさん:2008/12/27(土) 21:50:07
それにしたって、実行ファイルと同じフォルダにdll詰めてzipで配布すりゃ良いんじゃないの?わざわざスタティックリンクしなくても。

>>247
さすがにそれはねーよwどんだけ情報弱者の同業者想定してんのw
そのしょぼい独占欲で守られる利益なんて大してねーよw

251 :デフォルトの名無しさん:2008/12/27(土) 23:52:23

やたら巨大なライブラリの一部の機能しか使わない時なんかは、
サイズ的にスタティックリンクの方が効率いいかもしれん。
まあ、そんなにサイズを気にするご時世じゃないけどね



252 :デフォルトの名無しさん:2008/12/28(日) 01:48:53
スタティックリンク最大の利点は精神衛生上
ちょっと一端のプログラムを一人で作りあげた感を得られることだろう。
Windows慣れしてると、なんか変なdll置いてあるだけで
どことなく「ライブラリ頼りのトーシロ」感がかもしだされてしまう。
それよりはやっぱり実行ファイル一つ、のほうが気持ちいい。

253 :デフォルトの名無しさん:2008/12/28(日) 03:12:08
Windows自身がライブラリの塊じゃん

254 :デフォルトの名無しさん:2008/12/28(日) 04:11:19
実行ファイル一個で済む方が気分が良い

255 :デフォルトの名無しさん:2008/12/28(日) 06:44:07
動的リンクなら、ライブラリに脆弱性が見つかったときに
そのアプリがメンテされて無くても対応できる可能性が!

いや、まずないけどね

256 :デフォルトの名無しさん:2008/12/28(日) 11:10:28
>>252
ひとによって考え方が違うのは承知の上で聞くが、
全然わからん。プログラム書いた本人は
何のライブラリ使ったか覚えてるわけでしょ?
見た目だけちがうだけでなんで気持ち良かったり気持ち悪かったりするの?

257 :デフォルトの名無しさん:2008/12/28(日) 13:32:06
windowsユーザーの意見だけど……

dll使用が嫌われるのは「俺のPCのシステムに変なの仕込むな」つうことだけでしょ?
dll hellとかも嫌だし、アンインストールするときにキレイになるか判らんし。

exeと同じフォルダに仕込んどけばシステムにインストールする必要は無くなるけど、
dllのメリット無くなるしね。

258 :デフォルトの名無しさん:2008/12/28(日) 13:37:21
動的リンクで後から脆弱性が直せる可能性があるなら
同じように後から脆弱性を作り出せる可能性もあるのかな?

259 :デフォルトの名無しさん:2008/12/28(日) 14:46:08
最近はサイドバイサイドとかマニフェストとか色々めんどくさい

260 :デフォルトの名無しさん:2008/12/29(月) 22:37:21
>>250
いやあ、それが気になるのですよ。

うちの場合、
「ダイナミックでいれたランタイムを他のアプリが勝手に入れ替えた場合の保証がとれない。」
という理由で、お試しに作ったソフト・出荷ソフトの区別なく
一切ダイナミックリンク禁止になってます。

ちなみに、うちでは工場系のソフト(VC6 MFC製)を扱ってます。

工場のマシンに勝手にアプリを入れる馬鹿がいるとは思えないので、
ダイナミックだろうがスタティックだろうが、関係ないはずなのですけど・・・。

もしかして、OSのサービスパックが勝手に更新する、Cランタイム/MFCライブラリ
に対しての評価のことを気にしてるのか?


261 :デフォルトの名無しさん:2008/12/29(月) 22:54:58
全然素人なんだけど、工場って WIndows つかってるの?
でかい機械をコントロールしてるときに Windows がブルースクリーンになったら
どうするんでしょう?危険でない?

Windows ベースのタッチパネル端末で良く異常終了して
エラー画面になって止まってるのをみるんだけど...

262 :デフォルトの名無しさん:2008/12/29(月) 23:36:26
監視端末(Windows)と機械のファームは別だろう。
端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず


263 :デフォルトの名無しさん:2008/12/30(火) 00:23:35
>>261 >>262
もちろん、機械のファームはWindowsではないですが、
監視端末はWindows2000です。XpやLinuxにするだけのメリットがないので。

枯れた技術(STLですら新技術扱い)・枯れたコンパイラーしか(いまだに、VC6だぜ)使わせてくれないから、ブルースクリーンになることは、まずないよ。

>端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず

のように設計指示はしてるのだけど、実際に作ってるのがFSIの新人だから、
評価だけはしっかりやらせてる。


264 :デフォルトの名無しさん:2008/12/30(火) 00:43:11
なるほど!安心しました。まあ従業員の命がかかってるからそりゃ対処してるでしょうね。

265 :263補足:2008/12/30(火) 01:05:15
EXEが使用するDLLが、何らかの拍子で規定の場所から消えて、
同じDLL(Version違い)がWindowsディレクトリにあった場合に、
動作してしまう可能性がある。

DLLのVersionチェックとかできればいいのだけど、
Versionチェックそのものがバグってた場合や、Cランタイム/MFCランタイム
に問題が合った場合、評価したDLLのVersionと違う環境で動作してしまう。

Version差分によって修正されたDLLの場所に、
競合とかリークとか実装上のミスがたまたま引っかかって、
1%の確率で落ちたりしたら、だれが責任とるんじゃ?という問題があるのよ。
100万個作る場合、1万個の不良が出てしまう。。。

だったら、最初からスタティックにしておけば、DLLの外部要因をOSのDLLだけにしておける。
リスク軽減。その辺ってかんがえてる?



266 :デフォルトの名無しさん:2008/12/30(火) 04:29:07
ダイナミックリンカのバージョンが変われば問題も起こるからなぁ。
プロトコルが決まっていればいいんだが、
プロトコルが一定でない関数呼び出しみたいなものは出荷検査みたいなのに対応できない。

267 :デフォルトの名無しさん:2008/12/30(火) 18:15:34
>>265
まず言っとくけど、安全側に倒すってのもわかるし、DLLを強制するわけでもないぞ。

>EXEが使用するDLLが、何らかの拍子で規定の場所から消えて、
>同じDLL(Version違い)がWindowsディレクトリにあった場合に、
>動作してしまう可能性がある。
これはそういう風に依存するDLLを自動検索するよう作ってるからであって
.localファイルなりDLLを絶対パスで指定するなりすればいいんでないの?

>DLLのVersionチェックとかできればいいのだけど、
>Versionチェックそのものがバグってた場合や、Cランタイム/MFCランタイム
>に問題が合った場合、評価したDLLのVersionと違う環境で動作してしまう。
バージョンチェックがバグってたら、てそれはバージョンチェックするのはDLLホスト側なんだし
そんなバグ出るかもなんてレベルでホスト側のテスト通してるんならスタティックリンクしようがダイナミックリンクしようが
バグ埋め込みそうなものだけどなぁ。
Cランタイム/MFCランタイム側まで問題があった場合なんて言ったらそれこそスタティックリンクしようがダイナミックリンクしようがどうしようもないじゃないの。

ちなみにDllGetVersion()とかCOMとかCOM相当の自前でインターフェイスベースでコンポーネント作るとかやれば
バージョン違いでのDLLを使用することはそれなりに避けられるんじゃない?

>だったら、最初からスタティックにしておけば、DLLの外部要因をOSのDLLだけにしておける。
>リスク軽減。その辺ってかんがえてる?
その代わりテストするのは一塊の実行ファイルなりモジュールなりになるわけで、工数もテストの規模もでかくなると思われ。
全てのフローを網羅するとなったら個々のモジュール間が全て統合された場合の状態を全部網羅しなきゃならないし、
一部だけテストするとなったらなったでカバーしなきゃならない状態のテスト漏れとか起こりそうだし、
DLLでモジュールを細かく分割統治するより別側面でのリスクが増大しそうな気がする。

268 :267:2008/12/30(火) 18:17:14
今気づいたがぜんぜんwxWidgetsと関係ない話に脱線してるな。ゴメンナサイ。

269 :デフォルトの名無しさん:2008/12/31(水) 16:23:30
いや、おもしろいよ。どうせ閑古鳥スレだし。

270 :デフォルトの名無しさん:2008/12/31(水) 16:39:20
wxWidgets の場合、公式バイナリのような dll が無いので、 dll をほかの wxWidgets アプリと
共有しようとしたら違うconfigやコンパイラでビルドされた dll を使ってしまう可能性があって危険。
(C言語の場合ABIが決まってるけど、C++だとコンパイラのバージョンそろえないと怖い)
だから、wxWidgets の dll を system32 とかにぶち込む気にはなれない。

dllを共用できないのであれば、スタティックリンクにした方がいらない関数をリンクから外すとか
できるのでサイズが縮む。起動時間もダイナミックリンクがいらない分早くなるはず。

271 :デフォルトの名無しさん:2008/12/31(水) 16:54:07
>>267
単純に疑問なんだけど、リンク形態によってテスト工数が変わる理由がわからないんだが
単純に配布のファイルフォーマットの話じゃないの?
どっちにしろテストは全部しなきゃならんわけで


272 :263:2008/12/31(水) 17:17:47
>>267

たしかに、評価工数とかを考えると、フツーにモジュールを別にしますね。

>その代わりテストするのは一塊の実行ファイルなりモジュールなりになるわけで、工数もテストの規模もでかくなると思われ。
ええおかげさまで、ひどい目に遭いましたよ。帰れない日々が・・・。

COM形式なら、最悪IFクラスそのものを切り替えてしまえばいいので
それもありですね。

やっぱ、状況しだいなのかな。




273 :デフォルトの名無しさん:2008/12/31(水) 17:40:14
>>271

前に、 モジュール(DLL←→EXE)間の、
「構造体メンバのアライメント指定」が不一致が原因でメモリ壊してる
バグがあったです。と言うのは関係ないか。

どっちかというと、バイナリとしてのモジュールが違うから、
別の担当者に作業を割り当てることができるから、というのも違うな。
LIBにするのだから、IFでわけるわな。

納品される側から考えたら、DLLでもLIBでも対して違いはないですな。
作る側から考えたら、DLLの概要仕様から作らなきゃならんわけで、
めんどくさいてのはあるかも。

外注に、「DLLの要求仕様を出してないんかい」てのは、なしの方向で。


274 :デフォルトの名無しさん:2008/12/31(水) 17:48:18
DLLは基本的に「そうせざるを得ない」場合にしか使わないなぁ

275 :デフォルトの名無しさん:2008/12/31(水) 18:09:06
お前ら完全にスレ違いだが



いいぞもっとやれ

276 :デフォルトの名無しさん:2008/12/31(水) 18:40:32
そもそも、ネタがない・・・。

無理矢理作るか?
「wxwidgets乗ってたはずのC++Builder X ってどうなったんだ」とか?

これからやろうとしてるのだけど、
MFC製Dialogベースアプリを、
wxWidgetsのMDIの一画面にしてまともに動くのかとか?


277 :デフォルトの名無しさん:2008/12/31(水) 19:11:49
mfcのdllとか危険過ぎる。

278 :デフォルトの名無しさん:2008/12/31(水) 23:10:02
ちょっと気になった&連絡。

あけましておめでとうございます。

SVNのVCプロジェクトファイルなんだけど、
今までマルチバイトのはずだった(Debugと、ユニバーサルじゃない方)設定
が全部、Unicodeビルドになってる。。。

2.9に更新する場合は、wxString → char*変換周り、全部直さないとだめぽ。


279 :デフォルトの名無しさん:2009/01/01(木) 04:24:51
>>278
それ以前に、ASCIIで事足りる文化圏の人間じゃないなら、最初からUnicode使っておけよ。

280 :デフォルトの名無しさん:2009/01/01(木) 13:30:08
>>278
前スレとかにあったような気がするんだけど、wxWidgetsの3.0からUnicodeに統一されるよ。
詳細は以下のサイトとかが参考になると思う。
ttp://wxwidgets.blogspot.com/2007/11/looking-forward-to-wxwidgets-3.html

281 :デフォルトの名無しさん:2009/01/01(木) 20:38:42
wxとboostがあればもう何もいらない。
これでSOHO GUIアプリ請負で25歳月収60-70万だぜ。

282 :デフォルトの名無しさん:2009/01/02(金) 21:05:10
>>281
すごい。SOHOって仕事は自分で営業して取ってくるの?

283 :デフォルトの名無しさん:2009/01/02(金) 23:21:46
発注元の慈悲に過ぎん。あと有能な営業なら同じ仕事でも100万で取ってくる。

284 :デフォルトの名無しさん:2009/01/03(土) 01:49:01
マ板ネタになりそうだからこれで最後にするが

>>282
もちろんそうよ。ただ、特定の取引先と運良く良いコネが生まれたってのもある。
283のいうとおり、相手の良心に依存してるのはたしかだ。

まだwx自体が知られてなくて、それなりのGUIを作れるわりに
オープンでクロスプラットフォームということもあって
ある程度安心してガンガン技術習得に時間投資できるから
技術的精度が良かったり小回りが効いたりで客の評価は概ね高い。

285 :デフォルトの名無しさん:2009/01/03(土) 02:17:40
webやDB込みだよね?
スタンドアロンなアプリで60ならすごいな

286 :デフォルトの名無しさん:2009/01/03(土) 02:52:57
たしかにスキルがあって良いコネがあれば,そんぐらいもらえるかもなあ…
羨しすぎる

287 :デフォルトの名無しさん:2009/01/03(土) 09:25:49
個人は浮き沈みが激しいから最高値だけで語れないし
将来が不安すぐる

俺も学生の時に某大手商社から個人契約でやらないかって言われたけど
2年後くらいにその商社の社員の賞与が全額カットとかで
行ってたら余裕で切られてたはず

で、今はニートな訳ですが何か?

288 :282:2009/01/03(土) 14:16:16
>>287
自分も今は無職だよ。

ハローワークとかでも、ちょこちょこMFC使った案件の募集をやってる(自分は面接で落ちてしまうけど)んで、
そのままクロスプラットフォーム対応にしたwxWidgetsもそれなりに需要はあると思う。

ただ、wxWidgetsはAUIとかが今後メンテ・拡張されてくのかちょっと不安。
VS2008SP1のMFCみたいな強力なGUIとか、今後開発されるのかな?

289 :デフォルトの名無しさん:2009/01/03(土) 15:28:01
無職ならOSSで名を売る作業に戻るんだ
けど、OSSから職に繋がったのなんてほとんど聞いたことない

290 :デフォルトの名無しさん:2009/01/03(土) 16:49:55
AUIってドッキングインターフェース?
一般的なアプリでそれほど必須の機能とは思えないけど…
ドッキングできる場所が限定されれば自分で書くのもそれほど大変じゃなさそうだし
市販アプリならスキン的にやたらエキセントリックなUIにしたがるからそっちの方をなんとかしたほうが

wxWidgetsは何処ぞの組み込み系描画ライブラリ企業からバックアップ受けてるから
wxUniversalだのの、コンポーネントを自己描画する方向性ばかりが強まりそう
でもSwingでさえLook&Feelはそれほど発展しなかったのに
wxUniversalにどれほどの需要と将来性があるか個人的には非常に不明だわ

ハロワでMFC案件なんてあるんだ、行ってみようかなぁ

291 :デフォルトの名無しさん:2009/01/03(土) 18:55:11
こんなスレまでハロワとかの話題が出てきて
悲しい気分になってきた..

292 :デフォルトの名無しさん:2009/01/03(土) 21:09:04
ハロウは楽しかったなあ。俺はあんまり仮装には参加できなかったけどね。

293 :282:2009/01/03(土) 21:22:39
>>289
OSSが仕事で出来れば、それに勝る幸せはないかも。

>>290
wxMac(wxCocoa?)はMac持ってないんで良く分からないんだけど、
wxGTKではMDIがノート(タブ)形式になってしまうんで、LinuxでもMDIっぽいことを
やろうとすると何だかんだでAUI頼みになりそうな気がする。
wxUniversalは個人的には黒歴史として闇に葬り去られて欲しいんだけど、
wxPythonとかではむしろ積極的に活用されてるのかな?

>>291
ごめん、ハロワとかの暗い話題はこの辺でやめときます。

294 :デフォルトの名無しさん:2009/01/12(月) 12:28:27
290みたいな御託だけで何もしなさそうな奴が、無職なのはすごく納得する。

295 :デフォルトの名無しさん:2009/01/12(月) 15:59:53
wxBlogの方で以下の記事を見かけたんだけど、
日本語に翻訳されたものって何処かにあるのかな?

[wxBlog: Another Year of WX]
http://wxwidgets.blogspot.com/2009/01/another-year-of-wx.html
[The Wonderful World of wxWidgets 3.0]
http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/docs/publicity/WoWoW30.html?view=co

296 :デフォルトの名無しさん:2009/01/12(月) 17:45:04
>>294
御託だけで何もしないか、そうか、悪かったな。

>>295
概要だけで許せ

[wxBlog: Another Year of WX]
●2008年のwxの大きな動き
・コード書きより環境の改善が大きかった。
・sourceforgeのバグトラッカーをやめてTracを使うようにした。
・BuildBotを導入してビルドエラーを自動検出するようにした。
・Doxygenを使ってドキュメントを自動生成できるようにした。
●2008年に決定した戦略
・wxMacについてCarbonベースからαレベルではあるがwxCocoa(wxOSX)に移行を開始した。
   これにより32/64bitの両環境に対応しUnixスタイルのdynamic libraryからframeworkに移行できる。
・ライブラリの品質向上。
   これにより(長くメンテされておらず、バグが多く非互換性が強くなった)ODBCのサポートがドロップする。
   同様にかなり酷い状況だったwxSocketとwxURLがクリーンアップされた。
   全てではないがいくつかのwxGridの問題が修正された。

297 :デフォルトの名無しさん:2009/01/12(月) 17:45:28
(続き)
●機能追加
・wxPorpertyGridがwxWidgetsに含まれた。
・wxDataViewCtrlと関連クラスが結構良くなった。
・wxRichTextCtrlが多くの小さな修正で重要な改善を果たした。
・wxGrid/wxListCtrlのカラム表示サポートの一部としてwxHeaderCtrl、
 wxRearrangeListと関連クラスが追加され、カラムの順序変更が実装された。
・wxWrapSizerが追加された。
・wxCalendarCtrlがネイティブ実装になった。
・wxMessageDialogが改良され、特にボタンにカスタムラベルが使用可能になった。
・wxStaticTextがいくつか改良され、内容の省略をサポートした。
・wxGLCanvasがアンチエイリアスをサポート。
・AUIの主要な変更はwxAUIToolBarの追加。
・ついにwxBaseにイベントのサポートが追加された。
・忘れてるだけで他にもあるかも。
●他
・2.9.0の開発ブランチをプレビューリリースできなかった。
   Unicode関連のフィードバックを取り込むため可及的に早くしたい。
・wxButtonで画像をサポートして欲しいという要望が多い。簡単なのですぐやる。
・今年はwxOSXを完成させて3.0をリリースしたい。

298 :デフォルトの名無しさん:2009/01/12(月) 17:46:52
[The Wonderful World of wxWidgets 3.0]

Documentation in Doxygen
・3.0までにカスタムLaTexでドキュメントを整備する。
・ドキュメントの質を上げるためDoxygen形式を採用するが、手作業がかなり必要。
・これで3.0までに内容が見やすく正確になり、
 ビルトインサーチや多くのコントロールのスクリーンショットが含まれる。

C++ features and template support
・STLはバギーな環境・コンパイラが多かったので避けてきた。
・が、大分良くなったので以下のようなSTLが有効な部分で使用する。
   コンテナwxVector<T>、スマートポインタwxSharedPtr<T>、弱参照wxWeakRef<T>等々。
・Visual C++ 6.0のような古いシステムではwxが使えないか、機能制限される。

Platform features and backwards compatibility
・プラットフォームの新機能を取り込む一方、
 最新のシステム向けの開発を阻害しない範囲で互換性もサポートしてきた。
・特にOSXとGTK+2が問題で、10.4Tiger未満のOSXと2.4未満のGTK+2は非サポートに。
・クロスプラットフォームなDB APIは本来範囲外だろということでwxODBCはドロップ。

299 :デフォルトの名無しさん:2009/01/12(月) 17:48:24
Unicode: A Single Build for Everyone
・3.0までは歴史的経緯によりUnicodeビルドとANSIビルドの2つが存在する。
・WindowsやJavaはUTF-16を使いGTK+やOSXがUTF-8を使う時代になった。
・ANSIモードは削除。WindowsではUTF-16、それ以外ではUTF-8を使うことを決定。
   UnixとGTK+での呼び出しで異なるUnicode表現間の変換は不要になる。
   wxString、wxPrintf()等はUnicodeと8bit-stringの両方を必要に応じ受ける。
・wxアプリのユーザには見えないが、基礎的な変更で、3.0の主要な動機だった。

New 2D Drawing Code
・2D描画API(wxDC, wxPen等)は常にwxの一部だったが、初期からほぼ変わらず、
 単一のフロントエンドに対し多数のバックエンドが分岐して
 バイナリ互換性を気にすることなく簡単にプラットフォームの差違を吸収してきた。
・古い描画APIは多くのタスクと1990年代の描画能力に対し十分であったが、
 WindowsのGDI+やLinuxのCairo、OSXのCoreGraphics等、
 透過やアンチエイリアス、マトリックス変換といった現代的2Dシステムの
 先進的機能を使用できなかった。
・このため新描画API(wxGraphicsContextとか)が追加される。
   ビットマップでのαチャネルのサポート
   ビットマップのRAWデータへのアクセスをサポート
   定数を変更、wxMODERN→wxFONTFAMILY_MODERN、wxSOLID→wxBRUSHSTYLE_SOLID等。
・参照カウントが合理化されプラットフォームで共通になる。

なんかバカバカしくなったのでここまでで終了。
しょせん気まぐれだ、許せ。

300 :295:2009/01/12(月) 19:19:24
>>296-299
翻訳超乙。Unicode化の理由と、Graphicsの改善のあたりが良く分かった。
とりあえず、3.0は期待して損はなさそうだね。

301 :デフォルトの名無しさん:2009/01/12(月) 21:10:20
一服して若干気を取り直したので続きを投下。

Changes to wxBase
(訳注:wxBase自体の紹介は省略)
・wxStringとコンテナクラスには多くの変更がある。
・wxBaseの一番大きな変更はwx3.0でイベントベースのプログラムを書くための
 イベントループ、タイマー、ソケット等の追加。
・ソケットのコードは重複部分を削除、C/C++で分かれていたコードをドロップ。

302 :デフォルトの名無しさん:2009/01/12(月) 21:10:54
New controls and other major GUI additions for all ports
全ての修正とマイナーチェンジを羅列できないので、GUIの変更の概要のみ。
・柔軟な表現が可能なwxDataViewCtrl/wxDataViewTreeCtrlを実装。wxListCtrl/wxTreeCtrlを一部代替。
・wxGridの表形式はwxHeaderCtrlに分離したネイティブなヘッダを実装。
・wxPropertyGridの追加。
   名前-値のペアを表現する一般的クラス。
   wxDataViewCtrlと同様、数値、テキスト、リスト、フォントなどの
   組み込みのエディタ(in-place, ポップアップ、コンボボックス等)を提供する。
・wxHyperlinkCtrlをGTKでネイティブに、他では一般的方法で実装。
・ファイルダイアログのカスタマイズのためwxFileCtrlを実装。
・wxRichTextCtrlに親・子スクリプトのサポートを始め高速化など色々改良。
・wxTreeCtrlに状態アイコン表示機能追加。チェックボックス的にも使える。
・wxCalendarCtrlを刷新しMSWとGTK+でネイティブに。その他改良。
・wxTextCtrlとwxComboBoxでオートコンプリート機能を実装。
・wxAUIのクラス群にwxAUIToolBarを追加。より柔軟で自然に。
・wxBitmapComboBoxを再実装、MSWとGTKではネイティブに。
・wxBitmapToggleButtonを全プラットフォームに。
・wxStaticTextは全プラットフォームで省略表現をサポート、GTK+でマークアップ書式をサポート。
・全プラットフォームでwxListBoxの選択イベントの発起方法を書き直し精確にした。
・GTKとOSXでwxCollapsiblePaneをネイティブ実装。
・複数行に渡ってwrap可能な新しいsizer、wxWrapSizerを追加。
・OpenGlキャンバスにマルチサンプル、アンチエイリアスサポート追加。
 wxGLCanvasとwxGLContext分離。
・wxTopLevelWindowをネイティブウィンドウハンドルから構築するため
 MSWとGTK+にwxNativeContainerWindowを追加。

303 :デフォルトの名無しさん:2009/01/12(月) 21:11:29
wxMac specific changes (now called wxOSX)
・wxMacという呼称は廃止、wxOSXと呼称、iPhoneとiPodを一部サポート。
・Carbon, Cocoa, CocoaTouchの3つの一般コードに整理。
・OSXのCoreFoundationへのラッパでったり一般的なクラスへのラッパだったり。
・CarbonがwxMacのコアで安定していたが、iPhone対応にCocoa(Touch)が必要で、
 64bitのOSXでは非推奨となるため、現在はCarbonでも今後はCocoaにフォーカス。
・リストラクチャリングの一貫としてQuickDraw APIを使ったコードは削除。
 今後はCoreGraphicsを使用する。
・同様にOSX10.4にないCarbonの関数を使用したコードは削除。
 OSX10.4が最低動作環境になる。
・IconRefのサポート拡充。
・英語以外のロケールでのメニュー項目の重複を修正。
・ボタンにアクセラレータが使用可能に。
・CFLocaleを使用したwxLocal::GetInfo()の実装。

wxGTK specific changes
・GTK+のAPIが後方互換性がなくなって来たためGTK+2.4を最低環境とする。
・wxToolbarは新しいGTK+のツールバーAPIを使用。
・wxChoiceはGtkOptionMenuでなくGtkComboBoxを使用。
・wxComboBoxは非推奨のGtkCombでなく常にGtkComboBoxを使用。
・URLのドラッグはwxURLDataObjectで"text/x-moz-url"を使用。
・GtkPrintとCairoのダイアログを使用した新しいプリントバックエンド。
・アイドルイベントの生成コードを書き直し。
・タブの走査はGTK+でネイティブに。
・wxFrameのメニューバー、ツールバー、クライアントウィンドウとステータスバーは
 GtkVBoxを使用したレイアウトに書き直し。
・ウィンドウマネージャに帰属するウィンドウの装飾に係わらず
 トップレベルウィンドウSetSize()/GetSize()を正しく実装。
・wxYield()の呼び出しを避ける(リエントラント問題回避)ため
 wxClipboardの非同期APIを追加。
・Nokiaのタブレットで使われるMaemoプラットフォームの
 Hildonコントロールをいくつかサポート。

304 :デフォルトの名無しさん:2009/01/12(月) 21:13:12
wxMSW specific changes
・後方互換性が確保されており、ユーザ数が多いため最も安定しており、
 他のプラットフォームに比べ大きな変更はない。
・wxCheckListBoxがよりネイティブな感じに。
・長いツールチップが可能に。
・wxCheckBoxとwxToggleButtonで複数行ラベルをサポート。
・より正確なプリントプレビュー。
・サイズ変更可能なダイアログでリサイズグリップを表示。

以上、>>294曰く「御託だけで何もしない無職」の大雑把な訳でした。

305 :300:2009/01/12(月) 23:38:51
>>301-304
引き続きサンクス。wxOSXが結構面白そうに思えたんで、Mac Miniの中古でも
買ってみようかな。
あと、御託云々はあんまし気にしなくても良いと思うよ。

それよか、スタティックリンクでソース公開しなくてもいいwxWidgetsを使って
金儲けできると良いんだけど、クロスプラットフォームでお金になりそうなアプリって
どんなのだろ?どうにもイメージが沸かない。

306 :デフォルトの名無しさん:2009/01/13(火) 07:22:12
2ちゃんでちょっと煽られたくらいでむきになるようだと
実社会で辛くないか

307 :デフォルトの名無しさん:2009/01/13(火) 07:46:14
翻訳しただけでムキになってるとか決めつけるようだと
実社会ですぐ口論にならないか

308 :デフォルトの名無しさん:2009/01/13(火) 18:05:10
まぁ、どう見ても煽られたのが原動力にはなってるがな

309 :デフォルトの名無しさん:2009/01/13(火) 18:18:57
翻訳人は無能ではないことを証明したし
英語読めない人は3.0の改善項目がわかったし
みんな幸せってことでいいんじゃなかろか

310 :デフォルトの名無しさん:2009/01/14(水) 00:58:01
英語読めるようになりたいな

311 :デフォルトの名無しさん:2009/01/14(水) 01:40:22
これからはアラビア語の時代だけれどもね。

312 :デフォルトの名無しさん:2009/01/14(水) 13:11:27
つまらん、次

313 :デフォルトの名無しさん:2009/01/14(水) 13:56:31
これからはアラビアゴムの時代だけれどもね。

314 :デフォルトの名無しさん:2009/01/14(水) 22:09:16
MinGWでコンパイルしたwxWidgetsを使って
minimal sampleを動かそうとしたんだが
意味不明なタイミングでSIGSEGVが出て起動すらしない

◆gdbのスタックのコピー
スレッド [1] (中断中 : シグナル 'SIGSEGV' を受け取りました。説明: Segmentation fault)   
    9 wxFontMapperBase::Get()  0x0044e816   
    8 wxFontMapperModule::OnInit()  0x00546e3b  
    7 wxModule::DoInitializeModule()  0x00478632    
    6 wxModule::InitializeModules()  0x0047878c 
    5 wxEntryStart()  0x004bb64a    
    4 wxEntryReal()  0x004bb879 
    3 wxEntry()  0x00430e9e 
    2 WinMain() KirbyClone.cpp:117 0x00401406   
    1 main()  0x005340d1    

ソースコードはほとんどそのままなんだけど、(少なくとも上に載っている関数は触ってない)
原因があるとしたらどこ?

315 :デフォルトの名無しさん:2009/01/14(水) 22:13:06
それにしても、今日wxWidgetsの勉強を始めたばかりなんだが、
configureのオプションをいじると恐ろしいほどビルドに失敗するね
disable系を何個かつけると高確率でmakeが止まる

316 :314:2009/01/14(水) 22:47:14
sample自体をそのままmakeすると成功するみたいだ

となると、俺が自力で書いたMakefileが悪いのかな…

317 :デフォルトの名無しさん:2009/01/15(木) 10:31:46
>>316
MinGW はさわったことがないので山勘ですが。
メモリマップの方法がライブラリと本体で違うとか?


318 :デフォルトの名無しさん:2009/01/15(木) 19:07:46
商用版とGPL版しかなかったQtにLGPL版が出たね。
static linkできないのはちょっとアレだけど、なんかで使ってみてもいいかなー

319 :デフォルトの名無しさん:2009/01/15(木) 23:12:46
このままじゃ対抗できないからwxもWt(ワット)に改称してキャッチーな感じで攻めようよ。

320 :デフォルトの名無しさん:2009/01/16(金) 22:44:34
wxWidgetsにスタティックリンクしたプログラムをgdbでデバッグする。

コンパイル時に-gでデバッグ情報をつけるわけだが、
この時にライブラリの方もデバッグバージョンを使わないといけないのか?

なんかリリースバージョンをリンクした状態でデバッグしようとしたら
gdbが異常終了するんだが…

321 :デフォルトの名無しさん:2009/01/16(金) 23:46:48
>>320
俺の環境ではデバッグ無しでビルドしたwxをスタティックリンクしてもgdbは問題なく機能したよ
もちろん自分で書いたソースの範囲内でね
gcc3.4.5 gdb6.8と、あとは大体新しいやつ

322 :デフォルトの名無しさん:2009/01/17(土) 00:16:34
>>321
gdbを6.8に変えたらちゃんとエラーメッセージが出るようになった!

んで、開発にEclipse使ってるんだが、「共用ライブラリーシンボルを自動的にロード」
のオプションを外したら何もエラーが出ずにデバッグできるようになった

gdbのバージョンが古いと勝手に落ちる、「共有〜」にチェックつけてるとgdbが落ちる、
っていう前例も見つかったわ。
両方とも結構問題になってるみたいだ。

結果的にwxWidgetsは関係なかったな…でも解決したからいいや、ありがとう。

323 :220:2009/01/17(土) 00:26:59
すいませんお礼忘れてました汗
レスくださった方々ありがとうございましたm(_ _)m
結局ディスクがおかしかったみたいでchdiskで直りました。

ところで・・QTがLGPLで使えるようになるようですね。。
正直乗り換えるかもしれない(爆

324 :デフォルトの名無しさん:2009/01/17(土) 00:55:18
>>323
いますぐ全部ファイルをバックアップして
HDD とりかえたほうがいいと思う

ハードディスクは消耗品だからいちど壊れはじめるとはやいよ。

325 :デフォルトの名無しさん:2009/01/17(土) 06:58:04
不治痛のHDDは壊れやすい
凍死場に九州されるみたいで不安

326 :デフォルトの名無しさん:2009/01/17(土) 15:13:35
挙動が怪しいHDDはマジやばい
ファイルシステムが壊れてるだけならいいけど
物理的にエラーがでてて代替セクタとか使い出すと
見た目普通のままコロっと逝く時があるよ

初心者でも使いやすくてHDDの状態が大体わかる
CrystalDiskInfoを勧めちゃう

327 :デフォルトの名無しさん:2009/01/17(土) 21:07:43
>>326
なんで急にオカマ口調なの?

328 :デフォルトの名無しさん:2009/01/17(土) 22:29:44
CrystalDiskInfoって確かMFCで作られてるから
wxWidgetsでクロスプラットフォーム化するのってそんな手間じゃないのかな。

329 :デフォルトの名無しさん:2009/01/19(月) 01:27:50
ここのところ wxpython-usersに
Subject: will Qt mean the end of wxPython ?
っていうメールがめちゃめちゃ流れててワロタ



330 :デフォルトの名無しさん:2009/01/19(月) 05:56:41
APIはQTのほうがすっきりしているからな。
モッサリだけど。

331 :デフォルトの名無しさん:2009/01/19(月) 18:12:19
少くともQtでOS毎に自然な外観提供できて
複雑なライセンス体系が無くならない限り移行はできないなあ。。

332 :デフォルトの名無しさん:2009/01/19(月) 18:17:28
LGPLになったんだから、ライセンス簡単だろ?

333 :デフォルトの名無しさん:2009/01/19(月) 18:36:23
>>332
結局商用アプリ作るとかになったら、どうせ金クレクレモードに突入するじゃん。

334 :デフォルトの名無しさん:2009/01/19(月) 18:45:40
LGPLだと無問題だお?

335 :デフォルトの名無しさん:2009/01/19(月) 18:53:39
>>334
すまん、よく調べたらそうだった。
商用版も継続するってことは結局商用には使用料とるのかと思ってたよ。

こりゃやばいなwx。。

C++でクロスプラットフォームGUIライブラリが充実する
って流れは大歓迎だけどね。

336 :デフォルトの名無しさん:2009/01/19(月) 18:56:53
wx使う前はイメージヨカタんだが、IDEが悪いせいかMFCっぽくコントロールに連番ふってて、ダメだこりゃとオモタ。
この辺、Qtで解消すんのかなぁ?

337 :デフォルトの名無しさん:2009/01/19(月) 19:11:28
統合開発環境が簡単にインストールできれば、wxも生き残れるだろうが、
今のところ、qt 優勢。

338 :デフォルトの名無しさん:2009/01/19(月) 19:38:40
俺はEmacs使うからIDEはいらんから、軽いRADツールがあるのが一番かな。

339 :デフォルトの名無しさん:2009/01/19(月) 21:24:28
良RADさえあれば一気に巻き返せそうな気はするんだが

340 :デフォルトの名無しさん:2009/01/19(月) 21:31:41
wxのRADって有力なのはDialogBlocksとwxFormBuilderぐらい?
俺はここ来るまでwxGladeとXRCedしか知らなかった。
ウェブ検索してもこれ以外あんまり引っかからなかったし。

341 :デフォルトの名無しさん:2009/01/19(月) 23:39:01
あー,そういえば最新のDialogBlocks(4.29)で
プロジェクト開ける人いる?
linuxで引数としてプロジェクトを指定すると
can't open /hoge/moge/"hage.pjd"
的な事を言われる.
ダブルクォーテーションのせいかしら.


342 :デフォルトの名無しさん:2009/01/20(火) 07:37:07
IDEとしての方が意味が大きいけどCode::Blocksも入るんじゃない?
ただし作業自体はRAD的でもXRCじゃなくコードが挿入される形だけどね
あのコード見るとJavaでGUI作るときの苦々しさを思い出す・・・

343 :デフォルトの名無しさん:2009/01/21(水) 03:00:39
code::blocksはQtのプロジェクトも組める。あれでRADに
dialogblocks程度の操作性があれば良かったんだけど。
吐くソースはcode::blocks(wxSmith?)の方が親切な気がするし。

344 :デフォルトの名無しさん:2009/01/21(水) 08:45:41
>code::blocks

操作感が気に入らない゚听

wx-devcppの操作感が好き。
吐き出すコードは?だけど。

345 :デフォルトの名無しさん:2009/01/22(木) 03:48:17
>>344
wxSmithが我慢出来ない人はwxFormBuilder使うといいよ。
イベントもconnectとEVENT_TABLE選べるみたいだし、
とりあえずSizerの領域を均等に割り振る様な事もない。
wxGlade、DialogBlocks、wxSmith、wxFormBuilderと触ってみたけど、
操作性はDialogBlocks、ソースはwxSmithがいいと思った。
ソースはユーザーの弄り易さだけで、質はまだよく判らないんだけど。

それよりcode::blocksはnightyなんて出してないで、判りやすいバグを
放置したリリース版をリプレースするべきだ。
30分も触ると落ちるのは、どうかしてる@win32

346 :デフォルトの名無しさん:2009/01/22(木) 08:35:21
30分さわって強制終了なんて一回も経験したことないな
特定の使い方をして落ちてるか、環境が悪いかのどちらかじゃないか?

347 :デフォルトの名無しさん:2009/01/22(木) 10:44:42
DialogBlocks人気っぽいから入れてみたけど
軽快だし操作感がやたらいいな。

348 :344:2009/01/22(木) 11:37:56
そんなに沢山の選択肢示されても、無理。

349 :デフォルトの名無しさん:2009/01/22(木) 15:51:12
>>346
環境バカはかえれ

350 :デフォルトの名無しさん:2009/01/22(木) 17:09:59
>>346
Thread searchタブを右クリックしてThread searchのチェックを外すと
マウスオーバーでThread searchの部品が浮かび上がる。
あるいはScript consoleタブにThread searchのレイアウト(のみ)が表示される。
その後view menuからThread searchのonoffを行えば1分も経たずに落ちる。
他にも2byte圏のlocaleを使用するとhelp pluginが動かなかったり。
30分はwxSmithとbuildのみを使用して落ちる時間。
日本語化すると少し挙動が変わるから、その辺も不完全みたいだ。
以上は自宅のwindows xp sp3及び2000sp4での話。
落ちた事が無い=ほとんどまともに使ってない、と理解する。

>>347
動作自体はかっちりしてる。editorはscintilla使ったcode::blocksの方が高機能だけど。

351 :デフォルトの名無しさん:2009/01/22(木) 19:59:10
>>350
日本語化して動作が不安定になるなら、英語版を使ったほうがいい
日本語版と英語版で使い勝手に差が有るなら、日本語化を行なっている作者に文句をつけるべきだ

どうやら話し口調からして、いくつか特定の「落とし方」を知っているようだから、
それらをまとめて公式のフォーラムで報告することをおすすめする
オープンソース系のソフトを「まともに使っている」と自負できる人間なら、自分で修正してビルドするのもいい

一ついえることは、ここで文句を言っても、お前を含めて誰も得をしないということだ

352 :デフォルトの名無しさん:2009/01/22(木) 20:29:17
>>351
トラブルは全て英語の話で、日本語化もgettextを使った物だからbuildは一緒だ。
そもそも初めて使って5分で出る症状を、1年近く経ってから一々報告してどうする。
30分じゃ落ちた事がないと、使ったこともない奴が宣ってるから、実例を上げただけで、
ある情報に対しての損得は、その人次第だろう。

353 :デフォルトの名無しさん:2009/01/22(木) 22:15:44
ひさしぶりにwx-Devcppのサイト覗いたらバージョン上がってるんだけど、
使っってる人いたら教えてください。正常にデバッグができますか?

354 :デフォルトの名無しさん:2009/01/22(木) 23:59:37
>>352
何か勝手に「使用経験なし」だと思っているようだが、
俺はCodeBlocksを使って何本かソフト作ったことがあるぞ?
それこそ強制終了など一度も経験せずに。(むしろgdbがよく落ちた記憶がある)

報告してどうするって、バグフィクスを期待するに決まっているだろう
ユーザーがバグ報告するというのはソフト制作の大事な一環じゃないか。
修正とまでは行かなくとも、バグ回避の方法が製作者から聞けることだってある。

「文句を言うという行動は生産的ではないから、自分で何かしら行動したほうがいい」
ということがいいたいのだ。

とはいっても、こんなことは2chで言うべき言葉ではなかったかもしれないな

355 :デフォルトの名無しさん:2009/01/23(金) 02:38:38
俺もcode::blocksが落ちたことはないな
特定のペインが表示されなくなって困ったことはあるが

356 :デフォルトの名無しさん:2009/01/27(火) 20:14:55
WindowsのMinGW-5.1.4とMSYS-1.0.10を入れた環境で、wxWidgets-2.8.9をconfigureした後makeしたんですが、下記のようなエラーが出て先に進まなくて困っています。

0 [main] sh 2996 open_stackdumpfile: Dumping stack trace to sh.exe.stackdump

ご助言を頂けないでしょうか。

357 :デフォルトの名無しさん:2009/01/28(水) 12:10:51
WindowsだったらVisual Studioでやったらいいと思うんだけど

358 :デフォルトの名無しさん:2009/01/28(水) 14:05:13
せっかくフリーで可搬的なライブラリ使ってるのに
Windows上でだけ特別にVSなんか使いたくないわな。

359 :デフォルトの名無しさん:2009/01/28(水) 16:14:06
とりあえず>>356のエラーメッセージは糞の役にも立たないわな。
役に立たないレベルでは50歩100歩だが、同様の環境でwxWidgets-2.8.7はビルド成功してるんで参考までに。

360 :デフォルトの名無しさん:2009/01/28(水) 17:15:08
configureやdumpの内容も書いてない状況でした。
失礼しました。
同様の環境で出来たとのお話もあったので、
ライブラリ周りを見直してみたら上手くいきました。
助かりました。ありがとうございます。

361 :デフォルトの名無しさん:2009/01/29(木) 19:14:42
マウスイベントでWindowsAPIのSetCaptureに相当するものってあったっけ?

362 :デフォルトの名無しさん:2009/01/29(木) 19:18:07
自己解決
CaptureMouse();
ReleaseMouse();

363 :デフォルトの名無しさん:2009/01/30(金) 17:32:00
マウスの動きに連動して描画させると
非同期に描画命令が発行されるんだけど
つまりマウスの動きに合わせてPaintイベントが何度も呼ばれる
全部処理してから最後の描画が終わるまで画面が更新されない
そのせいでマウス移動中に画面がぐちゃぐちゃになるんだが
完全に表示が終わるまでマウスを動かなくするとか
他の描画が来たらそれ以前のはすべてキャンセルさせるとか出来ないの?

364 :デフォルトの名無しさん:2009/01/30(金) 18:17:32
>>363
他からPaintイベントが出るなら
マウス操作中は自分だけが処理するように
OnPaintを自前で用意すればいい。

マウスの移動だけではPaintイベント出ないとは
思うんだけど…

365 :デフォルトの名無しさん:2009/01/30(金) 19:45:18
マウスの動きに連動して描画させると

366 :デフォルトの名無しさん:2009/01/30(金) 23:14:50
描画(が何してるかわからんけど)でOnPaint出たっけ?

367 :デフォルトの名無しさん:2009/01/30(金) 23:23:21
>>363
マウスイベントハンドラで Refresh() を呼んでPaintイベント出してるとかいった状況?
もしそうなら、Refresh() 呼んだ直後に Update() 呼べば、同期的に画面更新できるよ。
(つまり、Update() から戻ってきたときにはPaintイベントが処理されて、画面更新が終わってる)

368 :デフォルトの名無しさん:2009/01/30(金) 23:39:52
>>367
マニュアル見る限りではUpdate()呼ぶならRefresh()要らんと思う

369 :デフォルトの名無しさん:2009/01/30(金) 23:49:37
>>368
マニュアルのUpdate()のとこに、
Use Refresh first if you want to immediately redraw the window unconditionally.
ってあるから、Refresh()いると思うよ。
無効領域がない状態でUpdate()しても何も起こらないと書いとる。

370 :デフォルトの名無しさん:2009/01/30(金) 23:54:52
ごめんRefresh()のinsteadだけ見てた

371 :デフォルトの名無しさん:2009/01/31(土) 09:11:40
質問があります。
ボタンの上での右クリックイベントを捕捉したいのですが、
button->Connect(ID_RIGHT_CLICK,
wxEVT_COMMAND_RIGHT_CLICK,
wxCommandEventHandler(MyFrame::OnRightClick),
NULL, button);
としてもうまくいきません。
どうすればよいでしょうか。

372 :デフォルトの名無しさん:2009/01/31(土) 12:28:29
>>371
OSは何? wxEVT_COMMAND_RIGHT_CLICKは Windows 95 and NT のみサポートらしいよ。
wxEVT_RIGHT_UPあたりで妥協しとくのが無難かもしれん。


373 :デフォルトの名無しさん:2009/01/31(土) 12:36:07
>>371
あ、Connect() の最後の引数はbuttonじゃなくて、thisとかじゃない?
eventSink引数には、イベント発生元オブジェクトじゃなくて、イベントハンドリングするオブジェクトを渡す。
だから、この場合はMyFrameオブジェクトを渡さないといかんです。

374 :デフォルトの名無しさん:2009/01/31(土) 15:19:10
>>372
OSはWinXP Home Editonです。wxEVT_RIGHT_UPにするとイベントを捕捉できました。
ありがとうございました。
>>373
eventSinkにはMyFrameオブジェクトをわたせばいいのですね。
ありがとうございました。

375 :デフォルトの名無しさん:2009/01/31(土) 18:50:14
タイマーイベントを使っていて反復実行している時
処理が混みだすとイベントがキューに溜まったような
状態になり他のイベントをリアルタイムに実行できなく
なります。
溜まったイベントを削除する方法はあるんでしょか。


376 :デフォルトの名無しさん:2009/02/01(日) 11:48:39
>>375
タイマー間隔を少し長くするか、wxIdleEventでRequestMore() しまくるなんてのはどうかな?
たまったイベントの削除関数とかは見かけたことないなぁ(あるかもしれないけど)

377 :375:2009/02/01(日) 17:54:01
回答有難うございます。
Win32APIにはイベントを削除する方法があった気がしたので
どうかなとおもったんですが。
時間管理を見直してみます。

378 :デフォルトの名無しさん:2009/02/06(金) 14:12:47
一番良いIDEは?
ダイアログイパーイ作る場合ね。

379 :デフォルトの名無しさん:2009/02/06(金) 14:34:46
Sizerの使い方を覚えたら、もうバカらしくてGUIで
ダイアログ作ろうだなんて思わないけどね

380 :デフォルトの名無しさん:2009/02/06(金) 14:40:26
コードでGUIを設定するのがバカらしいというのが一般的だが。

381 :デフォルトの名無しさん:2009/02/06(金) 16:11:56
RADどれ?って質問だったら万人に薦められるのはwxFormBuilderくらいなんだがな
RAD単体でPythonいらずってとこから
IDEとなると自分で全部試せとしか言えない

382 :デフォルトの名無しさん:2009/02/06(金) 16:15:11
>wxFormBuilder

ラジャ
使ってみるお。

383 :323:2009/02/10(火) 14:06:40
>>324
>>325
>>326

ありがとうございます!



384 :デフォルトの名無しさん:2009/02/11(水) 15:15:05
wxFormBuilderって、コンストラクタでnewしたインスタンスを
デストラクタでdeleteしてくれないんだけど、これは自分で書くの?

385 :デフォルトの名無しさん:2009/02/11(水) 17:37:33
自動でdeleteしてくれるライブラリ(スマートポインタとか)使わないなら
newした分だけdeleteするように書くしかないよ

386 :デフォルトの名無しさん:2009/02/11(水) 17:58:47
公式つながんない。

387 :デフォルトの名無しさん:2009/02/11(水) 23:24:55
wxDevC++!

ごめん嘘

388 :デフォルトの名無しさん:2009/02/12(木) 11:42:37
 ↑
何がウソで何がホントかハッキリしる!

389 :デフォルトの名無しさん:2009/02/12(木) 13:35:51
>>384
SizeにAddしたオブジェクトは勝手に削除される。
自分でdeleteしちゃだめ。

sizer.cpp の551行目

390 :デフォルトの名無しさん:2009/02/12(木) 14:54:15
ひょっとして>>384はGenerate Codeで吐き出されたコードに追記しようとしてるのか?
Generate Inherited Classで継承したクラスに自分のコードを書くのが正しい使い方だぜ?
そうじゃないと細かい修正でGenerate Codeしたらまた書き直さなきゃならないだろ

391 :384:2009/02/12(木) 23:12:05
>>390
いや、継承して書くのはわかってたけど、吐き出されるコードも
読んでおこうと見てみたらdeleteしてなかったので、
どうすんだろうなぁと。

で、>>389で納得しました。
ありがとうございました。

392 :デフォルトの名無しさん:2009/02/12(木) 23:16:13
wxWidgetsはフレームワーク側で色々ゴニョゴニョしているから
正直、自分で組んでて不安になって来るんだよな。細かい挙動とか、特に。

393 :デフォルトの名無しさん:2009/02/14(土) 00:44:18
Mac OS X 10.5にデフォルトで入ってるものを利用し、簡単なプログラムを組んだんだけど、
実行すると固まって操作できないのはそういうものでしょうか。
最新2.8.9のものをmakeして利用すれば問題ないのでしょうか。
っていうか、wxOSXっていつ頃になるの?

それからWindows上でwxFormBuilderを使ってみたのですが、
イベント部のコードを吐いてくれるのはいいけど、
マージしてくれないので、使いにくい。
そうゆうもんですか。
DialogBlocksは有償だけあって使いやすかったけど、レジストしてないから制限に引っかかる。
金ないからorz
なんかいいGUIのBuilderが欲しいと思った。


394 :デフォルトの名無しさん:2009/02/14(土) 01:43:50
>>393
>Mac OS X 10.5にデフォルトで入ってるものを利用し、簡単なプログラムを組んだんだけど、
デフォルトでは wxPerl とか wxPython しか入ってないとおもったけど、どうやるの?
OS X は実行ファイルは .app パッケージに入れないとイベント受け取れないから
固まったように見えますよ。
http://wiki.wxwidgets.org/WxMac_Issues#Building_a_MacOSX_application_bundle
とか参照。


395 :デフォルトの名無しさん:2009/02/14(土) 07:52:22
>>394

あ、そうなんですか。
Makefile書いてメイクしたのですが、minimalサンプルみたらxcodeのファイルがありますね。
MacはMacの作法にのっとってオブジェクトを配置しないといけないんですね。
ちょっとやってみようと思います。

因に私がやったメイクは、LinuxのwxGTKを使うように、
wx-config でインクルードとライブラリをあててmakeしました。
wxMacを特別に入れた記憶はありません。


396 :デフォルトの名無しさん:2009/02/14(土) 09:11:03
>>395
なるほど、wxPerl とかだけでなくて wxWidgets そのものが
デフォルトでインストールされてるんですね。そりゃそうか。

397 :デフォルトの名無しさん:2009/02/24(火) 14:17:50
もうすぐ2月が終わる
2.9.0来るかなぁ

398 :デフォルトの名無しさん:2009/03/01(日) 16:32:53
Eclipse CDTでwxしようとしてるんですが、ビルドとかは問題なくできるものの
補完のためのインデクサが

 Syntax error: DECLARE_EVENT_TABLE();

とかポップアップしてきて機能しません。

ビルド自体には影響してませんが、これだとエラーと非エラーが混ざって
使い勝手が悪いので、なんとか正常に処理させたいのですが、同じように
困ってる話は見つかっても解決方法が見当たりません。

どうすればいいでしょうか?

399 :デフォルトの名無しさん:2009/03/02(月) 23:10:17
wxPython2.8のAnimationが返す値おかしくね?
DisposalMethodがどうも-1ずれてるみたいし
BackgroundColourもなんか変だ
俺のだけ?


400 :デフォルトの名無しさん:2009/03/03(火) 13:38:10
ソースあるんだから自分で調べたらいいじゃんか

401 :デフォルトの名無しさん:2009/03/03(火) 19:05:13
うんその言葉で読む気になったわ
、で-1ずれてんのはcoincideだってさ
BackgroundColourは最初のフレームから
背景色に初期化しなかった俺のミス

ここで聞くよりソース読んだほうが
確かに早いけど誰もその情報は共有できん
のだ
いい意見有難う

402 :デフォルトの名無しさん:2009/03/10(火) 10:16:05
質問
レイアウト制御において

Sizer > Panel > Sizer
Sizer > Sizer

ってやっぱり違うんですか?( > は入れ子の関係を表してます)
コントロールをまとめる枠としての Panel の存在意義がイマイチわからないっす。

403 :デフォルトの名無しさん:2009/03/11(水) 02:02:27
Panelは子コントロールの親になる
Sizerはあくまで下層要素のサイズを制御するだけ

404 :デフォルトの名無しさん:2009/03/11(水) 07:05:48
>>403
ありがとうございます。
単にレイアウトを制御したいだけなら Sizer を直に入れ子にして、
コントロールを論理的にグループ化したい場合は Panel でまとめる、という感じですね。

405 :デフォルトの名無しさん:2009/03/11(水) 08:02:25
いつも使ってて思うことなんだけど、Sizerというクラスをなくして
レイアウトの機能もWindowに含めてほしい(統合してほしい)
そうなっていないということは、そうすると何か問題があるのだろうか

406 :405:2009/03/11(水) 08:03:13
ごめんageてしまった

407 :デフォルトの名無しさん:2009/03/11(水) 08:19:10
>>405
コントロールのレイアウトのためだけにWindowを入れ子にするのは
メモリ効率が悪いからじゃないでしょうか

だからレイアウトアルゴリズムだけをクラスとして抜き出して Sizer なんてものを
作ったのでは

408 :デフォルトの名無しさん:2009/03/11(水) 23:22:44
レイアウトアルゴリズム増やそうとする度に
wxWindowクラス書き換えて肥大化していくのは困るでしょ

409 :デフォルトの名無しさん:2009/03/12(木) 10:16:25
GoF でいうところの Strategy パターンというやつだな

410 :デフォルトの名無しさん:2009/03/13(金) 19:16:34
質問させて下さい。
wxRuby でちょっとした GUI ツールを書いているのですが、
ウィンドウを close してアプリを終了してもプロンプトが返ってきません。

ウィンドウを XRC から作るように変更したところでこのような
現象が発生するようになりました。

具体的には
Wx::XmlResource.get.load_frame_subclass(self, nil, "MyFrame")

があると上記の問題が発生します。
on_exit も呼ばれず、どうも何かが解放されずに残っていてアプリの終了を
邪魔しているような印象です。
どのような原因が考えられますか?

411 :410:2009/03/13(金) 19:18:34
補足
ウィンドウはきちんと表示されており、イベントハンドラの設定もうまくいっています。

412 :410:2009/03/13(金) 22:04:27
CloseEvent に対するデフォルトのハンドラが呼ばれなくなったと推測
XRC からリソースをロードした段階で CloseEvent をトラップする別のハンドラが
設定されたのか?

よくわからん。調査続行

どなたかヒントでもあればお願いします m(__)m

413 :410:2009/03/13(金) 23:24:53
evt_close {|event| exit }

でとりあえずプロンプトは戻るようになった。

414 :デフォルトの名無しさん:2009/03/14(土) 10:35:35
俺もその現象あった
XRCは使ってなかったけど、Frameのサブクラス作ったからそのせいかも

415 :410:2009/03/14(土) 11:31:46
>>414
自分も Frame のサブクラス作ってますが、それだけでは上記の問題は
発生しませんでした。
GUI が複雑になってきたので XRC をロードするように変更したところ
close でプログラムが終了しなくなりました。

閉じられるウィンドウが最後の一枚だったら exit というハンドラを自分で
設定すれば元の動作に戻るはずですので、そうしようと思ってます。

416 :デフォルトの名無しさん:2009/03/19(木) 19:09:19
なんで SetCellAttr はないんだ? セル単位で制御したいのに
まあ、自分で書いたらいいだけだけど

417 :デフォルトの名無しさん:2009/03/21(土) 11:26:29
2.8.10安定版リリース

133 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)