Visual Studio にネイティブ API フォームのデザイナーがないのはなぜですか? デルファイに似ていますか?何かプログラムやツール等があればアドバイスお願いします。
純粋な API で複雑なウィンドウを設計するための最良のアプローチは何ですか?
Visual Studio にネイティブ API フォームのデザイナーがないのはなぜですか? デルファイに似ていますか?何かプログラムやツール等があればアドバイスお願いします。
純粋な API で複雑なウィンドウを設計するための最良のアプローチは何ですか?
ダイアログ用のリソース エディターがあり、コードがあります。コントロール自体からのより良いサポートがあればいいのですが、ビジュアルデザインツールを見逃したことは一度もありません.
中心的な問題は抽象化レベルです。Win32 コントロールだけを使用して複雑な GUI を設計するには、ある程度の事前の検討が必要であり、すべてのコントロールにはわずかに異なる奇妙さ、機能、機能があります。それらには、上にデザイナーを構築するために使用できる共通のインターフェイスがありません。
WinForms は、デザイナーのサポートを念頭に置いてゼロから設計されました。Win32 コントロールの主な設計上の懸念は、コードとデータのメモリ フットプリントでした。
MFC (まだメモリ不足の多くの兆候を示しています) でさえ、まともなフォーム デザイナーを正当化するのに十分なほど、これらの奇妙さを抽象化していません。
適切なフォーム エディターが付属するすべての環境 (Watcom ++ / Optima、ZINC、および名前を忘れた他のかなりの数を覚えています) には、高度な抽象化レベルの適切なフォーム ライブラリも付属しています。
次に、変更の問題があります。デザイナーの出力はどうあるべきですか? XML データ ファイルを狙うこともできますが、ネイティブ アプリにいくつかの大きなライブラリへの依存関係が追加されることになり、あまり意味がありません。または、コードを作成しますが、C/C++ はそれに適していません。別のバイナリ形式?デザイナーが許可するものに制限します。
最終的に、設計者は各コントロールを個別に処理する必要があり、それでもコントロールとウィンドウ メカニズムを完全に理解することからあなたを切り離すことはできませんでした。C++ が大規模なデスクトップ開発の最初の選択肢であったとき、これは決して実行されませんでした。間違いなくより良い選択肢がある場合に、今それを追加するのはかなりばかげた動きです。
これはおそらく、WinAPI でコントロール レイアウトを行う標準的な方法がないためです。自分で管理する必要があります。WinAPI には基本の「コントロール」クラスはありません。すべてがある種のウィンドウであるため、一般的なレイアウト エディター/デザイナーとの違いをサポートする方法はありません。
ただし、ダイアログでウィンドウ レイアウトを作成し、自分で、または codeproject で公開されているメソッドを使用してサイズ変更可能にすることができます (これまたはこれ- どちらも MFC 関連ですが、変換はかなり簡単です)。
または、デスクトップのニーズに合わせてScreenLibを調整します。