在開發乙個sql文字編輯器時很意外的在游標顯示問題上卡了一下。其解決的過程和之前發布的問題解決篇中的內容很吻合，是對比法解決問題的乙個非常好的例子。所以下來分享一下。
背景：1.由於產品需要，公司決定自行開發乙個文字剪輯器，以滿足功能的要求。
2.我們是在讀懂乙個開源的編輯器的基礎上，完全自行開發的。
3.之前在gdi+方面的經驗非常少，僅限於基本的圖形繪製
問題：在顯示編輯器中的游標時，需要在某些場合自行繪製游標。我發現游標的定位有問題，總是偏離正確位置兩個畫素左右的偏移。也就是說游標在當前行的位置，往上多偏移了兩個畫素左右的位置。這是通過觀察顯示器的輸出得到的結論。當然差這一點距離，不是說就不行，只是與其它編輯器比較會覺得很不舒服。所以我還是打算解決這個問題。
下面介紹一下解決步驟和過程。第一步是嘗試調整顯示游標的位置。既然游標位置偏高，那麼顯示游標時把位置調低不就可以了麼。不幸的是實踐發現，顯示位置調低以後，游標圖形的上面是不高了，但是下面卻偏低了。無論如何調整都不能兩全。通過比較開源的**也沒有發現問題。然後上網找例子，但是若干例子嘗試以後，也沒有解決問題。由於畫游標只是乙個簡單繪製直線的操作，所以真的不清楚還會出什麼問題。於是到這裡就陷入困境了。
考慮一下過後，開始考察自行繪製的游標和用win32 api點亮的游標之間的差異。我發現點亮的游標顯示是正常的，而點亮的游標的位置和自行繪製貫標的位置是相同的。這說明位置是正確的，問題出在別的地方。好，到這裡這在困境中多少理出了一條新線索。於是想到乙個方法，點亮的游標位置和繪製的游標位置使用不同的座標，在繪製游標時將座標往下移兩個畫素。這個方法是可行的，但是顯然不太完美，至少開源**中沒有這樣。嘗試後發現位置貌似對了，但是繪製的游標和點亮的游標在形狀上存在一點點差異。由於整個游標的高度也就是10個畫素左右，所以這一點點差異從比例上講還是不小的，使用者會有明顯的察覺。所以問題還是沒有完全解決。
到這裡基本上覺得很頭疼了。由於之前沒有接觸過游標的繪製，所以還一度開始懷疑是不是在某些不知道的地方出現了問題。在多次google和比較開源**之後還是沒有發現導致問題的原因。但是可以肯定一點是我寫下的**本身出問題的可能也很低。因為都是非常簡單的**。於是把注意力放寬，關注整個繪製流程，也就是ondraw方法中的全部**。通過反覆和仔細的比較，發現了乙個可疑的地方。那就是我在繪製文字時繪製方法的引數指定使用高質量，反鋸齒的效果，而在開原始碼中是沒有這樣做的。乙個事實說清楚的，如果使用反鋸齒高質量的引數來繪製直線的話，那麼直線是會有一點虛化部分，用於光滑鋸齒。那麼這個會不會就是導致問題的原因呢？
乙個CMake編譯問題的解決過程
如果將整個產品進行更新後，發現裝置和模擬器通訊不正常。實際的表象是這樣的，其實是忽略了乙個實際情況 老的應用使用之前的makefile直接make編譯而來，部分更新的時候，自己就是直接make生成進行的區域性替換，而全部替換是使用後來自己加入的cmake的方式進行的。這是問題的根源所在 開始的時候著...
乙個儲存過程 游標迴圈結果集
在查詢表名使用變數時只能使用concat 拼接 哭哭哭。drop procedure ifexists proc tmp create procedure proc tmp begin declare done intdefault 0 declare tablename varchar 255 d...
乙個查了6個小時的問題的解決過程
giraph中改進 想在edge上面加點屬性，結果發現修改後的值無法生效，pagereank用的edgenovalue類中增加乙個屬性，但是始終讀不出來值，開始以為是使用int導致型別中間沒有進行readfiles或者write的序列化問題，但是edgenovalue根本沒有相關方法，且實際初始化使...