圖海浮沈錄

最近需要一個展示圖片的元件，網上亂google了一下，發現都不是很滿意，後來試了下jedi中的 jvThumbView 等二個元件，在效能及操控上都不令人滿意，所以決定自己來造輪子。
問題是自己對圖形方面不是很了解(哈，其實是各方面都不很了解)，所以就在ktop 這搜了一下，算是頗有收穫，其中像是 redsnow 版大在某帖上所說的，很有啟發性。
依著該思路實作，一方面加入 graphicEx 組件，以增加可處理的圖片格式，一方面針對 jpg 用TJPEGImage作優化處理。
另外在顯示方面則利用listview imageList.

感覺就要大功告成時，卻發現listview 變成了 flash view, 閃動的很厲害。可是在站上看到有人介紹一個用 vc 實作的 Thumbnails Viewer using ListCtrl 一點都不會閃動，圖片很cool的一張一張翻開更新。檢視一下他用的物件也是windows 的 ListCtrl imagelist,實作代碼叫用的api與自己的是一樣的。奇了？那有用vc表現極佳的代碼，用delphi 就變成垃圾？抱著一個不信邪的精神，終於謎底揭曉，原來不是因為delphi不好，而是因為delphi太好了。
這話怎麼說？
因為vcl 封裝的很好，所以每次 ImageList 新增或取代一個image時，就通知使用它的元件，例如 listview。每次listview 收到通知(ImageListChange),就叫 SetImageList ,然後 ListView_SetImageList 然後windows 系統就重繪整個 listview.這是好事，省卻我們去處理這些相關的變動。
但是當同時大量新增image時，大量的整個listview重繪,就會導致畫面閃動。

處理方法 : 繼承 ImageList ，覆載 change. 加入一行 if FDoNoChange then exit; 如此在大量新增時，將 FDoNoChange設為true即可。

看著程式以高速而優雅的姿態展示著圖片，就如同過去delphi起始界面上高雅的智慧女神像，內心不僅升起一股感動。正沈浸於這美好的時光，一個所有程式作者熟到不能再熟的畫面出現了 !!! "錯誤訊息"! 什麼？怎麼可能，這一定是圖檔本身的問題，自己如是的安慰自己。經過一翻確認發現果然 TJPEGImage 就無法顯示該圖片，嘿嘿連 graphicEx 也報錯，有了這兩個權威元件的判決書，於是又重拾回美好的心情，可以打包收工了。

.....咦! 該死的 ms檔案總管，豪不留情而大剌剌的將該縮圖刺進了我的眼睛，顯然ms就是有辦法處理，這又將我重打入網海亂估(咕? google)的輪迴。

gdi plus ? 一眼瞧見了它。加了個plus，還是ms的東西。試試吧。一經測試，馬上驚為天人，不但該問題.jpg不再是問題, 連另一個問題 .tift檔( graphicEx會報錯 )也悠然顯現。不僅如此，其處理速度也很快。實測了一下，以jpeg格式來說，graphicEx元件由於不作任何優化處理所以會慢上數倍(當然如果深入其核心，也許可以做優化設定，畢竟source code 都是現成的)，TJPEGImage元件如果依redshow前輩的口訣設定，速度很快，而gdi plus 不做任何設定時，速度已經就和TJPEGImage 一樣快，哇，那設定一下還得了？找了一下，發現無處可設。大槪ms認為你想得到優化手法，它都想得到而且 "加"進去了，這 gdi plus 當中 "plus" 的頭銜果然不是浪得虛名。

經過了這樣一番周折，至此算是大事底定，小功告成了。下面作個總結。

總結:在delphi下，免費的圖形資源中，以 gdi plus graphicEx 算是完美組合了。一般常見的圖形格式如jpg,tif,png,bmp,就用gdi plus 快速處理，其他的格式就交給 graphicEx處理。如此也就不需要各別的TJPEGImage 等元件了。
缺點: 這兩組在處理上叫用的方法不同，需要加以封裝才會好用。

圖形顯示部份用大家都已熟悉的 listview imageList。

圖形應用部份應該要能輕易與 shell treeview 及 資料庫 dataset 等元件結合，因為這是最常見的圖形儲存模式。

最後實作出的元件 TfastPicPreview, 有興趣的朋友可下載試看看。

