アカウント名:
パスワード:
今でも十分迷惑してるのにさらにカオス化するのか…
vbaも拡張されカオスになりそうですね個人的には.netと同様の仕様に刷新してほしい
個人的には.netと同様の仕様に刷新してほしい
どう足掻いたところでベースがCOMインターフェースだし、それに由来する仕様も多々あるからなぁ……
いっそ後方互換性を大幅に切り捨てたExcel.NETみたいに作り替えない限りは……
.NETってCOMが凄く使いやすくなってるけども。少なくともC++と比べれば天国と地獄ほどに使いやすくなってる。それもC#のウリの一つだからね。
.NETのCOMアダプタにVBX/OCXの仕様拡張を追加してやれば今までと大差ない構文で使えると思うよ。
そもそも今だって.NETからExcelの操作はできるし。
VSTOみたいに参照カウンタ管理をwrapperにやらせるか、ひたすらReleaseComObjectするのが使いやすいって?その程度のモノをC#のウリとか言ってる人って、本当にC#使えてるんだろうかって思うんだが。VS2002とか2003レベルの知識で止まってるんじゃねーの?
つーか、単純にCOM使ってExcelとか操作するのにC++使うのが見当違いだっただけでしょ。わざわざ不向きな用途のモノを使って地獄だったみたいに語ってるの、何言ってんのって感じなんだが。そんなのは(.NETになる前の)VBでやれば良かったし、COMを操作するだけならVB6はVB.NET(やC#)より使いやすいよ。変なWrapper使わなくてもLate Bindingできるところとか、COMのオブジェクトもGCが喰ってくれるところとか。流石に設計思想が古すぎるし、サポートの問題があるから、今からVB6を使うのは馬鹿だとは思うけど。
Excel操作に関した話ではなくCOM操作に関してC++よりはるかにマシと書いてるだけだが。
そもそも大半のアプリケーションはC++で書かれてるしそこでCOM関係の死ぬほどかったるい記述をさんざんしてるわけだよ。C++は向いて無いとかそんな次元の問題じゃねーよ。それにくらべれば.NETのCOMの扱いは天国と地獄だと書いてるんだよ。
VBX/OCXまわりの拡張に関して.NETは弱いからそこを拡張とも書いてるだろ。まだ足りないってわかってるからそう書いてあるんだよ。「今だってできる」とは書いてあるけど楽にできるとは書いてないだろ。楽にできるなら拡張するなんて記述ないと考える脳みそは無いのか?
自分の理解したいように好き勝手に文章を理解して反論するとか脳みそ足りて無いんじゃねーのか?相手が自分より知らないとか思うのは思い上がりも甚だしいよ。
そもそも大半のアプリケーションはC++で書かれてるしそこでCOM関係の死ぬほどかったるい記述をさんざんしてるわけだよ。
それって「適切な開発環境や言語を使う」という基本的なことすらできてなくて、ナントカの1つ覚えでC++使ってたってだけじゃないの?何をもって大半というかは知らないけどさ。Excelと連携しなきゃいけないような業務アプリで、VBでできなくてC++が必要な要件ってそんなにあるとは思えないし。
つーか今更VBXって……WIN16引きずって.NETで何したいんだよ老害。
VBX/OCXまわりの拡張に関して.NETは弱いからそこを拡張とも書いてるだろ。
いやー、それ.NETのできた理由の否定にし
> VBでできなくてC++が必要な要件ってそんなにあるとは思えないし。ネイティブコード…というかWin32APIとか叩きたかったら基本そっちだろ。ExecuteExcel4MacroのCALLでAPI叩きまくるとかどんだけマニアックなんだよ。.NETで出来ることは.NETでも出来るけどExcelのVBAではどうにもならんだろ…WSHのVBSやJScriptでも同じ。
VB6あたりは大半のWin32API叩けましたが……ついでに、VB6で扱えないWindows APIがあったら、そこだけ読み換えのDLLをVC++で作れば事足りました。わざわざVC++側でCOMとか踏み込む必要なし。
その程度の判断基準で、どの言語・開発環境を適切に選ぶ能力がなかったから苦労しただけでしょ、自業自得。
今時素のVB使えとか頭おかしい。Excelの中でVBAでない素のVBが走ってるならともかく。せめて.NETだろ…あれならAPIも叩ける。でも外から触るという点では.NETもC++も同じ。
なんかコイツこそ馬鹿の一つ覚えでVB(しかも.NET以前の物のみ)しか使えない人なんじゃないかと。
なに、技術力以前に日本語が不自由な人なの?誰も「今時VB使え」なんて話はしてないんだけど?
バカの1つ覚えで、昔、WindowsアプリにVC++しか使ってなかった阿呆が居て、「そんなのVBで作って、API絡みのVBで対応できないところだけVC++で作ればいいだろ」って話が出ただけじゃん。OCXどころかVBXとかいう言葉が出る時点で、今の話なわけねーもん。少なくとも、よほどピーキーな処理(たとえばVBから何度もGlobalAllocしてDLLとデータやりとりするとか、Window Messageを使った独自処理が大量にあるとか)でない限り、GUIまわりを作るならVBのほうがVC++より生産性は高いし、機能的に既存のモノに依存する分バグも出にくい。いや、たとえそういう処理が介在するとしても、その部分だけVC++で作ってDLLなり何なりで外出しするのが効率良いことのほうが多いけどな。
その事実を無視して「Windows API叩くならVC++」とか言ってるヤツは、3タイプしかいない。1つは単にVBでもVC++でもgotoだらけのスパゲティとか量産するタイプで「何で作っても収拾つかなくなるから、中身が単純なだけVC++使ったほうが可視化できる」って理由tで使ってるヤツ。そして、「BASICとかホビー用途だし」という意識高い系(笑)のプログラマだったか。まあ実際、タコいヤツが書いたVBコードは本当に目も当てられない惨状になるけど、それは使い方が悪いだけなんだよ。つーかそれはC++とかも同じなんだがね。そういうのしか知らなくて「VBはマトモな開発に使えない」って思い込んでるんだとしたら、幾分マシではあるが。それでも残念なプログラマーなことにかわりはない。あるいは「もっと簡単にできる方法を韜晦して、工数を多くさせて稼いだり、あるいは属人性の高いコードを作って会社の癌になろうとしてた」腐れプログラマーか。そんなのプロフェッショナルでも何でもない、ただの穀潰しなんだがね。そのどれかでしかないんわ。どれだとしても碌なやつじゃないってこと。
なんのためのC++か、なんのためのRADツール(VB)か、その辺の棲み分けすら理解してないお馬鹿に言ってもわからんかもしれんけどね。
で、現行での.NET Framework(+C#)のメリットでCOM使いやすいとかいうのもちゃんちゃらおかしい話で、そりゃ(苦行のつもりなのか無知なのかは知らんけど)VC++だけでCOM連携するWindowsアプリ作るのに比べれば多少はマシではあるものの、無印VBに比べれば大幅に劣化してる。だから、その仕様を引きずり続けてるExcelを、現行の後方互換性を維持して(≒COMインターフェースまたはそのWrapperで).NETで使うのはクソ面倒臭いままだし、Excel.NETみたいな大幅改修が必要ってだけの話なんだが。つーか本来、.NETの設計思想は「メモリ管理はフレームワークにやらせる」かつ「Late Bindingは極力使用しない」っていう方向性なわけで、そんなもんと真っ正面から対立するCOMが「使いやすい」ってもうね。ヘソが茶を沸かすよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
入力されたデータがどのようなデータなのかを自動認識 (スコア:4, すばらしい洞察)
今でも十分迷惑してるのにさらにカオス化するのか…
Re: (スコア:0)
vbaも拡張されカオスになりそうですね
個人的には.netと同様の仕様に刷新してほしい
Re: (スコア:0)
個人的には.netと同様の仕様に刷新してほしい
どう足掻いたところでベースがCOMインターフェースだし、それに由来する仕様も多々あるからなぁ……
いっそ後方互換性を大幅に切り捨てたExcel.NETみたいに作り替えない限りは……
Re: (スコア:0)
.NETってCOMが凄く使いやすくなってるけども。
少なくともC++と比べれば天国と地獄ほどに使いやすくなってる。
それもC#のウリの一つだからね。
.NETのCOMアダプタにVBX/OCXの仕様拡張を追加してやれば
今までと大差ない構文で使えると思うよ。
そもそも今だって.NETからExcelの操作はできるし。
Re: (スコア:0)
VSTOみたいに参照カウンタ管理をwrapperにやらせるか、ひたすらReleaseComObjectするのが使いやすいって?
その程度のモノをC#のウリとか言ってる人って、本当にC#使えてるんだろうかって思うんだが。VS2002とか2003レベルの知識で止まってるんじゃねーの?
つーか、単純にCOM使ってExcelとか操作するのにC++使うのが見当違いだっただけでしょ。わざわざ不向きな用途のモノを使って地獄だったみたいに語ってるの、何言ってんのって感じなんだが。
そんなのは(.NETになる前の)VBでやれば良かったし、COMを操作するだけならVB6はVB.NET(やC#)より使いやすいよ。
変なWrapper使わなくてもLate Bindingできるところとか、COMのオブジェクトもGCが喰ってくれるところとか。
流石に設計思想が古すぎるし、サポートの問題があるから、今からVB6を使うのは馬鹿だとは思うけど。
Re: (スコア:0)
Excel操作に関した話ではなく
COM操作に関してC++よりはるかにマシと書いてるだけだが。
そもそも大半のアプリケーションはC++で書かれてるし
そこでCOM関係の死ぬほどかったるい記述をさんざんしてるわけだよ。
C++は向いて無いとかそんな次元の問題じゃねーよ。
それにくらべれば.NETのCOMの扱いは天国と地獄だと書いてるんだよ。
VBX/OCXまわりの拡張に関して.NETは弱いからそこを拡張とも書いてるだろ。
まだ足りないってわかってるからそう書いてあるんだよ。
「今だってできる」とは書いてあるけど楽にできるとは書いてないだろ。
楽にできるなら拡張するなんて記述ないと考える脳みそは無いのか?
自分の理解したいように好き勝手に文章を理解して反論するとか
脳みそ足りて無いんじゃねーのか?
相手が自分より知らないとか思うのは思い上がりも甚だしいよ。
Re: (スコア:0)
そもそも大半のアプリケーションはC++で書かれてるし
そこでCOM関係の死ぬほどかったるい記述をさんざんしてるわけだよ。
それって「適切な開発環境や言語を使う」という基本的なことすらできてなくて、ナントカの1つ覚えでC++使ってたってだけじゃないの?
何をもって大半というかは知らないけどさ。Excelと連携しなきゃいけないような業務アプリで、VBでできなくてC++が必要な要件ってそんなにあるとは思えないし。
つーか今更VBXって……WIN16引きずって.NETで何したいんだよ老害。
VBX/OCXまわりの拡張に関して.NETは弱いからそこを拡張とも書いてるだろ。
いやー、それ.NETのできた理由の否定にし
Re: (スコア:0)
> VBでできなくてC++が必要な要件ってそんなにあるとは思えないし。
ネイティブコード…というかWin32APIとか叩きたかったら基本そっちだろ。
ExecuteExcel4MacroのCALLでAPI叩きまくるとかどんだけマニアックなんだよ。
.NETで出来ることは.NETでも出来るけどExcelのVBAではどうにもならんだろ…WSHのVBSやJScriptでも同じ。
Re: (スコア:0)
VB6あたりは大半のWin32API叩けましたが……
ついでに、VB6で扱えないWindows APIがあったら、そこだけ読み換えのDLLをVC++で作れば事足りました。わざわざVC++側でCOMとか踏み込む必要なし。
その程度の判断基準で、どの言語・開発環境を適切に選ぶ能力がなかったから苦労しただけでしょ、自業自得。
Re: (スコア:0)
今時素のVB使えとか頭おかしい。Excelの中でVBAでない素のVBが走ってるならともかく。
せめて.NETだろ…あれならAPIも叩ける。でも外から触るという点では.NETもC++も同じ。
なんかコイツこそ馬鹿の一つ覚えでVB(しかも.NET以前の物のみ)しか使えない人なんじゃないかと。
Re:入力されたデータがどのようなデータなのかを自動認識 (スコア:0)
今時素のVB使えとか頭おかしい。Excelの中でVBAでない素のVBが走ってるならともかく。
せめて.NETだろ…あれならAPIも叩ける。でも外から触るという点では.NETもC++も同じ。
なに、技術力以前に日本語が不自由な人なの?
誰も「今時VB使え」なんて話はしてないんだけど?
バカの1つ覚えで、昔、WindowsアプリにVC++しか使ってなかった阿呆が居て、「そんなのVBで作って、API絡みのVBで対応できないところだけVC++で作ればいいだろ」って話が出ただけじゃん。OCXどころかVBXとかいう言葉が出る時点で、今の話なわけねーもん。
少なくとも、よほどピーキーな処理(たとえばVBから何度もGlobalAllocしてDLLとデータやりとりするとか、Window Messageを使った独自処理が大量にあるとか)でない限り、GUIまわりを作るならVBのほうがVC++より生産性は高いし、機能的に既存のモノに依存する分バグも出にくい。
いや、たとえそういう処理が介在するとしても、その部分だけVC++で作ってDLLなり何なりで外出しするのが効率良いことのほうが多いけどな。
その事実を無視して「Windows API叩くならVC++」とか言ってるヤツは、3タイプしかいない。
1つは単にVBでもVC++でもgotoだらけのスパゲティとか量産するタイプで「何で作っても収拾つかなくなるから、中身が単純なだけVC++使ったほうが可視化できる」って理由tで使ってるヤツ。
そして、「BASICとかホビー用途だし」という意識高い系(笑)のプログラマだったか。まあ実際、タコいヤツが書いたVBコードは本当に目も当てられない惨状になるけど、それは使い方が悪いだけなんだよ。つーかそれはC++とかも同じなんだがね。そういうのしか知らなくて「VBはマトモな開発に使えない」って思い込んでるんだとしたら、幾分マシではあるが。それでも残念なプログラマーなことにかわりはない。
あるいは「もっと簡単にできる方法を韜晦して、工数を多くさせて稼いだり、あるいは属人性の高いコードを作って会社の癌になろうとしてた」腐れプログラマーか。そんなのプロフェッショナルでも何でもない、ただの穀潰しなんだがね。
そのどれかでしかないんわ。どれだとしても碌なやつじゃないってこと。
なんのためのC++か、なんのためのRADツール(VB)か、その辺の棲み分けすら理解してないお馬鹿に言ってもわからんかもしれんけどね。
で、現行での.NET Framework(+C#)のメリットでCOM使いやすいとかいうのもちゃんちゃらおかしい話で、そりゃ(苦行のつもりなのか無知なのかは知らんけど)VC++だけでCOM連携するWindowsアプリ作るのに比べれば多少はマシではあるものの、無印VBに比べれば大幅に劣化してる。
だから、その仕様を引きずり続けてるExcelを、現行の後方互換性を維持して(≒COMインターフェースまたはそのWrapperで).NETで使うのはクソ面倒臭いままだし、Excel.NETみたいな大幅改修が必要ってだけの話なんだが。
つーか本来、.NETの設計思想は「メモリ管理はフレームワークにやらせる」かつ「Late Bindingは極力使用しない」っていう方向性なわけで、そんなもんと真っ正面から対立するCOMが「使いやすい」ってもうね。ヘソが茶を沸かすよ。