WTL之父Nenad Stefanovic訪談錄

WTL 參考:http://dev.csdn.net/develop/article/74/74004.shtm

http://www.cnblogs.com/kylindai/archive/2007/11/28/974797.html(WTL8.0 調用 ActiveX 控件)

http://blog.csdn.net/xiangxiangouhongyuan/archive/2007/11/01/1862009.aspx(環境配置)

1.WTL 8.0 SDK下載:http://www.microsoft.com/downloads/thankyou.aspx?familyId=e5ba5ba4-6e6b-462a-b24c-61115e846f0c&displayLang=en
原作者姓名 採訪:myan,翻譯:cber

介紹
每一個,正在使用C++或者準備使用C++的朋友都應該仔細的讀讀這篇文章。

讀者評分 10 評分次數 2

正文
WTL之父Nenad Stefanovic訪談錄
採訪:myan,翻譯:cber
myan引介

作爲現代C++最重要的特色技術,template正在各個傳統領域攻城略地。從基本算法與數據結構,到正則表達式與XML解析,從高性能數學計算,到資源的分配與管理,從網絡分佈式計算環境,到組件模型創建,從靜態多態性的維度擴展,到設計模式的自動生成,神奇的template顯示出其令人歎爲觀止的強勁實力,如果不是有一個隱隱的痛處,template愛好者簡直可以去狂歡了。

這個隱隱的痛處,就是在GUI編程領域。

現有的大部分成熟GUI框架和工具庫,其定型時間都在90年代早期,不管是因爲什麼原因,總之我們根本看不到template技術在這些環境中的任何重要運用。無論是專有MFC和OWL,還是開源的wxWindow和Mozilla, 以至於是專有還是開源都說不清楚的Qt,它們在其他方面有着諸多不同,偏偏倒是在對待模板技術上空前一致:嚴格限制在底層的數據結構領域內,抵制模板技術流入GUI主體結構。最過分的wxWindow和Mozilla,在代碼編寫規範裏嚴厲禁止使用1990年之後發展出來的任何C++特性,模板、異常、多繼承、STL等等,均在黑名單上。諸位有興趣,不妨去看看,那與其說是一份C++代碼編寫規範,倒不如說是對C++現代特性在GUI領域應用的一份不公正的判決書。

難道模板技術真的在GUI領域無用武之地嗎?

WTL給出了一個響亮的回答。

WTL是微軟ATL開發組成員Nenad Stefanovic先生在ATL Windowing機制上發展起來的一整套GUI框架,運用template技術組織和創建GUI對象,構築了精緻的面向對象框架(沒錯,在這裏object oriented與template達成了精緻的融合)。雖然沒有獲得微軟的官方支持,雖然其使用者人數很少,但是確實是“用過的都說好”,有位微軟MVP人士甚至說,這是微軟有史以來推出的最優秀的一個framework。真是一個有趣的諷刺,最好的東西居然不被官方支持。有關於WTL的流言不少,比如這東西原本是微軟內部專用,只是因爲不小心才被泄漏出來等等,這更加劇它的神祕色彩。相信大家對它一定有不少問題。我們特別邀請到了WTL之父Nenad Stefanovic先生,進行了一次網上的訪談,希望能幫助大家瞭解WTL的真面目。

【C++ View】:I think most of our readers are not very familiar with you, so would you please tell us your story here? We are very fond of that. What do you think about China and Chinese people?

【C++ View】:我想,可能我們的讀者中有很多人對您還不是很熟悉,您能不能在此給我們簡單介紹一下您自己呢?我們將非常樂意聽到您的自述。還有,您能不能也對我們講述一下您對於中國以及中國人民的基本看法呢?

【Nenad】: I am a software developer at Microsoft. Your readers will probably know me as a creator of Windows Template Library, WTL. I am from former Yugoslavia, where I finished school and started working on software development. I've been living in US for 10 years now.

I am intrigued and impressed by the Chinese culture and tradition. I think that China is now in a great position of progress as a country and a nation. I discovered that, being from former Yugoslavia, I already know many things about China, and getting to know people from China gave me a bit of the "everyday" life perspective as well. I'd like to learn more, so I hope to visit China one day.

【Nenad】:好的。我現在在Microsoft工作,是它裏面的一個軟件開發人員。你們雜誌的讀者中可能有人知道,我就是Windows Template Library (WTL)的創作者。我來自於前南斯拉夫,在那我完成了我的學業並開始了我作爲軟件開發人員的工作生涯。現在,我在美國居住的時間已經超過了10年了。

中國的文化以及傳統給我留下了極爲深刻的印象,我對此十分感興趣。我想,作爲一個國家以及民族,中國已經處於一個偉大並且不斷在成長中的位置上。作爲一個從前南斯拉夫來的人,我早就瞭解到關於中國的很多事情。在與來自中國的人民的接觸過程中,我還瞭解到了你們日常生活的一些狀況。我還想了解更多(有關中國的事情),希望有一天我可以到中國來遊覽。

【C++ View】:When and why did you first think about WTL? What's its original purpose? How do you see its future?

【C++ View】:您是什麼時候開始想起要開發WTL呢?爲什麼?您在開發它時的最初目的是什麼?您又是如何地看待它未來的發展呢?

