向在對話框中靜態地顯示一個bitmap類型圖片,在網上搜了好半天 ,發現都麻煩的很。
最后發現一個簡單的方法:
1、首先添加想要顯示的圖片資源,ID為IDB_BITMAP1.
2、直接使用picture control
->設置屬性->雜項->type,選擇Bitmap類型
然后屬性中就會出現IMAGE項,直接從種選擇要顯示的圖片的IDB_BITMAP1,完畢!
首先說說ASCII碼吧,計算機在外國誕生后,大家要想怎么吧characters input給計算機,他們就定了ASCII,現在有人抱怨老美太小氣,只設計了128個,其實不然。試想想當時的環境,一是他們無法預料計算機能像現在這樣普及,二是存儲設備還都不成熟,成本爆高。所以導致后來的局面,也就是ISO和unicode兩種字符集,分別是UCS-4(4個字節)和unicode 1.0(2個字節),但這種定長的導致英語國家不答應了,平時字符都是一個byte,現在突然編程2個甚至是4個,還有后來加入新的字符后就更亂了,最后兩個組織整合了,整個世界終于安靜了。
在這我想澄清個概念,就是大家不要把unicode和utf-8, utf-16, utf-32搞亂了,首先unicode是一套標準的字符集,基本包括了大多數的文字了,可以在這個路徑下載最新的字符表http://www.unicode.org/ ,utf-7,8等都是基于這個字符集的一些編碼算法。在unicode設計的時候把ASCII碼的128個作為unicode的前128個。那么現在最最最流行的也就是UTF-8的編碼了,它的算法思想是:
U-00000000 - U-0000007F: 0xxxxxxx ASCII碼
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
比如我在codeCharts里面找到這個字符?(010e),那么它的UTF-8結果是:
1 0000 1110 -------> 110 00 100 10 001110 C48E 就這么簡單了,有沒有。
這里我還想引入一個庫libiconv,可以說是一個萬能的轉換編碼的工具把,去網站http://www.gnu.org/software/libiconv/ 了解詳情,它目前支持的字符編碼不下30種,常用的都有了。那么有了這個庫以后呢,大家可以在遇到已知輸入多種編碼時,可以用它來轉成一種類型的編碼(utf-8),然后做處理。VCard的解析我就是就是這樣解決的。
先到這,希望各位博友能再補充,提點一二,萬分感謝!
最初來自http://www.sinoprise.com/read.php?tid-662-page-e-fpage-1.html(遺憾的是這個鏈接已經打不開了),我基本未改動,只是進行了一些排版和整理。參考文獻:http://www.fsf.org/licensing/licenses/
現今存在的開源協議很多,而經過Open Source Initiative組織通過批準的開源協議目前有58種(http://www.opensource.org/licenses/alphabetical)。我們在常見的開源協議如BSD, GPL, LGPL,MIT等都是OSI批準的協議。如果要開源自己的代碼,最好也是選擇這些被批準的開源協議。
這里我們來看四種最常用的開源協議及它們的適用范圍,供那些準備開源或者使用開源產品的開發人員/廠家參考。
BSD開源協議(original BSD license、FreeBSD license、Original BSD license)
BSD開源協議是一個給于使用者很大自由的協議?;旧鲜褂谜呖梢?#8221;為所欲為”,可以自由的使用,修改源代碼,也可以將修改后的代碼作為開源或者專有軟件再發布。
但”為所欲為”的前提當你發布使用了BSD協議的代碼,或則以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
BSD 代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由于允許使用者修改和重新發布代碼,也允許使用或在BSD代碼上開發商業軟件發布和銷售,因此是對商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發。
Apache Licence 2.0(Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0)
Apache Licence是著名的非盈利開源組織Apache采用的協議。該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發布(作為開源或商業軟件)。需要滿足的條件也和BSD類似:
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要并作為開源或商業產品發布/銷售。
GPL(GNU General Public License)
我們很熟悉的Linux就是采用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改后和衍生的代碼做為閉源的商業軟件發布和銷售。這也就是為什么我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商業軟件公司開發的免費軟件了。
GPL協議的主要內容是只要在一個軟件中使用(”使用”指類庫引用,修改后的代碼或者衍生代碼)GPL 協議的產品,則該軟件產品必須也采用GPL協議,既必須也是開源和免費。這就是所謂的”傳染性”。GPL協議的產品作為一個單獨的產品使用沒有任何問題,還可以享受免費的優勢。
由于GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議,對于使用GPL協議的開源代碼,商業軟件或者對代碼有保密要求的部門就不適合集成/采用作為類庫和二次開發的基礎。
其它細節如再發布的時候需要伴隨GPL協議等和BSD/Apache等類似。
LGPL(GNU Lesser General Public License)
LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須采用GPL協議不同。LGPL允許商業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼。這使得采用LGPL協議的開源代碼可以被商業軟件作為類庫引用并發布和銷售。
但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須采用LGPL協議。因此LGPL協議的開源代碼很適合作為第三方類庫被商業軟件引用,但不適合希望以LGPL協議代碼為基礎,通過修改和衍生的方式做二次開發的商業軟件采用。
GPL/LGPL都保障原作者的知識產權,避免有人利用開源代碼復制并開發類似的產品
MIT(MIT)
MIT是和BSD一樣寬范的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版里包含原許可協議的聲明,無論你是以二進制發布的還是以源代碼發布的.
當年索尼名為音質,實是為了保護唱片版權,賺更多的錢,推出MD,但還沒等到大賺一筆,就被類似于APPLE,IRIVER 的MP3打敗。之后雖說也推出了一些MP3,但是不管從外形還是音質上都不是很滿意。就在我覺得MP3的戰爭中SONY可能只是一個匆匆過客的時候,發現了SONY在9月29日要上市的代號“Rolly”的MP3。
其實在SONY的愛寶機器狗問世時,我就在想既然SONY的AI技術這么成熟了,應該會出些其它的更接近生活的產品,但遲遲沒有出現直到現在。那么這個會跳舞的MP3主要有一下的功能:
1 支持 MP3、ATRAC 和 AAC 檔,并且內置有 1GB 的內存來存放音樂,或者也可以透過 A2DP / AVRCP 藍牙將音樂傳送給它
2 藏在蓋子底下的確實是兩個喇叭,清晰的音質。
3 拿起來將一個側面朝上時,下面的蓋子會蓋起來。這時 Rolly 的其中一個「輪子」就成了歌曲選擇器。
4 放在桌子上的時候推動它(也就是讓輪子轉)可以換音樂,原地旋轉是調音量。 按下上面的按鍵,它就會開始隨歌曲跳舞。
5 Rolly 可以透過 USB 聯機到電腦上,還可以改程控它的動作。
6 充滿電的話,它可以播 5 個小時的音樂、4 個小時的音樂加跳舞、3 個半小時的音樂加跳舞加藍牙。
那么現在Rolly是以 ¥40,000(2,850 人民幣)的價格上市,我覺得我又得贊錢了。
具體的視頻官方網站:http://www.rolly-show.com。相信SONY要掀起MP3的臺風了。
大家幫我看下:
Where can I download Konqueror/Embedded?
Although there is a 0.1 release available I strongly recommend for grabbing one of the latest snapshots instead. Have a look at http://devel-home.kde.org/~hausmann/snapshots/. Please note these snapshots are based on the KONQE_1_0_BRANCH and require Qt version 2.3.x to compile - they won't work with any Qt 3.x version!
And if you're interesting in bleeding edge stuff then you can also check out the source from the KDE CVS Repository , in the kdenox module. Note that besides this module you will also need the kdelibs module for building. Make sure your copy of kdelibs resides in the same directory as the kdenox module.
我如果想下載snapshots版的就去http://devel-home.kde.org/~hausmann/snapshots
如果想下載不穩定(bleeding edge stuff:是不是指測試版)的就去KDE CVS Repository
我要全部功能,應該下載哪個呢?