.Net 海角點部落

Visual Studio 提供給 Windows Form 開發者一個非常方便的視覺化工具來安排圖形化使用者介面的展示，在大部份不太複雜的狀況下只要拿滑鼠拖來拉去的就可以安排好你所想要展示的畫面，但究竟這些個控制項的定義是存放在哪裡？答案就是Form Desinger檔案。

延續上一篇Split的弔詭這問題，我個人猜測Split可能是用遞迴的方式產生的，所以就很無聊的想要寫一個可以模擬這種程序的範例出來。

Split有一些令人覺得很奇妙的特質，這篇文源自於MSDN論壇上的一個發問 ：【請教】關於 SPlit 跟 陣列長度 ，就寫個小文章來解釋一下。

承上篇[X64 , Access MDB 與 卡到陰]，如果不知道前因後果的人可以去看一下，雖然我很嘴硬地說沒有要說明技術性的問題，而採用暫時性方案 (也就是乾脆直接裝在System Volumn下) 解決，不過實際上自己是非常想要找出真正地原因與解決之道。

這一陣子在寫一個指紋機的考勤軟體，由於考慮到這軟體必須要使用者自己安裝，並且沒有多人操作的需求，所以就決定使用Access 2003的mdb檔來當做資料庫，也因為這樣整個程式只能編譯成X86版本，沒想到苦難就這樣開始了。

這個測試使用的是Access的資料檔案與 OleDb 相關類別，雖然過去就知道不斷地Open/Close OleDbConnection會影響效能，不過由於很少用Access而且使用 SqlDb相關類別時有Bulk可以用，所以從來也沒有想過倒底會產生多大的影響，所以就很無聊地寫了一個測試程式來測看看真實的效能影響數據。

一般我們使用ToolStrip大概都還是用.NET提供的基本下拉式選單，有一次在MSDN 論壇上有人發問是否可以做出自訂的樣式，這一篇文就來介紹如何自訂ToolStrip的ToolStripItem。

最近在寫一個要將系統事件藉由簡訊平台發送到手機簡訊的軟體，我想說這玩意以前我就寫過應該不會太難，以前都用Every8D的平台寫，從來沒出過毛病，不過這一次的需求比較特殊，因為是政府單位(我猜應該是某個XX事務所)，人客要求說要使用「全國XX即時訊息發送中心」發送訊息之URL API 平台發送簡訊，一開始看到範例的時候就傻眼了，因為那個範例是Java的，幸好朋友多，半問半猜之下也把測試的程式碼拼湊出來。

七月是個令人歡欣鼓舞的月份，許多朋友這幾天都接到微軟通知獲選或是連任MVP的通知，雖然在噗浪已經狂賀一輪了，在這邊還是要恭喜他們，很開心他們的努力有獲得微軟的認可。言歸正傳，因為這幾天在改以前寫的類別庫，突然讓我想起為何 .Net中的列舉都是在命名空間﹝Namespace﹞中，而我的都寫在類別裡面；是不是自訂類別庫不能將列舉放在命名空間中呢？

這一篇來應用一下BindingNavigator與BindingSource的結合，來取代前一篇使用Button做出來的功能，並且同時繫結資料到TextBox與DataGridView。

BindingSource類別在個人看來是 .NET 2.0的偉大發明之一，它具有兩種用途﹝引述自MSDN文件庫BindingSource 類別﹞：
第一，經由提供間接取值 (Indirection) 層、貨幣管理、變更告知和其他服務，簡化將表單上的控制項繫結至資料的動作。
第二，BindingSource 元件可以當做強型別的資料來源。

第一篇說明了BackgroundWorker的基本用法，這一篇要談到以下幾個主題：
(1) 不斷循環執行的背景執行緒及如何中斷。
(2) 執行過程的參數傳遞。

.Net Framework在多執行緒的支援上提供了許多方便的類別，而BackgroundWorker則是一項非常容易用來撰寫多執行緒的類別， 它不僅和System.Windows.Forms.Timer一樣也在工具箱提供了可拖曳使用的元件，並且提供了ProgressChanged事件使得更動主畫面控制項可以不需藉由Control.Invoke﹝有些時候Invoke的概念對初學者會有或多或少邏輯上的困擾﹞，個人覺得這個元件滿適合初學者當做撰寫多執行緒的入門。

這一篇談一個小小的技巧，最近也常在MSDN看過類似的問題，許多同好都會提出如何把一個DataGridView的Row複製到另一個DataGridView，所以就想寫一個小小的範例讓需要的人參考。

SQL:Having VS Where

.NET提供了許多回呼的方法使得撰寫多執行緒與非同步的程式變的較為簡單，像是ThreadPool.QueueUserWorkItem、Socket與其衍生類別的Beginxxxx、ADO.NET中的SqlCommand.Beginxxxxx等等。而這些方法通常在其多載函式中其中至少會有一個具備了State Object，當我剛開始撰寫這一類程式的時候，一直無法弄清楚這個State Object的作用，所以想要特別用簡單的方式來介紹這個Object的用途。

第四篇來談談用Try Catch來避免必然會發生的問題，一開始我在建立這個系列文章的原因是因為常再MSDN看到許多.Net同好們問的問題所引發的靈感，因為許多同好對於Try Catch並沒有特別的重視其例外訊息所帶給程式撰寫者的提示，所以往往會被這些例外狀況困住；而另一種情況則是引發了必然發生的例外，卻沒想到使用Try Catch來閃躲這個例外，這也就是這一篇的主要討論範圍。

在之前的例子中，都是一個Try配著一個Catch，其實一個Try可以搭配很多Catch，這樣子的作法，可以依照不同的例外狀況做不同的處理。

這一篇來說說關於例外處理的When和Finally

看到這個標題大概很多人會笑出來：「廢話！當然是除錯！」。是的，Try Catch最主要的功能就是除錯，而這檔事也是初學者應該要列為首要學習的事情之一，所以我想特別談談這件事情。