我dotNET 所以我 Skin （WinForm 控制元件再選） (轉)

我dotNET 所以我 Skin （WinForm 控制元件再選） (轉)[@more@]

我 所以我 Skin （WinFo再選）

:namespace prefix = o ns = "urn:schemas--com::office" /> 

---

小氣的神 2002-02-15

Article Type: In-Depth

難度等級：6/9 

版本：1.10

  各位，不要笑我想好了，如果過些天我象今天一樣又發現什麼有趣的控制元件或原始碼，我就起這樣的標題《我dotNET，所以我什麼什麼 （ 控制元件還選） 》，如果再有就叫《又選》。總之如果有，我就會收集它，實驗它，可以的話，也寫出來和所有感興趣的人一起分享。

  在上可以體驗和感受現實中不太多的創新思想和速度，過去這種創新是反映在本身，而現在軟體或程式碼成了一種介質，往往透過它我們可以看到一個又一個創新的思想和個體，軟體業在靠這種創新不斷成長，作為其中的每一個個體也受到鼓舞，願意成為其中的一員。商業和網路催化和加快了這個過程，快到讓你驚訝和迎接不暇，所以說我們正從事著“這個世界上最好和最辛苦的職業”。

 話題要從上一篇文章的cwTab說起，幾天之後我在CodeProject上找到了它，然後試圖把它在RTM下透過，可這將是一件痛苦的過程，儘管帶來的回報是可以熟悉如何創造一個控制元件的過程和不斷減少的喜悅，但從Beta1到RTM某種程度上還是一個忍耐和掙扎的過程。不過許多事情都會有額外的回報，不然下一次就是一個失敗的重複和下賭。比如這一次我發現dotNET下指標的所謂無奈，也許它並不象我們曾經聽說和以為的那樣，dotNET互操作有一個看不見的界限，跨越之外也將象指標一樣會把你帶動一個不可預知的境地。如果熟悉C或C++的很容易知道下面這段程式碼在幹什麼，想出對應的C原始碼。不過在RTM下要除錯透過這段程式碼是需要某種挑戰的。原來和dotNET下的是兩種環境，它們有各自不同的疆界，能夠自如出入兩者的開發人員是幸福的。能明確知道這個界限的人，對於大多數來說也將是次幸福的。不過最後我還是告別指標用陣列重新寫過了，觀念之外需要一種行之有效的方式來詮釋它。

 

private unsafe bool FillColorTable(int hDC, int hPal, ref Methods.BITMAPINFO_FLAT tBitInfo)

{

  bool bRet = false;

  byte[] aj = new byte[sizeof(APIMethods.PALETTEENTRY) * 256];

   int nColors;

  fixed( APIMethods.RGBQUAD* prgb = (APIMethods.RGBQUAD*)&tBitInfo.bmiColors[0])

  {

  fixed( APIMethods.PALETTEENTRY* lppe = (APIMethods.PALETTEENTRY*)&aj[0] )

  {

  nColors = 1 << tBitInfo.bmiHeader_biBitCount;

   if( nColors <= 256 )

  {

  int hPalRet;

  if( hPal==APIMethods.Nullint ) 

hPalRet = APIMethods.GetSystemPaletteEntries(hDC, 0, nColors, aj);

  else 

  hPalRet = APIMethods.GetPaletteEntries(hPal, 0, nColors, aj);

  if( hPalRet!=0 )

  {

  for( int nL=0; nLoop

  {

  prgb[nLoop].rgbRed  = lppe[nLoop].peRed;

  prgb[nLoop].rgbGreen  = lppe[nLoop].peGreen;

   prgb[nLoop].rgbBlue  = lppe[nLoop].peBlue;

  prgb[nLoop].rgbReserved = 0;

  }

  bRet = true;

  }

  }

  }

  }

  return bRet;

}

}

 

更有趣的在後面，當某一個臨界值之後，我決定用陣列重新實現來減少目前的錯誤數和推進編譯的速度，又經過一個量化的值F5之後，終於可以看到這個不錯的Tab控制元件了。我保證自己在看到下面這條資訊之後，有混沌昏厥的頓感：“早知如此，又何必。。。”， 我們可愛的Phil Wright，就是上一篇文章提到的那個“很Cool”的Docking控制元件作者在dotnetmagic網站宣告“諸位，新的1.1版本出現，並且又多加一個Menu和Tab控制元件”，看到網站上的截圖，我在心裡安慰自己說cwTab還是有另外一些特色的，比如除VS.NET風格之外還有, InterDev風格並且還可以自定義。然後是機械的.html">Download新的版本。 到目前為止，我們已經可以看到cwTab、Magic Library以及ShDevelop的 Alexandria Library對Tab控制元件作出三種見解，迷人之處是三者各不相同，這個世界是多麼的奇妙。

 無論是菜鳥還是大蝦在網路生活中都會犯這樣錯誤：依賴書籤。某日我看到一個很有意思網頁，是關於WinForm的Skins話題，也是回答那些“如何使WinForm窗體象一樣？”的問題（如果CSDN上有人提這樣的問題，我一定去回覆haha），很快的Save這副靚麗的圖片和Zip。接著我想是個習慣，我返回到它的首頁（試圖想找到更多有趣的東東），然後收藏了它。幾天之後，當我再次想找到這個頁面時，我發現這個使用iso-8859-1字符集的網站上沒有Search功能，而且這種字元我根本不認識也無法和幾天前的記憶聯絡起來，拉丁文還是德文？（圖片出自：）：

 

 

ectratio="t" v:ext="edit">

  不過工作還要繼續做，之後可能又是上面類似的過程，從Beta2到RTM的各種調整變動，比較糟糕的是這次又遇到資源(不同國籍和語系)，我試圖用最新的regenresx.exe 轉換這些資原始檔到RTM版本，對於解決這樣的錯誤資訊：“The (Predetenado) culture cannot be converted to a CultureInfo on this computer. ”又將是需要技巧的考驗。不過我還是要感謝Alberto Ortiz Enrique （to:aoe@euskalnet.net">aoe@euskalnet.net） 這是個精妙的實現。在dotNET下我們有這樣一個新的機遇：各種語言的開發人員可以在一個通用的平臺上交流。這種交流是絕對有益的：一個C員有機會看到一個Prel程式設計師的實現，同樣一個VB程式設計師也可以看到程式設計師的設計。至於這個平臺是建立在還是上，這也許是商業和信仰決定的。感謝之後還是看看最後的成果吧：

 

 

當然裡面還有更多的一些Demo。最後提一句，AOECalendar.vb原始碼中 Sub New() 最後我註釋了下面的一句，這個錯誤是明顯和需要調整的。AddHandler AOECommand.Load, AddressOf AOECalendar_Load ，所以Sample中的Form5的範例會有些問題，不過這些問題的討論超出這篇文章的假設。並且它也不影響對整個設計和實現的理解。

  好了，我想是要結束這個有關創新和速度話題的時間了，上面的兩個例子你可以在下面的連結中獲得。我在W2K CN ADV+SP2+SRP1 , VS.NET EN RTM， dotNET SDK v1.0 上除錯透過。

相關的檔案：  

 

---

特別：

以上軟體和程式都已標明出處和所有者，請尊重版權和各自相關的條款。

感謝CSDN提供下載檔案和圖片的空間。

本文CSDN署名首發，轉載或改編請註明作者和出處。如果有問題，請發電子給new2001@.com

以上文字和圖片涉及其他人的和個人權利，所有文字和圖片只用於內部交流，不作任何新聞發表和商業用途。