不知道是業務員言過其實了,每次都很期待新版的到來.... http://spaces.msn.com/members/GordonLiWei/ 7月31日 Delphi 2006 !(Dexter) 隨著Dexter推出的日子逐漸接近，Dexter的Beta測試也進入了如火如荼的階段，目前Dexter的狀態是第4個Beta，我也好久沒有看到Borland的產品會有Beta 4了(Delphi 8/Delphi 2005是Beta 3之後便被下令推出)，而且Dexter還有好幾個月的時間繼續進行穩定性，延展性以及效率的調整，這實在是令人高興，因為這代表Borland的高層現在腦筋終於清醒了，我不知道Dexter推出後在Marketing方面是不是可以掃除Delphi 8/Delphi2005負面的印象，但我知道如果Dexter依照目前的計劃發展下去，那麼我們終於將有一個很棒的產品了，OK，不多說Politics方面的事以免我有麻煩，讓我們多談談Dexter技術以及產品本身的事好了。 如果您還不知道Dexter是什麼的話，簡單的說Dexter將在一個IDE中(Galileo 4.0)中提供C/C For Win32，Delphi For Win32，C#，Delphi For .NET開發的能力。而Dexter最主要的目標即是提供C Builder 10.0的功能，是C Builder 自從6.0以來最大幅度的一次大改版，下面列出的事項大概是Dexter的主要功能: - Same IDE as in Delphi 2005 with enhancement - Is about IDE features, bug fixes and Win32 (a Win32 supporting release) - Conformance for Boost and ACE. Almost 100% ANSI conformance. - SSE2 in inline assembler - Code folding, basic refactoring (as in Delphi 2005) and C specific refactoring - Heavily revised compiler and linker - Similar speed in compilation. Code Insight is much faster. - COM - Improved type library support - Some features for a C tuned project manager, easier project manager - Dinkumware STL, IntraWeb, Corba - Support Win32 drivers development - Updated Win32 headers and libraries - Full support for make tool (commandlines) - CVS support thru SCC API Dexter在C Builder的Code Complete方面終於提供了快速的反應能力，和Delphi一樣，除了在第1次啟動Code Complete時稍微緩慢一點之外，隨後的速度比以前快上了數倍，因此C Builder的使用者再也不需要關閉Code Complete了。 此外Dexter特別的C Builder的使用者開發了新的Project Manager，提供了強大的專案管理能力，在Dexter中開發人員不但擁有更多的控制權以進行更彈性的設定，Dexter也開放了在Build過程中開發人員可以在編譯之前(Pre-Compile)，編譯之後(Post-Compile)以及連結之前(Pre-Link)設定各種不同的Build工作，這可以讓開發人員設定客製化的Build程序，這應該是許多C Builder開發人員要求許久的功能了。 雖然Dexter的主力是提供C Builder 10.0，但是在Delphi方面也同樣提供了許多令人流口水的功能，例如Together For Delphi終於實作出來了，Delphi For Win32和Delphi.NET現在都有了Together的功能，Delphi的開發人員終於可以使用Together For Delphi來開發各種不同的UML模型，這也是我個人等待多時，最重要的功能。下面是Delphi其他方面的強化: -- -Together For Delphi(Win32/.NET) - -ECO 3 - -更多的Refactoring - -CORBA Support 在資料庫技術方面Dexter更是有長足的進步，不論是在Win32和.NET都一樣，這方面也是我有興趣的地方，也許在下一次的文章中再讓我們討論。 另外一個Dexter最重大的改變是使用了新的Memory Manager。以前Borland的Memory Manager(Borlandmm.dll)在服役多年後終於光榮引退，被新的Memory Manager取代，而這個新的Memory Manager在R&D的測試中提供了比Borlandmm.dll更好的效率，Delphi R&D也希望新的Memory Manager能夠提昇Dexter IDE整體的執行效率。 現在我想Borland的問題是當Dexter正式發表時，到底如何傳遞Dexter在各方面強大的進步?是告訴C Builder的使用者呢?還是告訴Delphi的使用者?在Dexter產品發表會時是邀請C Builder的使用者呢? 還是邀請Delphi的使用者? 這真是有趣的事情 ..................... .楛耕傷稼,楛耘失歲. .....................

請教各位專家: 未來有無支援Unicode ? Thanks. SCJP/OCA

有無支援 Unicode ,這是小事 希望 Delphi 2006 能在軟體工程方面支援更多的功能 這次看到開始支援Together For Delphi(Win32/.NET) 實在令人興奮 未來的程式設計不在是要每個人寫一堆程式 而是要多思考 如果愛情也有味覺 那麼 有沒有ㄧ種愛 微微泛酸 不太苦澀 有點甜密 嚐起來的滋味讓人想起幸福 Thomas Chiou

------
Thomas Chiou

borland出啥產品都不重要， 最要的是，要寫豐富的文件!! 學c 的，誰不會去查微軟的msdn! borland的help只要多寫，一定能長存... -- Level: A newbie of C Book: The Complete Reference C

------
A fan of C#.NET

看了這麼多功能上的增強,讓人很期待,可是delphi 8,delphi 2005推出時亦都說了一堆很讓人心動的特色,可是一用上似乎落差不少,bug又一堆,書籍亦沒幾本, 這個版本如果再沒改善,只怕Borland要潰敗了,因為產品一而再的出trouble,在競爭淘汰速度快速的軟體市場,會受到唾棄的ㄋ,況且使用者越少越無法形成氣候,在技術交流或相關討論上受到的影響更大,請Borland多多加油! Freshwang

