すべてはC#が存在する前に始まりました
1999年に戻って、Visual Studio 5/6がありました。独立系ソフトウェアベンダーまたはWindowsを使用している企業で、たとえば従業員のプロジェクトに費やした時間を追跡できるアプリケーションを必要とする場合、いくつかの選択肢がありました。
- Visual Basicのフォーム。
- Visual C ++のMFC、ATLまたはWin32。
- Access 97/2000のフォーム。
- ASP Webサイト。
- Javaアプレット。
当時、私たちはドットコムバブルが崩壊する直前だったので、(4)または(5)に長けていた人は誰でも、魅力的なドットコムでストックオプションの交渉に出かけました。
(3)ロックと全体的なスケーラビリティに問題がありましたが、必要に応じてサポート機能を実行するためにシェルアウトする多くのアクセス駆動型ソリューションを見ました。
そのため、VBとVC ++が残ります。
当時、VBのフォームエディターは生産性に優れていました。ボタン、ラベル、テキストボックスだけでなく、巧妙なグリッド、Excelシート、IEインスタンスなどの再利用可能なコンポーネントの完全な「OLEコントロール」ツールボックスを使用して、コンポーネントをドラッグアンドドロップできます。ワイヤリングは舞台裏で行われました-すべてがオブジェクトのようであり、イベントハンドラを追加するためにダブルクリックするだけでした。これは、Visual C ++では非常に困難でした。当時のVisual Studio開発者サポートチームのメンバーとして、Visual Basicサポートの呼び出しは、どのコンポーネントを使用するのが最適であるか、特定の方法でアプリケーションを最適化する方法がほとんどでした。「X、Y、Zのユーザーインターフェイス機能を使用してアプリケーションを作成する方法」はほとんどありませんでした。
Visual C ++でリッチUIを構築することは、別の課題でした。ダイアログとSDI / MDIフォームのビジュアルエディターサポートがありましたが、かなり制限されていました。OLEコントロール(ActiveX)をMFCまたはWin32に埋め込むことのサポートは、ATLの方がやや簡単ですが、黒魔術でした。コンポーネントのカスタムイベントに必要な接続ポイントはもちろんのこと、イベントのサイズ変更やオーナー描画などの単純なものを作成するのは非常に苦痛でした。
はい、VC ++には実行速度、デバッグ機能、柔軟なフレームワーク/ライブラリ/ UIオプションがありましたが、IDEサポートではそのすべてをカバーできなかったため、ウィザード、包括的なMFCクラス階層、90日間などの最も一般的な操作に対処しました/ 2-free-incidentsサポートライン。
VRCに同梱されているアプリケーションパッケージャーであるIIRCは、アプリ、VBランタイム、および最新の共通コントロールDLLをパッケージ化し、CDに入れて顧客に提供できるスタンドアロンEXEインストーラーを提供します。この「msvcrtXX.dllとmfcxx.dllをインストールしましたか?」はどれも、MFC開発者を悩ませました。
そのため、市場投入までの時間とリッチなユーザーインターフェースの理由から、VBは非常に大きな支持を得ました。
Visual J ++とVisual InterdevがVS6でヒットしたとき、Visual Basic IDEがVisual C ++のものとの戦いに勝ったことは明らかでした。Visual Studio .NETに新しいCOOL C#言語用のVBのようなフォームエディタがあったことはまったく驚きではありませんでした。
これまでずっとVBの人々が楽しんでいたUIデザイナーと結合した新しいJava / C / C ++のような言語は、MFC / ATL / Win32で今やられていたC ++の人々に新しい移行パスを与えました。VB.netの100%下位互換性の欠如が気に入らないVB 3/4/5/6の人々にとって、これは使い慣れた環境で新しい言語を学ぶ機会を提供しました。
VBがこのような包括的な製品であった理由は、Microsoftの起源と関係がある可能性が高く、Basicは主力の開発者製品ですが、現時点では引用がありません。