【Nenad】:WTL was born while I was working on ATL (Active Template Library). We were extending ATL to support ActiveX controls, and I was working on the windowing support. I started thinking that the same techniques can be applied to much broader windowing support, for the much richer UI for controls, components, and also applications. So, WTL was created as a part of ATL that would extend ATL to support any kind of UI related component or application. It did not ship with ATL in Visual Studio, however, so I decided to ship it as a standalone library that extends ATL.

I think that WTL will continue to be a great option for developers writing Windows applications and components. I don't see big changes or additions to WTL, because one of the design principles for WTL was to follow the Win32 UI API and design. It will continue to do so.

【Nenad】:WTL是我在從事ATL (Active Template Library)開發工作時的產物。那時我們正在擴展ATL,使之得以支持ActiveX control,而我負責的就是其中對於窗口機制部分的支持。這時,我就開始想,是不是可以把同樣的技術應用到更爲廣泛的窗口機制中,以獲得更豐富的UI控制、組件、以至於應用程序呢?於是,作爲ATL的一部分,WTL被開發出來了。它將ATL進行了擴展,以使得它可以支持各種類型的與UI相關的組件或者應用程序。然而,它並沒有隨着ATL一同集成在Visual Studio中被髮布,於是我就決定將它作爲一個單獨的ATL擴展庫發佈出去。

我認爲WTL將一直是那些在Windows下開發應用程序以及組件的開發者的一個很好的選擇。我並不認爲在以後,我們會對WTL有一個大的改動(或者增添),因爲WTL的一個設計宗旨就是“遵循Win32 UI的API及其設計”。現在如此,將來還是會如此下去。

【C++ View】:I first heard about WTL in July, 2000. At that time, I thought: "No official support, no documentation, no commercial hype, it will die in 6 months." Now, fifteen months passed, it spreads wider and be more vigorous. Lots of C++ programmers, esp. the ones we regard them as "gurus and masters" involved in WTL. I know it's surely because WTL is a wonderful library, but it must be more than a wonderful library to gain such attentions without official force.What do you think WTL's relative success? What's the reason?

【C++ View】:我第一次接觸WTL是在2000年7月。在那時,我就想:“沒有官方的支持,沒有文檔,也沒有商業吹捧,它最多隻能夠存活6個月。”但現在15個月過去了,它反而流傳得更爲廣泛,更加的生機勃勃。許多C++程序員,尤其是一些我們所認知的“專家”以及“大師”,都在使用WTL。我當然知道這主要是因爲WTL的出色,但我想,能夠在沒有官方的力量牽涉的情況下吸引如此多的注意,WTL一定還有更出色的東西,請問您是如何看待WTL的成功呢?它成功的原因又是什麼?

【Nenad】: I think that the main reason of WTL's success is that it did fit the need of developers at the right time. More and more developers started using ATL, and it was natural for them to start using WTL when they needed more UI support. It seems that WTL was perceived as a more open project than others, judging by the support provided by other parties in the development community. Many people did a wonderful job of creating samples, documentation and support for WTL. The support from the programming community is very important part of the acceptance and success of WTL.

【Nenad】:我認爲WTL成功的最主要原因就是,它確實而且及時地滿足了開發者的需求。越來越多的開發人員開始使用ATL,當他們需要更多的UI支持時,他們很自然的就會開始使用WTL。 從其他的開發團隊所提供支持來看,WTL看起來似乎要比其他的項目更加開放。許許多多人爲WTL做了大量工作,如:創建示例代碼,撰寫文檔等。WTL之所以能夠被廣爲接受並獲得如此大的成功,來自於這些開發團隊的支持絕對是一個重要的因素。

【C++ View】:What do you think about MFC? Do you like it? If you don't, why? And the most confusing thing is Managed C++, is it C++? Do the leaders of MC++ really think some C++ users will go to learn it? Do you believe?

【C++ View】:請問您對於MFC是怎麼看的?您喜歡它嗎?如果不,爲什麼呢?還有,最讓人迷惑不解的就是Managed C++了,它是不是C++呢?MC++的提倡者是不是真的認爲會有一些C++的用戶轉而去學習它呢?您的看法又是如何呢?

【Nenad】: I think that MFC is a great framework library. Don't forget that MFC was designed at the time that C++ compiler was rather limited, and the main platform was 16-bit Windows. Unfortunately, because MFC was designed as a framework, it was really hard to evolve it to use better C++ support in newer compilers, and to add support for new features added to Windows in the meantime. What I don't like about MFC is the DLL approach, which causes many compatibility problems, and framework design, which dictates too many things about app design.

Managed C++ is an extension to C++ which allows C++ programs to use managed code. It is very important to understand that you can compile your existing C++ code using MC++ without any changes. MC++ allows developers to use both familiar non-managed C++ and managed code in the same module. That provides an excellent way to extend existing code to interact with managed code, as well to create new projects that can use both managed and traditional C++.

【Nenad】:我認爲MFC是一個了不起的框架庫。請不要忘了,在MFC被設計出來初期,那時的C++編譯器還具有很多的限制,並且那時主要的平臺還只是16位的Windows。不幸的是,由於MFC被設計成爲一個框架,使得我們很難利用新編譯器中那些更好的C++特性來改進它,也很難將Windows中的很多新特性添加到MFC中。我不喜歡MFC的地方是它高度依賴DLL的特性——因爲它將導致許多兼容性方面的問題;還有就是MFC的整個框架設計——它在應用程序的設計中限定了太多東西。