cool~~感謝分享
可以的話能否請您將檔案上傳到
會員作品發表區(限本人創作發表)

不知道有沒有人會轉成BCB版本:P

感謝無私分享～
第一時間從協做平台下載欲體驗一下，發現無法編譯少了些檔案，我想是因為我沒有事先安裝 gdi plus 和 graphicEx 兩個組件吧！？
我知道爬文與估海搜尋是程式人必備特質，沒用過這兩組件的我多花了半小時搜尋安裝未果，甚是遺憾。
我想若能順便帶一下相關組件安裝資訊就更完美了(下載點或其他)，也算幫助像我這樣的人能夠更短時間內觀摩這個範例。

編輯記錄

非常樂意將檔案在發表區分享，不過因為最近還在更新中，不知道上傳後還能不能更新?

另外有網友給了些建議，覺得不錯，新版1.05已提供下載。
其中包括
1.提供兩個事件，讓使用者可以更輕易且有彈性的餵圖檔檔名及listview的item caption.
2.不只可設定縮圖的大小，同時也可設定縮圖的間距。


===================引 用 taishyang 文 章===================
cool~~感謝分享
可以的話能否請您將檔案上傳到
會員作品發表區(限本人創作發表)

不知道有沒有人會轉成BCB版本:P

哈哈，TWY 兄所言甚是。小弟踏在前人的肩上，得到不少指引，大槪因為第一次發表，太過興奮，竟忘了將相關資訊好好整理。
茲分享如下。


) v9.9 應是最後發佈的版本， 已經好幾年沒更新了。

gdi plus
http://www.progdigy.com/files/gdiplus.zip
-------------------------- gdi plus 的參考文章 ----------------------------------------------------------------
他似乎也有對 gdi plus 作了封裝，不過我沒下載測試過。
http://blog.csdn.net/maozefa/archive/2007/11/12/1880484.aspx


這位萬一老兄將另外他也寫了不少入門級應用範例，每頁首先以一小 falsh 動畫顯示執行結果，再加上源碼說明。
非常值得一看的網站。

http://www.cnblogs.com/del/category/113557.html?Show=All


===================引 用 TWY 文 章===================
感謝無私分享～
第一時間從協做平台下載欲體驗一下，發現無法編譯少了些檔案，我想是因為我沒有事先安裝 gdi plus 和 graphicEx 兩個組件吧！？
我知道爬文與估海搜尋是程式人必備特質，沒用過這兩組件的我多花了半小時搜尋安裝未果，甚是遺憾。
我想若能順便帶一下相關組件安裝資訊就更完美了(下載點或其他)，也算幫助像我這樣的人能夠更短時間內觀摩這個範例。

再次感謝，我喜歡較為完整的學習，有了這些擴充資訊，使我打算安排出多些時間來研讀。
雖然k.top人氣不若過往，但只要還有像 newdk 這樣無私分享的人願意繼續貢獻，這裡一樣是個寶地。

回報一下，有了 GDI Plus & graphicEx 外，還有缺少 tnt 開頭的幾個檔案所以仍無法編譯...（應該是做 Unicode 的組件吧...!?）
建議可以連執行檔一起壓縮打包，讓大家可以直接使用觀摩而不一定要透過 自己編譯 Source 。

mm..關於這點我說一下好了，Tnt開頭的元件是TntUnicode，現已被TMS取得完整的版權。
而我自己也有host OSS且曾經去信問過TMS，根據TMS在news group跟給我的回信中表示，
我們已經有舊版的TntUnicode source code者，可以繼續無償的使用，但不得發行可安裝的版本。
為免困擾，我想還是請newdk把相關元件的相依性表列在google codes，自行找舊版的TntUnicode元件來安裝會比較好。


===================引 用 TWY 文 章===================
回報一下，有了 GDI Plus & graphicEx 外，還有缺少 tnt 開頭的幾個檔案所以仍無法編譯...（應該是做 Unicode 的組件吧...!?）
建議可以連執行檔一起壓縮打包，讓大家可以直接使用觀摩而不一定要透過 自己編譯 Source 。

------
不論是否我發的文，在能力範圍皆很樂意為大家回答問題。
為了補我的能力不足之處，以及讓答案可以被重複的使用，希望大家能儘量以公開的方式問問題。
在引述到我的文時自然會儘量替各位想辦法，謝謝大家！

