- - PR -
ネイティブアプリとCLRアプリの違い
1
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-03-14 01:16
また質問で恐縮です。
今回は考え方というかアプローチについてお聞きしたいのです。 例えば.NETで「こういうアプリを作ろう」と考えたときに GUIやコントロール部分について他のアプリを参考にするときが ありますよね。 で、過去の偉大なアプリの多くはネイティブのアプリが多い様に思います。 私は自分が常用しているアプリを参考にするのですが、MS製のアプリは 独自のコントロール使いまくりで(VS等）どうしても参考にしがたく 有名オンラインソフトなどを参考にしたりしています。 そこで些細な事なのですが、標準コントロールを使っていて それと同じように動作させたいと思っても、.NETでのコントロールだと 微妙に（？）動作やプロパティが違うようで同じように動作しない ことがあるように思います。 例としては、本当に些細な事なのですが、私が常用しているメーラーである Becky!ではメールの一覧表示でSysListView32を使用しているようなのですが 一番左のカラム（カラムヘッダー）のサイズをマウスでドラッグして 変更使しようとしても固定されており変更できず、その他のカラムは変更できます。 これを私が開発しているアプリでSystem.Windows.Forms.ListViewや System.Windows.Forms.ColumnHeaderなどの関連するコントロールのプロパティ など、どこをどういじっても上記の様にはなりません。 このような差異に頻繁に出くわします。 参考にしているアプリが独自コントロールを使っているのであれば 諦めもつくのですが、やはり.NETのコントロールの性と諦めなくては いけないのでしょうか？ そもそもネイティブアプリを参考にするのが間違っている等、 アプローチの糸口だけでもご教示いただけたら 今後の参考にさせていただきますので、宜しくお願いできないでしょうか？ | ||||||||||||||||||||
|
投稿日時: 2006-03-14 01:43
まあ、標準だと思って諦めた方が先は明るく見えますね。 私の場合ですが、何とかなるようなことであれば、カスタム コントロールとして改善するというスタンスです。 (諦めがつく場合も COM を使うよりは遥かに良いということで納得しています) # しっかり読んでなかったのかな。 # なーんか、思いっきり質問の意味を取り違えてますね。> 私 [ メッセージ編集済み 編集者: じゃんぬねっと 編集日時 2006-10-12 11:19 ] | ||||||||||||||||||||
|
投稿日時: 2006-03-14 09:47
なんか、よく、わからん。
.NET は 2002 年からなんだから、そりゃそうじゃない？
わからん。マイクロソフトが用意しているものを使っているんだから、標準のものに手を加えている、でしょ。 もっとも、マイクロソフトは内部にしか公開していない API を使っているようですけど。それでもたいていのコントロールは、公開されています。
なんか、言っていることが逆。それだったら、Bekky! を作ったところが「独自コントロール使いまくり」じゃないですか。 自分で WIN32API をラッピングすればいいのでは？ カラム変更のメッセージが飛ぶだろうから、そこでキャンセルすれば、固定できますよね？
これがわからん。マイクロソフトが用意したものと、他社が用意したものと、なぜ比べる？マイクロソフトが用意しているのは、すべてのアプリケーションの基本部分ですよね。それで足りない、付加価値をつけなければと、考えた他社が付加価値をつけた訳ですよね。なにを比べようとしているの？ _________________ | ||||||||||||||||||||
|
投稿日時: 2006-03-14 10:35
標準コントロールを標準のまま使っているソフトで、有名なものなんてそう滅多に無いと思いますよ。標準コントロールの動作を、メッセージを捕ら得ることでカスタマイズするのは、MFCでも.NETでも普通に行われることです。
.NETで提供されている標準の動作に不服なら、MFCと同様に動作をカスタマイズすればよいではないですか。その為に必要な機能もきっちり提供されているのですし。 | ||||||||||||||||||||
|
投稿日時: 2006-03-14 12:39
ということで実装サンプルー。
.NET のコントロールは、基礎的なところはプロパティでできて、それに満足できなければメッセージを処理できるという二段構えの構造ですが、初めからメッセージを意識してフォームを作成するのに比べれば諸メッセージや構造体が未定義（System.Windows.Forms.dll には internal とかでありそうだけど）なこともあってメッセージの方には手を出しにくいかも知れませんねー。 // でも Open/SaveFileDialog はもうちょっとなんとかして欲しかったな。せめて sealed は……。 | ||||||||||||||||||||
1
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。