Managed C++是C++的一個擴展,它允許C++程序得以使用受管(managed)代碼。我們需要了解的一個很重要的特性就是,我們可以使用MC++來編譯已有的C++代碼而無需對它們進行任何改動。MC++允許開發者同時使用他們所熟悉的非受管代碼以及受管代碼來開發同一個模塊。這就提供了一個非常好的途徑,使已有的代碼與新的受管代碼相互作用,並也可使得我們創建一個項目,同時使用受管的和傳統的C++代碼。

【C++ View】:In the past 15 years or more, C and C++ is the base of almost all Microsoft's technologies(OS, COM, etc.). We C++ user paid a lot of hard work to catch them, because we felt what we paid was worthy(?). Now, it seems the climate changed. .NET is coming, the world is going to be full of CLRs and/or JVMs. There has been a decampment from C++. So what do you think about the future of C++ (not MC++) in Mircosoft technologies? Will it go away? Will it become a marginal language?

【C++ View】:在過去的15年中(甚至更長的一段時間內),C以及C++構成了幾乎所有Microsoft技術的基礎(如:OS,COM等)。我們這些C++用戶花費了大量的時間來熟悉並掌握它們(C以及C++),因爲我們相信我們所付出的一定會有回報(?)。但現在的風向好像有了很大的改變。.NET出現了,世界似乎就要充斥CLR (Common Language Runtime,公共語言運行庫)以及/或JVM (Java Virtual Machine,Java虛擬機)。現在C++已經出現了退潮的跡象。那麼,請問您對於C++(不是MC++)在Microsoft技術中的前景如何看待?它是否會由此消亡?還是就此淪落爲一門邊緣語言?

【Nenad】:Well, the world is changing too. The new type of development for Web services and connected applications is on the horizon. I think that new languages, like Java, C#, and VB.NET, were developed to address two main issues - to simplify software development and to provide better support for Internet development. Simplifying software development allows more developers to write good applications and cuts down on time needed to finish a project. Supporting Internet development is obviously very important in this time when Internet is used more and more in every part of everyday life.

I think that C++ will continue to be an important language, especially for ISV's and for system development. On the other hand, I believe that .NET will be very important platform soon. .NET has the potential to be the main programming platform for the future, but it is reasonable to expect that the transition will take some time.

