質問

Visual Studio にはネイティブ API フォームのデザイナーがないのはなぜですか?デルフィに似てる?何かプログラムやツール等があればアドバイスをお願いします。

純粋な API で複雑なウィンドウを設計するための最良のアプローチは何ですか?

役に立ちましたか?

解決

おそらく、WinAPI にはコントロール レイアウトを行う標準的な方法がなく、自分で管理する必要があるためです。WinAPI には基本的な「Control」クラスはありません。すべてが何らかの種類の Window であるため、共通のレイアウト エディター/デザイナーでそれらの違いをサポートする方法がありません。

ただし、ダイアログでウィンドウ レイアウトを作成し、自分で、または codeproject で公開されているメソッドを使用してサイズ変更可能にすることはできます (これ または これ - どちらも MFC 関連ですが、翻訳は非常に簡単です)。

あるいは適応する スクリーンリブ デスクトップのニーズに応えます。

他のヒント

ダイアログ用のリソース エディターとコードがあります。ビジュアル デザイン ツールを欠かしたことはありませんが、コントロール自体のサポートがもう少し充実していればいいのにと思います。

中心的な問題は抽象化レベルです。 Win32 コントロールのみを使用する場合、複雑な GUI を設計するには事前の考慮が必要であり、コントロールはすべてわずかに異なる奇妙さ、機能、特徴を持っています。これらには、デザイナーを上に構築するために使用できる共通のインターフェイスがありません。

WinForms は、デザイナーのサポートを念頭に置いてゼロから設計されたことがそれを示しています。Win32 コントロールの設計上の主な懸念事項は、コードとデータのメモリ フットプリントでした。

MFC (依然としてメモリ不足の兆候が数多く見られます) でさえ、まともなフォーム デザイナーを保証するほどこれらの奇妙な点を十分に抽象化することはできません。

まともなフォーム エディターが付属するすべての環境 (Watcom ++ / Optima、ZINC などは覚えていますが、名前は忘れました) には、高い抽象化レベルを備えたまともなフォーム ライブラリも付属しています。

次に、改造の問題があります。 デザイナーは何をアウトプットすべきでしょうか?XML データ ファイルを狙うこともできますが、それはネイティブ アプリにいくつかの大規模なライブラリへの依存関係を追加することになり、あまり意味がありません。あるいは、コードを作成するが、C/C++ はそれにあまり適していません。別のバイナリ形式ですか?デザイナーが許可する範囲に自分自身を制限することになります。


最終的に、設計者は各コントロールを個別に処理する必要がありますが、それでもコントロールとウィンドウのメカニズムを徹底的に理解することからあなたを切り離すことはできません。C++ が大規模なデスクトップ開発の第一の選択肢であったときには、これは決して行われませんでした。追加する , 、おそらく、より良い選択肢があるときに、それはかなり愚かな行動になるでしょう。

これは、Microsoftのです。彼らはすでにDOTNETとC#の方に移動しました。 Visual Studio 2005がそれらのための素敵なGUIエディタがあります。なぜあなたは純粋なAPIを使用する必要があるのですか?

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top