我覺的是看心酸的。像2005看起來很強 但是市面上的書真的少之又少 實在不得其門而入    還是只能呆呆的用delphi 7 在好的產品，沒人用還是枉然    ..-----------βλμε------------..
◎Ｏｏ月夜 光明 藍更愁ｏＯ◎
藍調月光城v4：http://inping.myweb.hinet.net/ (暫時使用中..) 明日報(藍調．月光)：http://mypaper2.ttimes.com.tw/user/a6475

------
月夜 光明 藍更愁

Unicode VCL的事情，我從Delphi 3就在Borland的newsgroup上跟Borland要，要到現在，完全不見蹤影。 站在開發國際化軟體的角度來看，我完全不認為Unicode的良好支援是次要的事情，相反的，是最重要也最根本的。一個軟體開發工具的其他方面功能再好，如果根本的Unicode支援很破爛，就不能用來開發國際化軟體。 你看BDP，Borland說好說妙，但是BDP對Unicode的支援就是不完整，你在繁體中文平台上要用BDP去存取簡體中文或日文的資料，就是會糊成一堆問號，當然也不要說在簡體中文平台上用BDP去讀寫繁體中文或日文的東西了。很奧妙，.NET上頭來來去去都是Unicode了，但是拿BDP來用，就是可以讓作業系統預設字元編碼內不支援的字糊掉。這也不是一天兩天的事情了。 當然啦，這個功能都已經被討了那麼多年，Danny Thorpe最近也講話了。他說，Unicode VCL這事情牽涉到一些內部字元寬度計算的問題、元件designer的問題，會影響到舊程式的向後相容性，所以他們現在只考慮在相容性問題較小的平台上做Unicode VCL，像是已經出現了的.NET VCL，以及未來的64-bit X86 VCL。 這話一出，我也感到很無奈，我完全不認為字元寬度計算算是哪們子重要到要影響Unicode VCL出不出的問題。如果Win32 Unicode VCL把字元編碼定為UTF-8，請Danny Thorpe說說看，哪裡會對他們用ISO-8859-1/ASCII的西方人會造成任何影響？東方人算字元寬度，也不是直接拿byte length在算的啊！個人認為Danny Thorpe的發言對於此問題非常缺乏解決誠意，不過人家是Delphi compiler core的大頭目，人家說了算。改用UTF-8當Win32 VCL的字元編碼，又不是今天才有人建議這麼做，從1998年就看過有人在建議了，Borland不理就是不理。那要不要加上MSLU的支援呀？這個要求，我想Borland也是完全不會理會的。 功力夠的人面對不同問題，自然有自己的解決方案，Unicode VCL如是，文件問題也好說，大不了自己去翻MSDN、反組譯、反編譯。但是功力不夠的小朋友怎麼辦呢？ Dexter的新糖果確實也是挺令人流口水的，可是如果Borland不能解決客戶根本的需要，即使新糖果再好吃，又有什麼用呢？

Delphi在win32好好的,只差那麼一點點,若Borland能放棄對Win 9X的相容性支援,在整個Win32 VCL重新整理過支援Unicode並不是不可能的(連BDE、ADO那些資料庫引擎介面一同整理) 只是他們感覺不到unicode對delphi的重要,熟知老外的很多軟體也都被我們拿來用,多語系共存對我們來講真的很重要 不知道有沒有使用TntWare Delphi Unicode Controls開發資訊系統的經驗?不知道是不是堪用在日常系統上? 我實際測的經驗是TTntDBEdit->ClientDataSet->ADOQuery並不能正常的存取額外的中文字,我不知道是否有辦法可設定成功 最近公司要我評估兩岸三地看能不能上unicode,我就很頭痛 ..................... .楛耕傷稼,楛耘失歲. .....................

引言: Delphi在win32好好的,只差那麼一點點,若Borland能放棄對Win 9X的相容性支援,在整個Win32 VCL重新整理過支援Unicode並不是不可能的(連BDE、ADO那些資料庫引擎介面一同整理) 不知道有沒有使用TntWare Delphi Unicode Controls開發資訊系統的經驗?不知道是不是堪用在日常系統上? 我實際測的經驗是TTntDBEdit->ClientDataSet->ADOQuery並不能正常的存取額外的中文字,我不知道是否有辦法可設定成功

透過MSLU的支援，並不需要放棄Win9x的相容性。 TNT Unicode controls不錯用，但是TNTWare不可能幫你把所有你要用的3rd party元件都unicode化。以ThemeEngine的元件來說，幸好設計者當初就有考慮Unicode問題，裡頭都是WideString，只差顯示的那段沒有Unicode化，所以可以改它的source code，本來裡頭control的祖先物件是Delphi標準VCL，改成衍生自TNT Unicode controls裡的，顯示上的Unicode化也差不多完成了。 TNT的問題是，你只能在Delphi for Win32上用，同一套code搬上Delphi.NET，就連編譯都過不去。 依我長久以來的觀察，從VCL/compiler層次採用UTF-8 MSLU的解決方案是處理這個問題時，相容性最好的方法。這做法是在compiler裡頭多個option，指定讓AnsiString採用UTF-8字元編碼，而VCL內看到compiler指定了這個選項時，就會用MSLU來秀東西。 什麼相容性問題？哪來的相容性問題？如果我可以改Delphi VCL跟compiler的原始碼，我早就跳下去改了。