確實，有時看了某程序的說明，但是還不確定其效果是不是自己要的，若有個exe檔直接看，會方便不少。但相對會使檔案大許多，不過google 是海量，這應是不成大問題。
所以已發了一個含執行檔的版本。


===================引 用 TWY 文 章===================
回報一下，有了 GDI Plus & graphicEx 外，還有缺少 tnt 開頭的幾個檔案所以仍無法編譯...（應該是做 Unicode 的組件吧...!?）
建議可以連執行檔一起壓縮打包，讓大家可以直接使用觀摩而不一定要透過 自己編譯 Source 。

一向認為 tnt 應是delphi 使用者必備的元件之一，特別是對台灣地區。為什麼? 對使用者來說，一種不認識的文字即使正確顯示出來，本質上與亂碼無異。
但簡繁體確是大家大致上可認得的字，所以能正確處理相當重要。
但對大陸人來說，即使沒有繁體網站和網路資源，大該也不是大問題。但對使用繁體的台灣來說，簡體的巨量資源確是絕不可忽視。例如程式不能正確讀取簡體檔名，就是個大問題。delphi 一直到2009 才支援unicode 實在是晚得太離譜了。在此之前程式師若要繁簡共榮,要嗎捨掉大量的控件( delphi 的優勢之一)使用綁手綁腳的 tnt ，要不然自已修改。

無論如何unicode delphi 的時代已來臨，所以 FastPicPreview 也發個不含 tnt 的版本，這樣舊delphi 也可編譯，而直接用2009 編譯，就支援unicode了。哇，天下太平了!!!

但graphicEx似乎不能在 unicode的2009環境下編譯，因為似乎graphicEx已不再更新了。
所以問題來了，一些控件組如jedi系列有人繼續維護更新，而其他如果沒有，高手如雲的delphi ktop中是否應該有些動作呢?


===================引 用 Coffee 文 章===================
mm..關於這點我說一下好了，Tnt開頭的元件是TntUnicode，現已被TMS取得完整的版權。
而我自己也有host OSS且曾經去信問過TMS，根據TMS在news group跟給我的回信中表示，
我們已經有舊版的TntUnicode source code者，可以繼續無償的使用，但不得發行可安裝的版本。
為免困擾，我想還是請newdk把相關元件的相依性表列在google codes，自行找舊版的TntUnicode元件來安裝會比較好。

編輯記錄

Unicode 問題的確是大家心中長久以來的痛，還好我需要開發的程式這方面需求並不高，所以 TNT 之類的我沒用過說。

至於 graphicEX 這類經典好用套件的承先啟後，個人樂見其成，但我想授權的取得與確認是必要的。至於 k.top 的高手是否應有動作，我是不敢奢望他人，畢竟大家都有自己的家庭與工作，且需要有時間與 Graphic 相關認知能力才行(這兩點我就已經出局了，專業知識不足 閒於要當兩個小孩的玩具)。

在我看來， newdk 大大對於 unicode 、 graphic 這一塊充滿熱情也很有心得，不妨揭竿起義號召一下，可利用協做平台等開放資源來共同維護。若初期乏人響應也別灰心，在 k.top 保持跟大家發表、分享，相信大家還是會給予高度支持鼓勵的。

Troy在放棄維護之前曾經在news group詢問過，但是沒有人接手。一直到確定轉手給TMS的時候，才出現一堆無意義的謾罵，因此我想是怨不得人的。(我則是晚了一步)
曾經我也跟TntWare的作者和TMS提過一樣的問題，就是希望舊版(及LX Control)可以獨立成一個分支放到SF.net上繼續以維護的名義及GPL License存在，最主要供既存的OSS Project維護其library的相依性。
Troy認為他已經把版權交給tMS， LX Control他則是覺得要再考慮(但沒有再回覆)。但TMS的回覆如同我先前提過的，不得繼續發行可安裝的Tnt元件。

因此，如果想要維護什麼元件也只能靠自己了，畢竟每個人會使用到的元件不一樣。
而且無奈在臺灣/大陸，OSS風氣不是那麼盛(尤其是Delphi)。別說是維護既有的OSS，光是像newdk前輩這樣改好再放出來就已經是少之又少了。

