關于"經典VB"的一些想法
2024-07-21 02:20:44
供稿：網友
最近，這個主題已經出現在了“新聞組”里（呃，至少已經出現在了很多blog里），我一直在考慮如何回復大家……但事實上，我根本沒有回復的必要，因為dave totzke已經替我這么做了。他在文中提到了一點：我們應該讓c++繼續存在下去，是因為office是用c++寫成的……關于這點我不太敢恭維，因為這理由實際上應當是——這個被托管的世界無法取代我們為底層的硬件和操作系統編寫本地代碼的需要。我們至少需要一種方案，使圖形軟件、設備驅動器、網絡信息過濾器等等都能高效地運作……因此，我們還是需要非托管的c++。但對于vb6的變革而言，就沒有類似的需要了。
確實，升級復雜的代碼庫是件相當困難的事，但是安裝vb.net并不意味著你必須刪除vb6。你可以保持你現有的代碼庫，而在.net里編寫新的代碼，然后在必要的時候讓這兩個世界互相運作。在msdn里，你可以找到一個access應用程序，當你點擊某些特定的按鈕時，它會彈出新窗體來……你也可以找到為outlook和word寫的基于vb6的插件，其實它們就是.net代碼的包裝材料，是個vb6代碼和vb.net代碼的混合品。
還有很多東西，它們可以在vb6里找到，卻沒有被包含在vb.net里，我覺得這樣不太好，但我想，它們可以通過.net組件、activex組件、或者是visual studio插件的形式引入vb.net。譬如說dde（動態數據交換，涕淌注）吧，它本身并不是.net框架的一部分，因此，我設想如果能有一個小組件，使我們在.net中能直接訪問dde，在新數據到達時能夠引發事件，諸如此類的……那就好多了。我真希望人們能致力于構建（或者是致力于請求構建）這樣的組件，而不是拼命叫囂著做某某事不是個好主意。至少至少，人們也應該努力使它被列進升級開發的進程中。我們最好能讓某個人來構建這樣的一個工具，這個工具不僅僅是一個向導，而是能勝任升級的工作，并且包含了一大堆附加的庫，藉此來轉換舊的代碼。這將會是個浩大的工程，但是比起對vb6做一些補充性的改進而言，它的成果會更令人滿意的。
順便提一句，我一直都想告訴大家，我真的認為，.net世界中至今仍然缺少了一些東西。我們需要為.net提供一個類似 access界面那樣的工具……它不能像vb6里的那個工具，因為它對于我眼中的開發人員的水平而言，實在是太難用了……它應該是一個支持數據庫拖放的應用程序創建工具，像access、filemaker pro、hypercard，等等那樣的……它應該能在這些設置背后自動生成.net代碼，這樣，我們就可以使用這個工具，配合著由vb.net或c#創建的代碼，來擴展簡單的應用程序。我想我會給它起個名字，access.net :)
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
以下是原文供網友們參考，如果大家要到duncan先生的主頁上讀文，請點擊這里。
this topic has been in the 'news' lately (well, at least in the blogs) and i've been considering replying.... but it turns out i don't have to, because dave totzke has done it for me. i don't really agree with his comment that we've kept c++ alive because office is written in it... it is actually because the managed world doesn't replace the need to write native code against the underlying hardware and os. we need to have at least one avenue for folks to write the high-performance graphic software, device drivers, network packet filters, etc.... so we need unmanaged c++ to stay. there isn't a similar need for new development on vb6.
yes, it is hard to upgrade complex code bases, but when you install vb.net it doesn't uninstall your copy of vb6. it is possible to maintain an existing code base while you write new code in .net and then interop as necessary between the two worlds. within msdn, we have access applications that pop-up windows forms when you click certain buttons... we have vb6-based add-ins for outlook and word that are simple wrappers around .net code and some that are a mix of vb6 code and vb.net code...
there are some things that were in vb6 and are not available in vb.net that i feel still need to be available, but i think they could be made available as .net components, activex components, or add-ins to visual studio. take dde for example, it just isn't part of the .net framework, so i think it would be nice if we had a small component that allowed me to access dde from within .net, fired events when new data arrived, etc... i wish that people would put their effort towards building/requesting these types of components instead of advocating something that just isn't a good idea. at the very least, push for more effort to be put into the upgrade process, lets get someone to build more than just a wizard, build a tool that does the upgrade and includes a ton of additional libraries to help with transitioning older code. that would be a lot of work, but the end result is still better than just doing incremental development on vb6.
by the way, this is as good of time as any to point out that i do believe that there is something missing in the .net world right now. we need an access-like tool for .net... not what vb6 was, which was really much too complicated for the level of developer i'm thinking of... but something that is a drag-and-drop database form focused application creation tool. like access, filemaker pro, hypercard, etc... but producing .net code behind the scenes so that you can extend simple applications created using this tool with code produced out of vb.net/c#. i think i'll call it access.net :)
