私は wxWidgets を使用して職場でテスト ツールを作成しています。コードでウィジェットを作成することにより、常に GUI を作成してきました。これを行うのに役立つツールを試したことはありません。wxWidgets の他のユーザーは通常どのようにインターフェースを作成しますか? ツールを使用する場合、どのツールを使用しますか? ツールを使用する場合、そのツールを使用することにはどのような長所と短所があると思いますか?
4 に答える
私がwxFormBuilderを使用した理由は 2 つあります。
- これはクロスプラットフォームであり、Linux で動作するものが必要でした。
- 私は wxWidgets を初めて使用するので、GUI の作成に多くの時間を費やしたくありませんでした。
非常にうまく機能すると思います。また、同様の GUI 構築ツール (Borland C++ Builder、Jigloo for Java、Delphi) に慣れているので、使いやすいことがわかりました。
wxFormBuilder を使用して基本クラスを生成するというパラダイムに固執し、継承するクラスを作成してアプリケーション固有のロジックを最上位に階層化し、wxFormBuilder が生成する C++ コードを手動で編集しない場合、うまく機能し、簡単にwxFormBuilder で GUI を更新して修正します (そしてまた…)。
利点:
- ドキュメンテーションを常に参照する必要なく、ビジュアルな方法で非常に迅速にベース GUI を生成できます。
- GUI が期待どおりに見えるようにするためだけに、多くのコード/コンパイル/実行サイクルを実行する必要はありません。
- 基本クラス/派生クラスのパラダイムにより、GUI とビジネス ロジック コードを適度に明確に分離できます。
潜在的な欠点
- 免責事項:私は wxWidgets を使用して非常にシンプルでわかりやすい GUI を作成しただけなので、ツールを限界まで押し上げたことはありません。
- GUI で高度な処理を行っている場合、基本クラス/派生クラスのパラダイムが邪魔になる可能性があります (OTOH は、アプローチを再考する必要があることを示している可能性があります)。
- あるオペレーティング システム用にコンパイルしたときはメニュー項目が必要でしたが、別のオペレーティング システム用にコンパイルしたときは必要ないという状況がありました。これをサポートする wxFormBuilder のロジックはありません。私は、常にメニュー項目を作成し、それが間違った OS (理想的ではない) である場合、派生クラスを非表示にするという近道をとることになりました。
それくらいだと思います。
私が見つけたのは、ツールを使用して GUI で最初のカットを作成することが多く、「最終的な」フォームに収束しているように見えるときは、手動で再コード化/リファクタリングを開始することです。
ただし、これの一部はツールにも依存します。私は wxWidget の大ファンではありません。
XRC/XRSファイルの使用を検討することをお勧めします。
私は自分でそうすることを気にしなかったことを認めなければなりませんが。wxFormBuilder(XRCをサポートしています)を使用して静的GUIコードを生成するだけで、すべての(小規模な)GUIデザインに十分です。
あなたが知っている、それは依存します。たとえば、標準的な動作が必要な場合は、通常、GUI に DialogBlocks を使用します。これが最速の方法だからです。カスタム動作が必要な場合 (たとえば、現在のプロジェクトは、GUI がスキンをサポートするクロスプラットフォームのメディア マネージャーです)、GUI 関連のすべてをコードで行います。カスタム コントロールについては、次のとおりです。
- コントロールがプロジェクト固有のことを行う場合、同じプロジェクト ファイルを使用して DialogBlocks で作成します (このプロジェクトで使用される他のフォームとダイアログを使用)。
- コントロールを再利用可能にする必要がある場合 (汎用コントロール)、別のプロジェクトを作成し、DialogBlocks にスケルトンを作成します。可能であれば、空のイベント ハンドラーとクラス変数を追加し、Visual Studio でロジックを手動で記述します。
それでおしまい :)