【Nenad】:是的,世界也已經發生了變化。對於網絡服務以及連接這樣的新型應用程序的開發已經浮上了水面。我認爲那些新的編程語言(如Java,C#,以及VB.NET)都是針對以下兩個主要的問題而開發出來的——簡化軟件的開發過程以及對於Internet應用程序開發提供更好的的支持。簡化軟件的開發過程使得更多的開發者可以寫出更多更好的應用程序並減少完成開發項目所需要的時間。而支持Internet的開發,對於這個Internet越來越深入到我們的日常生活中的時代來說,毫無疑問是一件非常重要的事情。

我認爲C++會繼續作爲一門重要的編程語言發揮作用,尤其是對那些獨立軟件開發商和那些系統級開發來說更是如此。從另一方面來說,我相信.NET將會在不久以後成爲另外一個非常重要的開發平臺。對於未來來說,.NET擁有成爲主流編程平臺的潛力,但我們必須認識到,這樣的過渡階段肯定要持續一段時間。

【C++ View】:There a lots of beginners in our readers, after they learn (standard) C++, they want to seek a path to master enought Microsoft technologies to be practical and proficient programmers. Could you recommend such a path? Should they learn Win32 API programming? Is it worthy of studying MFC? Is WTL/ATL/STL a reliable solution? Or goto C# directly? Many many people will thank you if you give them frank advice.

【C++ View】:我們的讀者中有很多是初學者,在他們學習完(標準)C++後,他們希望能夠找到一條道路,掌握到足夠多的Microsoft的技術使自己成爲經驗豐富的、熟練的程序員。您能不能給我們指出這樣的一條道路來呢?我們是不是應該學習Win32 API編程?學習MFC是否是值得的?WTL/ATL/STL算得上是一個可靠的解決方案嗎?又或是我們應該直接學習C#?如果您能夠給我們一些建議,相信會有很多的人爲此而感激您的。

【Nenad】:I think that depends on their plans and ambitions. The more of those things you do, the better you are off in the long run. But, you also have to balance that with the practical issues. So, I think that people who see their future in the Internet development can go directly to C# or VB.NET, and study .NET platform. Those who would like to have more knowledge of the Windows platform and services it provides should certainly learn more about Win32 API and libraries that support Windows programming.

【Nenad】:我認爲這主要取決於他們的計劃以及雄心。你所做的越多,在長時間競爭中你就越佔據優勢。不過你也要注意保持與實際問題的平衡。我建議那些決心以後只做Internet相關開發的人可以直接去學習C#或者VB.NET,同時學習.NET平臺。而那些更多地瞭解Windows平臺以及它所提供的服務方面知識的人,當然就必須需要更多地瞭解有關Win32 API以及那些支持Windows編程的庫相關的知識。

【C++ View】:Soon after I began to learn WTL, a warm-hearted man posted me a email. He wrote: "You won't be a good WTL programmer if not a good ATL programmer, you won't be a good ATL programmer if not a COM programmer. And once you decide to learn COM, you are beginning your travel to hell." Is COM so difficult to learn? How to study WTL? We must learn API, COM, ATL and WTL in sequence, do we? And what about COM, will it remain to be the core technology of Microsoft, or just be substituted by .NET and dismiss?

【C++ View】:在我剛開始學習WTL後不久,有一位熱心人給我發了份郵件。他寫道:“如果你不是一個好的ATL程序員的話,你就不可能成爲一個好的WTL程序員;如果你不會COM編程的話,你就不可能成爲一個好的ATL程序員;但一旦你決定開始學習COM,你就邁出了踏向地獄的第一步。”COM是不是真的那麼難學?我們應該如何地來學習WTL呢?我們是不是應該按照這樣的順序學下來呢,API->COM->ATL->WTL?還有,COM將會變得如何?他是不是還能夠保持Microsoft的核心技術這一頭銜,抑或是被.NET給替換掉然後就此消失?

【Nenad】:I don't think it is necessary to master COM to use and understand WTL. Win32 UI knowledge is more important than COM to understand WTL. But it is true that knowledge of ATL is required, and ATL mainly supports COM. So, COM knowledge is desirable, but not required.

I don't think that COM is hell, but it sure does require a lot to learn to be an expert. Keep in mind that many people don't have to be COM experts to use COM, or to use WTL. Just understanding basic principles of COM is enough to use it, and then people can learn more when needed.

【Nenad】:我不認爲使用和理解WTL就一定要掌握COM。相比於COM來說,Win32 UI的知識對於理解WTL顯得更爲重要。但毫無疑問的是,ATL的相關知識是必不可少的。由於ATL主要任務就是支持COM,所以,有COM的知識只是會更好一些而已,但它們並不是必需的。

我也不認爲COM是一個噩夢,但毫無疑問的是,想要成爲一個COM專家,要學的東西實在是太多了。但請記住一件事情,很多使用COM或者WTL的人並不都是COM方面的專家。要想使用它們,人們所需瞭解的只是一些COM的基本原理就夠了,其他的相關的知識則可以在需要時再去學習。

【C++ View】:What do you think about Generic Programming? Is it a whole different paradigm from OOP, or just OOP's supplemental facility? Can we combine GP and OOP? In the hard work of design and implement WTL, you must had got an insight about the relationship between OOP and GP, what's it?

【C++ View】:請問您對於泛型程序設計是如何看待的?它到底是OOP的一個補充呢,還是完全不同於OOP的另外一個程序設計範型呢?我們是否可以將GP以及OOP一同聯合使用?我想,在設計和實作出WTL的艱苦過程中,對於OOP以及GP之間的關係,您一定有了自己的看法,您能不能給我們說一下呢?

【Nenad】:Generic Programming and OOP are very different, mostly because Generic Programming doesn't explicitly express relationships between design elements. They can, however, be used together very efficiently.

WTL uses a combination of Generic Programming and OOP design. Templates are mostly used to implement traditional OOP classes. I'd like to point out that WTL doesn't use any "pure" design, and it doesn't strictly follow any design guidelines or styles. I do think, though, that WTL does use one of the main strengths of the C++ language - it uses appropriate paradigm that is the most suitable for a particular problem.

【Nenad】:GP和OOP非常不同,這主要是由於GP從不顯式地表達出設計元素之間的關聯來。然而,它們也可以被非常高效地組合運用。

WTL中使用了一種GP連同OOP的設計。我在其中大量使用了模板來實作出傳統的OOP中的類。我很樂意指出的是,WTL中並沒有使用一種“純”設計,它也沒有遵循任何的設計指導方針或者設計規格。可是,我還是認爲WTL使用到了C++語言中的最主要的精髓處——對於一個特定的問題使用一種最適合它的適當典範。

【C++ View】:Recently, the famous C++ pioneer Stanley Lippman joined Microsoft and became a member of Visual C++.NET group. How do you think about this? What message do you think your company like to pass to public? Does this mean Microsoft want to make VC.NET a full-standardized C++ compiler and hold C++ as your core system language?

【C++ View】:最近,著名的C++元老級大師Stanley Lippman加入了Microsoft併成爲其VC.NET開發小組中的一員。請問您對於此事是如何看待的?您認爲Microsoft試圖向公衆傳播一種什麼樣的信息呢?這是否也意味着Microsoft希望VC.NET成爲一個完全標準化的C++編譯器,並繼續保持C++的核心繫統語言地位呢?

【Nenad】:I think that shows that Microsoft is committed to advance the C++ compiler and language, and ready to get the best people to help. I am sure that VC++.NET will continue to be powerful tool for developing applications, and that it will also include additional capabilities for the .NET development. Compliance with the C++ Standard is an ongoing work, and we will see further improvements there, too.

【Nenad】:我認爲這顯示了Microsoft對於促進C++編譯器以及語言繼續發展的決心,併爲此找到了最佳人選來獲取幫助。我確信VC.NET將會繼續是開發應用程序的強有力工具,並且它同時還將包含有.NET開發能力。目前我們正在進行兼容C++標準方面的工作,不久我們就會看到成效。

【C++ View】:I'm learning WTL and ATL, since you are the author of WTL and a member of ATL group, can you give me some advice?

【C++ View】:我現在正在學習WTL以及ATL,既然您是WTL的作者,同時又是ATL開發小組中的一員,您能不能給我一些建議呢?

【Nenad】:There are several areas of programming that are very important for WTL and ATL: knowledge of the C++ language in general, understanding of templates, COM for ATL, and Windows UI programming for WTL. Solid knowledge in these areas is very beneficial for WTL and ATL developers, and it also helps to understand the source code for both libraries.

I would also like to encourage everybody to write programs. That is the best way to learn how to use any library, or a programming language or operating system. Writing programs often brings problems that must be solved that are not addressed in books. Reading about something is very useful to start learning, writing programs is the best next step.

【Nenad】:對於WTL和ATL來說,有好幾個編程方面的領域是十分重要的:大體上的C++語言知識,瞭解模板,COM(對ATL而言),以及Windows UI編程(對WTL而言)。在這些領域有着堅實的基礎對於WTL以及ATL開發人員來說有着很大的好處,同時對於理解這兩個的源代碼也能夠起到幫助作用。

我同樣也很樂意去鼓勵大家多寫程序。這也是學習如何使用一個程序庫,或者一門編程語言,或者一個操作系統的一個最好的方法。在寫程序的過程中經常會出現一些書本上沒有提及但又必須被解決的問題。在開始學習時讀一些東西是很有用的,而寫程序則是向縱深發展的最佳方式。

【C++ View】:They say we are in the gate of Post-PC times, it will be a embedded world, and there will be embedded smart device everywhere, and the embedded industry will build a far large market compare to PC's. Do you believe it? Do you think WTL and other C++ template libraries are available and appropriate for embedded development? Are there available for Internet development?

【C++ View】:有人說,我們現在已經處於後PC時代的門口,未來將會是一個嵌入系統的世界,嵌入式的智能設備將會無所不在,並且對比PC來說,嵌入系統的產業將會是一個更大的市場。您是否相信這些呢?您是否認爲WTL以及其他的一些C++模板庫對於嵌入式開發也適用呢?它們是否適合Internet開發?

【Nenad】:Yes, I think that large number of various devices that we use everyday will become small, specialized computers. That doesn't mean that the number and importance of PCs will go down, just that there are many other devices that will be enhanced to be programmable and connected. Those new devices will provide a great opportunity for software developers, because they will all have software and somebody has to write it.

Many of the C++ libraries are quite appropriate for embedded development, and WTL would also be in cases where Windows based user interface is important (for example, Pocket PC platform). Great flexibility and small footprint are always very important features for embedded development, so template libraries are in the very good position there.

【Nenad】:是的,我認爲我們現今所使用的各種設備中的大部分在以後都將會演變成爲一些小的,具有專門用途的計算機。但這並不意味着PC的數目以及重要性將會由此降低,只不過是表明還有着許多其他的設備需要被加強以使得我們可以對其進行編程並且連接。由於必須需要有軟件的支持,而軟件又需要有人來寫,這些新的設備將會給軟件開發人員帶來極大的機遇。

有許多的C++函數庫都可用於嵌入系統的開發,WTL也將會在那些Windows用戶界面較爲重要的開發中(例如,在Pocket PC平臺上面開發)佔有一席之地。對於嵌入式開發來說,良好的彈性,微小的內存耗用永遠都會是很重要的特性,而模板庫在這方面佔據了一個非常好的地位。

【C++ View】:In the past 7 years or more, COM is Microsoft's core technology. And we now can see that in the next decade, the core role may be .NET. My question is, what's wrong with COM? Where will COM be? Will it disappear? Will it be substituted by something else? What's the relationship between COM and .NET? Is .NET based on COM? Is it worthy of learning COM now?

【C++ View】:在過去的7年(甚至更長的一段時間)內,COM都是Microsoft中的核心技術。現在我們可以預見到,在下一個十年間,這個核心將會變爲.NET。我的問題就是,COM有什麼過錯?COM將何去何從?它是否會逐漸消失呢,還是會被其他的一些技術給替代?COM和.NET之間的關係是什麼樣的情況?.NET是否是基於COM之上呢?現在學習COM是不是還值得?

【Nenad】:Maybe you shouldn't ask what is wrong with COM, but just think of .NET as the evolution of COM. .NET extends what was started with COM- creating reusable binary components - and brings additional important features: rich metadata, great run-time, built-in security, versioning, etc. All of these new features are important for development today, and it is really great that .NET has extensive support for them. Interoperability between .NET and COM is also provided, so that the previously developed COM components can still be used in the .NET environment.

I still think that it is a good idea to learn COM - it is a great first step even for people who want to learn .NET, and it also provides better understanding of the design and implementation of .NET itself.

【Nenad】:或許你不應該問COM有什麼過錯,而是應該把.NET看成COM的進化。.NET擴展了COM最初的目的——創建可重用的二進制程序組件——並向其中添加了很多重要的特性:豐富的元數據,了不起的運行庫,內建的安全機制,版本機制等。對於現今的軟件開發來說,所有的這些新的特性都非常重要,所以.NET能夠廣泛地支持它們,是一件很偉大的產品。Microsoft同時也提供了在.NET和COM之間進行互操作的能力,這使得以前所開發出來的COM組件在.NET環境中同樣也能夠得到使用。

我仍然認爲學習COM是一個很好的主意——它甚至對於那些希望學習.NET的人們來說也是一個很好的開端,學習COM同時也有助於我們更深入地理解 .NET本身的設計和實現。

【C++ View】:I know you must be a C++ fan. Now the language is facing lots of challenges. To counterattack, Dr. Stroustrup suggest to develop many useful libraries, and teach the programmers to use C++ as a high level language. Now there are several wonderful modern C++ libraries. Aside of ATL, WTL and STL, there are still Boost library, MTL, ACE/TAO, DTL, etc. It seems the C++ community is preparing a movement. Do you think the movement will success? Why? What are your colleagues'(in Microsoft VC.NET group) attitude towards such a movement?

【C++ View】:我猜想您肯定是一個C++愛好者。現在這門語言面對着許多的挑戰。作爲反擊措施,Stroustrup博士提議開發許多有用的庫,並引導C++程序員把C++當作一門高級語言來使用。現在我們已經可以得到好幾個極好的現代的C++庫,除去ATL、WTL以及STL之外,還有Boost庫、MTL、ACE/TAO、DTL等。一切都顯示着C++社區正在醞釀着一次變革。請問您覺得這場變革能否成功?爲什麼?您的那些Microsoft中的VC.NET開發小組中的同事對於此態度是怎樣的?

【Nenad】:C++ is a great language and its importance remains high, even with the new challenges. Libraries are an excellent addition to the language itself, as they provide very useful reusable code for developers. The existence of many great C++ libraries shows the size and strength of the C++ community. I think that is already a success, and that it will continue. You can be sure that the VC++.NET group is aware of the existing libraries, and I expect them to continue to enhance the support for them.

【Nenad】:C++是一門偉大的語言,即便遇到了新的挑戰,它仍然將是非常重要的。程序庫對於語言本身是極好的補充,它們爲開發者提供了一些十分有用的可重用代碼。存在如此衆多的、了不起C++程序庫,這件事情本身就表明了C++社區的龐大和強大。我認爲這場變革已經成功了,並且會一直成功下去。你們可以放心,VC.NET開發組是不會對這些已有的程序庫熟視無睹的,我預期他們會不斷地加強對於這些庫的支持。

【C++ View】:The last question. Since lots of people don’t acquaint themselves with WTL, now we have a chance for you, the father of WTL, to introduce WTL in a short speech here. What would you like to speak?

【C++ View】:最後一個問題。既然許多人並不瞭解WTL,作爲WTL之父,您現在有機會在這裏做一個演講,請簡短地介紹一下WTL。

【Nenad】:WTL is a template based library for user interface development. It extends ATL to provide classes for implementing user interface for applications, components, and controls. It provides classes for various user interface elements: top-level windows, MDI, standard and common controls, common dialogs, property sheets and pages, GDI objects, UI updating, scrollable windows, splitter windows, command bars, etc.

WTL is implemented using the same template architecture as ATL, so it is a natural fit for ATL developers. It also doesn't alter or hide Windows specific constructs, thus allowing Windows programmers to use WTL without surprises. The important design goal of WTL was to avoid inter-dependencies - classes themselves do not reference other WTL classes. That means that your program will contain just the code that you actually use, and nothing else. Coupled with the use of templates, this allows creation of very small programs without run-time dependencies.

WTL delivers the object oriented way to program for the Windows user interface, while keeping the code size small. It also provides a great foundation that developers can extend with their own classes.

And finally - WTL was written with a hope that developers will enjoy using it. I hope you will use it and enjoy it, too.

WTL是一個基於模板的、專爲開發用戶界面的程序庫。它擴展了ATL,並提供了一些類用來實現應用程序的用戶界面、組件和控件。它提供了各種類來支持各種各樣的用戶界面元素:頂級窗口、MDI、標準控件和通用控件、通用的對話框、屬性表以及屬性頁、GDI對象、UI更新、可捲動的窗口、分割窗口、命令條等等……

WTL的實現使用了和ATL一樣的模板架構,所以對於ATL開發者顯得很自然。同時它並沒有改變或者是隱藏那些Windows相關結構,那些Windows程序員在使用WTL時也不會感到很吃驚。WTL的一個主要設計原則就是避免在沒有引用到其他WTL類時,出現不必要的內部依賴。這意味着我們的程序將只包含有我們實際上所使用的代碼,除此之外再無其他的東西。加上了模板的使用後,這樣做得到的結果就是一些非常小的,不依賴於運行庫的程序。

WTL專注於用面向對象的方法來編寫Windows的用戶界面程序,同時保持代碼的尺寸很小。同時,它也爲開發者提供了一個很好的基礎,可以寫新的類來擴展WTL。

最後,我在編寫WTL時就希望開發者能夠喜歡在開發中使用它。我同樣也希望您能夠使用它並喜歡上它。

正文完

WTL疑點分析

1.配置WLT環境後,打開smaple中的例子 調試的的時候發現有編譯錯誤:
用VS2005新建一個WTL   dialog工程,建好後直接變異會出現下面這2個錯誤,是什麼原因,如何解決?
CVTRES   :   fatal   error   CVT1100:   duplicate   resource.     type:MANIFEST,   name:1,   language:0x0409
LINK   :   fatal   error   LNK1123:   failure   during   conversion   to   COFF:   file   invalid   or   corrupt
解決辦法:找到工程對應的rc文件,將
CREATEPROCESS_MANIFEST_RESOURCE_ID   RT_MANIFEST
這句注視掉即可.
CREATEPROCESS_MANIFEST_RESOURCE_ID       RT_MANIFEST

這個語句有2個地方,一個是
BEGIN
        "CREATEPROCESS_MANIFEST_RESOURCE_ID   RT_MANIFEST   ""res////WTLClock2.exe.manifest""/r/n"
        "/0"
END
另外一個地方是:
CREATEPROCESS_MANIFEST_RESOURCE_ID   RT_MANIFEST   "res//WTLClock2.exe.manifest"


我註釋掉第二句就可以了,
但是其實我還不是很明白意思
我只是知道這麼做可以通過
而且我自己新建的工程不會有這個問題,我用的是   WTL8+Vista,拿別人的Sample   Code會出現這個問題
具體可以參考http://www.polsnet.com/home/html/tech171_189899.html
2.MSG_WM_TIMER(OnTimer) 編譯報錯:e:/program files/wtl80/wtlproject/wtl sample from mike/wtl4mfc2_demo/wtlclock/wtlclockview.h(26) : error C2660: 'CWTLClockView::OnTimer' : function does not take 1 arguments
 void OnTimer ( UINT uTimerID/*, TIMERPROC pTimerProc*/ )屏蔽掉第2個參數就可以了估計版本不一樣吧。高版本的爲1個參數了。

http://flipcode.spaces.live.com/blog/cns!8e578e7901a88369!932.entry
http://www.cnblogs.com/cxun/archive/2007/07/10/731470.html

2.關於WTL插入對話框資源後如何新建類的問題
自己通過添加C++類然後,
class CUrlDlg :
 public CStdDialogResizeImpl<CUrlDlg>,
 public CWinDataExchange<CUrlDlg>

{
public:
 ///CUrlDlg(void);
 //~CUrlDlg(void);
 enum { IDD = IDD_URL };
 BEGIN_MSG_MAP(CUrlDlg)
  CHAIN_MSG_MAP(CStdDialogResizeImpl<CUrlDlg>)
 END_MSG_MAP() 
};
像這樣子。
編譯後出現問題:
------ Build started: Project: MoibleIE, Configuration: Debug Windows Mobile 5.0 Pocket PC SDK (ARMV4I) ------
Compiling...
UrlDlg.cpp
E:/Program Files/WTL80/include/atlframe.h(3121) : error C2039: 'GetDlgResizeMap' : is not a member of 'CUrlDlg'
        c:/documents and settings/administrator.microsof-4e75bb/桌面/moibleie/moibleie/UrlDlg.h(9) : see declaration of 'CUrlDlg'
        E:/Program Files/WTL80/include/atlframe.h(3028) : while compiling class template member function 'void WTL::CDialogResize<T>::DlgResize_Init(bool,bool,DWORD)'
        with
        [
            T=CUrlDlg
        ]
        E:/Program Files/WTL80/include/atlwince.h(669) : see reference to class template instantiation 'WTL::CDialogResize<T>' being compiled
        with
        [
            T=CUrlDlg
        ]
        E:/Program Files/WTL80/include/atlwince.h(704) : see reference to class template instantiation 'WTL::CStdDialogResizeImplBase<T,t_shidiFlags,t_bModal>' being compiled
        with
        [
            T=CUrlDlg,
            t_shidiFlags=13,
            t_bModal=true
        ]
        c:/documents and settings/administrator.microsof-4e75bb/桌面/moibleie/moibleie/UrlDlg.h(10) : see reference to class template instantiation 'WTL::CStdDialogResizeImpl<T>' being compiled
        with
        [
            T=CUrlDlg
        ]
Build log was saved at "file://c:/Documents and Settings/Administrator.MICROSOF-4E75BB/桌面/MoibleIE/MoibleIE/Windows Mobile 5.0 Pocket PC SDK (ARMV4I)/Debug/BuildLog.htm"
MoibleIE - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

經過分析發現加上下面的映射宏
 BEGIN_DLGRESIZE_MAP(CUrlDlg)

    END_DLGRESIZE_MAP()
發現問題就解決了,編譯成功了。

然後這個時候我們跑到對話框上去看一下 用鼠標點右鍵發現可以添加變量了 這個時候說明我們的類建立成功了。
那爲什麼我們自己手動的建立的類能夠跟我們的對話框對應起來了。
其中enum { IDD = IDD_URL };纔是真正的罪魁禍首,IDD_URL這裏是你插入的對話框的ID,通過這個就可以對應起來。
也許你不信這樣一些就可以了嗎?不過的確是這樣。不信的話,你可以把這個enum註釋掉,然後再去重新rebuild下,發現雖然沒有錯誤
但是,跑到對話框上去的時候發現不能添加變量。所以敢肯定這個的確是這麼回事!

然後我們可以通過
FSDoModal(窗口對象)這樣就可以打開我們所創建的窗口了。
然後這個時候我們需要對窗口進行初始化。比如我們可以插入菜單之類的東東。
頭文件:
BEGIN_MSG_MAP(CUrlDlg)
  MESSAGE_HANDLER(WM_INITDIALOG,OnInitDialog)
  CHAIN_MSG_MAP(CStdDialogResizeImpl<CUrlDlg>)
 END_MSG_MAP()

   LRESULT OnInitDialog(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
實現文件:
然後我們需要完LRESULT成OnInitDialog()的編寫.
LRESULT CUrlDlg::OnInitDialog(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled)
{            //這裏可以添加自己想添加的初始化代碼
 return bHandled = FALSE;
}

這裏有點體會:關於複製別人的菜單問題。比如copy menu到自己的資源的時候發現壓根兒不能paste,最好只好自己直接插入菜單,命個一樣ID的名字,然後在把別人的菜單最上面那個menucopy過來paste上去發現整個都貼上上去了,今天才發現的。偷懶的做法。

然後初始化部分插入菜單:
CreateMenuBar(IDM_EDIT);
這個時候運行下發現出錯誤了:Line:172 ::SHCreateMenuBar(&mbi)!=0 這樣的Debug Assertion Failed。
進一步分析:我們需要在.rc2文件裏面加入
IDM_EDIT SHMENUBAR DISCARDABLE
BEGIN
    IDM_EDIT, 2,
    I_IMAGENONE, ID_MENU_OK, TBSTATE_ENABLED, TBSTYLE_AUTOSIZE, ID_MENU_OK, 0, NOMENU,
    I_IMAGENONE, ID_MENU, TBSTATE_ENABLED, TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE, ID_MENU, 0, 0,
END
這個就可以成功插入我們的菜單了 ok,繼續吧。IDM_EDIT 我們自己的菜單ID。

3.WTL中可以通過宏進行設置edit控件自動調節大小。
 BEGIN_DLGRESIZE_MAP(CUrlDlg)
  DLGRESIZE_CONTROL(IDC_EDIT_URL, DLSZ_SIZE_X | DLSZ_SIZE_Y)
    END_DLGRESIZE_MAP()
其中。IDC_EDIT_URL 是編輯控件的ID
其中DLSZ_SIZE_X 表示以右對齊的意思。同理DLSZ_SIZE_Y以底部對齊
這個編輯控件位於我們剛剛插入的對話框上面。無論我們怎麼樣在編輯的時候弄成什麼樣子,該控件都會根據窗口大小而自動調整。
不過,有點要注意的是,你的控件Y或X位置的不能太靠近對話框的邊緣,否則會出現被覆蓋的問題。至少要保留默認距離。
4.WTL關於IDR_MAINFRAME菜單的修改
如果該菜單需要分版本的話,比如SP 或PPC菜單需要設置成不一樣
我們也可以採用預編譯的方式來做

ATL_IDW_MENU_BAR SHMENUBAR 
BEGIN
#ifdef WIN32_PLATFORM_PSPC
 IDM_MAINFRAME_PPC,//以前系統這裏是IDR_MAINFRAME 其實這個與類裏面那個IDR_MAINFRAME沒有什麼關係,這裏本身就//只是一個系統菜單而已。
#else
 IDM_MAINFRAME_SP,
#endif
 2,
    I_IMAGENONE, ID_ACTION, TBSTATE_ENABLED, TBSTYLE_AUTOSIZE, ID_ACTION, 0, NOMENU,
    I_IMAGENONE, ID_MENU, TBSTATE_ENABLED, TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE, ID_MENU, 0, 0,
END

其中我們這需要在PPC sdk進行設置:Resouces->General ->Preprocessor Definitions ->WIN32_PLATFORM_PSPC(添加該宏,其中這裏的宏可以是自己隨便定義的我們這裏順便就直接使用系統自己的宏了),這樣就可以選擇性的加入菜單。IDR_MAINFRAME了其他地方不需要做任何修改。

4.調試WTL中的MTPadCE,出現link錯誤:MTPad.obj : error LNK2019: unresolved external symbol GetOpenFileNameEx referenced in function "public: int __cdecl WTL::CFileDialogImpl<class WTL::CFileDialog>::DoModal(struct HWND__ *)" (?DoModal@?$CFileDialogImpl@VCFileDialog@WTL@@@WTL@@QAAHPAUHWND__@@@Z)

解決方法是在頭文件中加入 comment(lib,"aygshell.lib")便可以解決了。

5.編譯GuidGenCE 的時候出現的錯誤:E:/Program Files/WTL80/include/atlres.h(15) : error RC2188: e:/Program Files/WTL80/Samples/GuidGen/Pocket PC 2003 (ARMV4)/Debug/RCa02380(197) : fatal error RC1116: RC terminating after preprocessor errors
 
解決方法是:編輯.rc文件 用#include "atlresce.h" 替換#include "atlres.h"就可以了。

6.運行WTL8.0裏面的ImageView的時候,出現問題:
ATLASSERT(!"Floating point (%%e, %%E, %%f, %%g, and %%G) is not supported by the WTL::CString class.");

解決方法:在頭文件中加入 #define _ATL_USE_CSTRING_FLOAT就好了。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章