網路上好像也有人有類似問題，我花了兩個鐘頭總算搞定，因為安裝過程有點繁瑣，寫下來當備忘
1.移除這三套控件
2.從共用/Delphi bpl 移除 TMSUnicodeD2007.bpl
3.打開AlphaControls內的 sDefs.inc 將上面Unicode的部分取消註解並回存
4.打開acnt2007_R.dpk並編譯
5.打開acnt2007.dpk安裝
6.打開TMSUnicodeDED2007.dpk選ViewSource 將 TMSUnicodeD2007 改為 acnt2007_R
7.安裝TMSUnicodeDED2007.dpk
8.打開JAM文件夾內的JamShellD2007Win32.dbk, 選ViewSource 將 TMSUnicodeD2007 改為 acnt2007_R
9.安裝JamShellD2007Win32.dbk 大功告成
因為這些控件都有各自的UnicodeUnit，不容許放在一起，所以要小改一下
2009年6月22日 星期一
2009年6月11日 星期四
Web-Base VS Application
有時候寫Win32的Application真的是很無奈，尤其是寫到與Server牽扯不清，只差資料庫是從本地撈而已，其他功能巴不得都是Web-Base，Application儘量保持獨立的特性，似乎只能從大型軟體看到了，一堆小軟體動不動就要找伺服器，沒伺服器根本也不用玩了。
然而這些小軟體又覺得Web-Base在操作上不如傳統的Application，於是奇奇怪怪的Function就出來了，什麼東西都得上Server去問....
回到AP介面上，又覺得沒有Web-Base那麼靈活，要修改又是一大堆更新程序（廢話，Web-Base只要伺服器程式改一下當然快）
最重要的是Application的程序員得承受軟體正常是應該的，不正常就該死，例如，用戶犯了羊顛瘋，手指會顫抖，然後以超音速惡搞按鈕（Web-Base不會有這種問題，按鈕點下去---你就等吧..按到死都不會有Error），所以AP程序員就必須再寫一套羊顛瘋防制函數。
再來當用戶用超音速點選各個功能鈕，造成AP Crash時，死的也是AP程序員，為什麼人家XXX軟體不會當，我們家軟體就會當（人家XXX工程師月薪是我的五倍，同時是一整個Team在開發...OK!）
永遠只有AP工程師會想到，如果更新了，會產生哪些問題，怎樣避免過於複雜的程序，而大老闆們一天到晚就是，能不能新增這個功能，能不能把那個功能搞進來，最後...軟體能不能快一點？
如果在這些過程中你去抗爭，那就好笑了，馬上被吐，你對自己寫的軟體程式沒信心嗎？
當然沒信心啊，我寫的是微軟系統的軟體，他們都很沒信心的一天到晚Update, 我去哪裡生信心出來？
現在忽然覺得Web-Base真是好，難怪大家都用，老闆們說"改"，馬上所有用戶都改了，不用Update軟件，更不用重新安裝。
反正Win32 AP的工程師真的可以去死一死了，連微軟都不要你們了，快去搞Flex，AJax之類Web-Base 的東西吧，別再留戀Delphi, VB了，EXE還是會在，不過都是多包一層皮的瀏覽器而已。
然而這些小軟體又覺得Web-Base在操作上不如傳統的Application，於是奇奇怪怪的Function就出來了，什麼東西都得上Server去問....
回到AP介面上，又覺得沒有Web-Base那麼靈活，要修改又是一大堆更新程序（廢話，Web-Base只要伺服器程式改一下當然快）
最重要的是Application的程序員得承受軟體正常是應該的，不正常就該死，例如，用戶犯了羊顛瘋，手指會顫抖，然後以超音速惡搞按鈕（Web-Base不會有這種問題，按鈕點下去---你就等吧..按到死都不會有Error），所以AP程序員就必須再寫一套羊顛瘋防制函數。
再來當用戶用超音速點選各個功能鈕，造成AP Crash時，死的也是AP程序員，為什麼人家XXX軟體不會當，我們家軟體就會當（人家XXX工程師月薪是我的五倍，同時是一整個Team在開發...OK!）
永遠只有AP工程師會想到，如果更新了，會產生哪些問題，怎樣避免過於複雜的程序，而大老闆們一天到晚就是，能不能新增這個功能，能不能把那個功能搞進來，最後...軟體能不能快一點？
如果在這些過程中你去抗爭，那就好笑了，馬上被吐，你對自己寫的軟體程式沒信心嗎？
當然沒信心啊，我寫的是微軟系統的軟體，他們都很沒信心的一天到晚Update, 我去哪裡生信心出來？
現在忽然覺得Web-Base真是好，難怪大家都用，老闆們說"改"，馬上所有用戶都改了，不用Update軟件，更不用重新安裝。
反正Win32 AP的工程師真的可以去死一死了，連微軟都不要你們了，快去搞Flex，AJax之類Web-Base 的東西吧，別再留戀Delphi, VB了，EXE還是會在，不過都是多包一層皮的瀏覽器而已。
2009年1月4日 星期日
Flex & Visual Studio
最近買了Flex與Visual Studio For C#兩本書來看，不知道為什麼，我對把程式碼內砍在HTML上的東西總是會感冒，尤其是又得加上JavaScript, CSS等等的，儘管DreamWeaver已經儘量讓這些不同的程式看起來不是那麼難以處理，但終究是沒辦法像Delphi寫Win32那麼的方便，尤其是除錯時更牽涉到了瀏覽器的支援性，想到此，對PHP, ASP等網路應用開發總是興趣缺缺。
我想這些大公司大概也意識到，一個開發員要兼顧所有技術，幾乎是不可能的任務，但WebBase的應用程式又是大勢所趨，本來我是寄望Delphi在Windows上的成就能夠轉移到Web應用上，但看來這不是一獗可至，雖然Delphi也有解決方案，但卻不比目前主流的技術方便到哪裡去。
以前曾用Flash搭配PHP寫過很小型的資料庫應用，那時我就覺得Flash若能把前後端整合起來，變成一個獨立的開發環境，那麼AS的開發員就不用自己去寫什麼接收、輸出XML之類的東西，果然後來Flex就冒出來了，目前僅玩過一遍他的IDE環境，雖然與Delphi, VC那種怪物仍有一大段差距，但就Web應用來說，已經非常足夠了。
至於VC的WPF我也小看了一下，對於C#，稍微翻過大概就知道怎麼寫了，每種物件導向語言其實都差不多，對有C++/Java/Pascal的人來說不難上手，但微軟似乎怎麼也放不開，主力仍舊放在MsSQL, ASP.NET上，相對於Flex後端的自由度來說，讓我有點翻不下去。
兩種開發環境都有自己的優勢，C#秉持著主流語言的模式，吸引其他開發員加入，但在後端的自由度不夠，似乎總是要用微軟的解決方案才能使用。
Adob的AS在物件導向上太過模糊，AS的初學者很容易寫成義大利麵程式，不管是Flash或Flex，他的IDE環境也都沒有VC或Delphi來的強大。
最後比較起來，我還是偏好使用Flex，畢竟在視覺上還是Adobe具有絕對的優勢，只要Adobe的Flash Player夠爭氣，我相信是有拿來做大專案的本錢的。
我想這些大公司大概也意識到，一個開發員要兼顧所有技術，幾乎是不可能的任務，但WebBase的應用程式又是大勢所趨，本來我是寄望Delphi在Windows上的成就能夠轉移到Web應用上，但看來這不是一獗可至，雖然Delphi也有解決方案，但卻不比目前主流的技術方便到哪裡去。
以前曾用Flash搭配PHP寫過很小型的資料庫應用，那時我就覺得Flash若能把前後端整合起來，變成一個獨立的開發環境，那麼AS的開發員就不用自己去寫什麼接收、輸出XML之類的東西，果然後來Flex就冒出來了，目前僅玩過一遍他的IDE環境，雖然與Delphi, VC那種怪物仍有一大段差距，但就Web應用來說，已經非常足夠了。
至於VC的WPF我也小看了一下，對於C#，稍微翻過大概就知道怎麼寫了，每種物件導向語言其實都差不多，對有C++/Java/Pascal的人來說不難上手，但微軟似乎怎麼也放不開，主力仍舊放在MsSQL, ASP.NET上，相對於Flex後端的自由度來說，讓我有點翻不下去。
兩種開發環境都有自己的優勢，C#秉持著主流語言的模式，吸引其他開發員加入，但在後端的自由度不夠，似乎總是要用微軟的解決方案才能使用。
Adob的AS在物件導向上太過模糊，AS的初學者很容易寫成義大利麵程式，不管是Flash或Flex，他的IDE環境也都沒有VC或Delphi來的強大。
最後比較起來，我還是偏好使用Flex，畢竟在視覺上還是Adobe具有絕對的優勢，只要Adobe的Flash Player夠爭氣，我相信是有拿來做大專案的本錢的。
訂閱：
文章 (Atom)
