Win32APIと.NETの質問

[神族]

Win32APIと.NET一緒に使ってアプリ作れる事できるんですか？誰か教えてプリーズ！

*追記：たとえばCreateWindowの中にSystem::Windows::Forms::Buttonを入れたいんですけど

[softya（ソフト屋)]

どう一緒に使うか条件が書いてないので困りますが、出来る出来ないかで言えば出来ると答えるしか無いでしょう。
もっと具体的なことを聞いてもらうと答えやすいです。
C#からWin32APIを使う方法を知りたいとかですね。

[オカピーα]

*追記：たとえばCreateWindowの中にSystem::Windows::Forms::Buttonを入れたいんですけど

CreateWindowはWin32APIの関数ですか？それとも自作のウィンドウ作成用関数ですか？
とりあえず後者として話を進めると、神族さんのやりたいことは出来ないと思います。
捉え方によると思うのですが、この文面だと「C言語（Win32API）でC#を使う」というふうに受け取れます。
C言語ではC#は実行できません。しかし、C#からC言語（WIｎ32API）を使うことは出来るようです。
色々な意味でC言語は不遇の言語です。

[softya（ソフト屋)]

追記を見逃していたようです。
過去の内容に追記しても更新メールが届いたりトピックが上に上がるわけではないので返信の形で書いてもらわないと伝わりませんのでお願いします。

>*追記：たとえばCreateWindowの中にSystem::Windows::Forms::Buttonを入れたいんですけど

.NetFrameWorkはフレームワークなので部分的に使うことは不整合を起こします。
なので、環境以前に主をWindowsAPIにして従を.NetFrameWorkにすることは困難です。
これは、.NetFrameWorkを利用できるC#であろうとVB.NETであろうと変わりません。

さて、純粋なＣ言語から.NetFrameWorkを利用できる環境は今のところ存在しません。
代わりに.NetFrameWorkのC++版であるC++/CLIでCLRフォームアプリのプロジェクトを使えば.NetFrameWorkのフレームワーク記述にＣ言語的な物を混ぜることは可能ですが、先程も書いた通り主従を逆にすることは出来ません。
それとC++/CLIのCLRフォームに関してはVisualStudio2012から新規に作ることは見た目上はできなくなっていますので、将来性としてマイクロソフト自体がフェードアウトを狙っているようです。
.NetFrameWorkのＧＵＩは、C#かVBで組んでくれという意向だと思います。それに逆らうのは得策と思えませんので、何か別の方法を検討されたほうが良いと思います。

色々な意味でC言語は不遇の言語です。

言語のコンセプトの問題ですからＣ言語が悪いわけではありません。
まぁ、私も過去の資産を気にせず素早くGUIを組みたいのならC#を使うでしょうから適材適所であり何でもＣ言語で組むのは間違った選択だと思います。
C言語でもGTK+を使えばWin32APIを直接使うよりもＧＵＩが楽に組めます。つまり、面倒なものであるWin32APIを使う必然はないです。
更にC++ならＱｔなどいろいろな選択肢がありますので、環境とやりたい事のために言語を選ぶのはプログラマーとして必要なことです。

[YuO]

System::Windows::Forms::ButtonはComVisible属性がついていて，引数がtrueとなっていますから，COM扱いで呼び出せるはずです。
茨の道であることがわかっているので，テストコードを書く気にもなっていないのですが……。
Visual Basic for ApplicationsやVisual Basic 6などから.NET Frameworkのクラスを使うには，というような質問に対して使えるという回答がついているのを見るので，可能だとは思います。

[神族]

追記を見逃していたようです。
過去の内容に追記しても更新メールが届いたりトピックが上に上がるわけではないので返信の形で書いてもらわないと伝わりませんのでお願いします。

>*追記：たとえばCreateWindowの中にSystem::Windows::Forms::Buttonを入れたいんですけど

.NetFrameWorkはフレームワークなので部分的に使うことは不整合を起こします。
なので、環境以前に主をWindowsAPIにして従を.NetFrameWorkにすることは困難です。
これは、.NetFrameWorkを利用できるC#であろうとVB.NETであろうと変わりません。

さて、純粋なＣ言語から.NetFrameWorkを利用できる環境は今のところ存在しません。
代わりに.NetFrameWorkのC++版であるC++/CLIでCLRフォームアプリのプロジェクトを使えば.NetFrameWorkのフレームワーク記述にＣ言語的な物を混ぜることは可能ですが、先程も書いた通り主従を逆にすることは出来ません。
それとC++/CLIのCLRフォームに関してはVisualStudio2012から新規に作ることは見た目上はできなくなっていますので、将来性としてマイクロソフト自体がフェードアウトを狙っているようです。
.NetFrameWorkのＧＵＩは、C#かVBで組んでくれという意向だと思います。それに逆らうのは得策と思えませんので、何か別の方法を検討されたほうが良いと思います。

色々な意味でC言語は不遇の言語です。

言語のコンセプトの問題ですからＣ言語が悪いわけではありません。
まぁ、私も過去の資産を気にせず素早くGUIを組みたいのならC#を使うでしょうから適材適所であり何でもＣ言語で組むのは間違った選択だと思います。
C言語でもGTK+を使えばWin32APIを直接使うよりもＧＵＩが楽に組めます。つまり、面倒なものであるWin32APIを使う必然はないです。
更にC++ならＱｔなどいろいろな選択肢がありますので、環境とやりたい事のために言語を選ぶのはプログラマーとして必要なことです。