===================引 用 newdk 文 章===================
一向認為 tnt 應是delphi 使用者必備的元件之一，特別是對台灣地區。為什麼? 對使用者來說，一種不認識的文字即使正確顯示出來，本質上與亂碼無異。
但簡繁體確是大家大致上可認得的字，所以能正確處理相當重要。
但對大陸人來說，即使沒有繁體網站和網路資源，大該也不是大問題。但對使用繁體的台灣來說，簡體的巨量資源確是絕不可忽視。例如程式不能正確讀取簡體檔名，就是個大問題。delphi 一直到2009 才支援unicode 實在是晚得太離譜了。在此之前程式師若要繁簡共榮,要嗎捨掉大量的控件( delphi 的優勢之一)使用綁手綁腳的 tnt ，要不然自已修改。

無論如何unicode delphi 的時代已來臨，所以 FastPicPreview 也發個不含 tnt 的版本，這樣舊delphi 也可編譯，而直接用2009 編譯，就支援unicode了。哇，天下太平了!!!

但graphicEx似乎不能在 unicode的2009環境下編譯，因為似乎graphicEx已不再更新了。
所以問題來了，一些控件組如jedi系列有人繼續維護更新，而其他如果沒有，高手如雲的delphi ktop中是否應該有些動作呢?


===================引 用 Coffee 文 章===================
mm..關於這點我說一下好了，Tnt開頭的元件是TntUnicode，現已被TMS取得完整的版權。
而我自己也有host OSS且曾經去信問過TMS，根據TMS在news group跟給我的回信中表示，
我們已經有舊版的TntUnicode source code者，可以繼續無償的使用，但不得發行可安裝的版本。
為免困擾，我想還是請newdk把相關元件的相依性表列在google codes，自行找舊版的TntUnicode元件來安裝會比較好。

------
不論是否我發的文，在能力範圍皆很樂意為大家回答問題。
為了補我的能力不足之處，以及讓答案可以被重複的使用，希望大家能儘量以公開的方式問問題。
在引述到我的文時自然會儘量替各位想辦法，謝謝大家！

回報一下...
三個範例中『file mode』可正常編譯出執行檔，『db mode(ado)』、『db mode(custom,bde)』則少了 AppEvent.dcu，這應該是 RxLib 套件的吧！？
不過移掉仍可編譯啦～
試玩了一下，載入、展示圖片的速度的確是快，絲毫不遜色於 ACDSee，讚啦！

Graphics32 已經有支援Delphi 2009/2010的版本了, 大家可以從NewsGroup中找到相關的信息.

news.graphics32.org

也可以從下面的網址下載:
http://www.xperttool.com/download/delphi/Graphic32.D2010.zip

另一個好消息是, Graphics32 將繼續開始開發.

------
------------------------
博采眾家之長,奉獻綿薄之力
------------------------

編輯記錄

真是太棒了，有不含tnt類的元件，這樣就可以在bcb上run起來了
謝謝開版大的分享啦！

http://delphi.ktop.com.tw/board.php?cid=30&fid=71&tid=98710
因為這篇討論,我也曾經試著要做一個出來,只是做到一半看到newdk發表的TfastPicPreview我就知道我不用寫了
多執行緒,用GraphicEx支援多種格式,支援unicode檔名,GDI 加快讀取速度
這比起內建的TJPEGImage好太多了,還以為要用不同的技巧來加快讀取速度現在感覺沒必要了
http://delphi.ktop.com.tw/board.php?cid=168&fid=923&tid=81296
這可是Ktop少見的大作,我想之後類似的問題就丟這個連結就解決了吧


補充
>但graphicEx似乎不能在 unicode的2009環境下編譯，因為似乎graphicEx已不再更新了。
這裡有2009,2010的GraphicEx http://www.songbeamer.com/delphi/


雖然是未完成的作品,還是放上來讓各位網友試看看
http://delphi.ktop.com.tw/board.php?cid=31&fid=97&tid=99471
若需要vcl60.bpl請到這裡下載
http://delphi.ktop.com.tw/download/upload/45b8c86f862d6_VCL Runtime Library.exe


Chance36所提供的看圖程式
http://delphi.ktop.com.tw/board.php?cid=31&fid=79&tid=29612

感謝無私分享
K.TOP又恢復以前友善介面了
真是可喜可賀
希望能回到往日的盛況