軟體主廚的程式料理廚房

Windows Forms 的 DataGridView 開啟編輯資料之後，我們就可以在畫面上直接對資料進行修改，預設的統一操作行為是修改完資料之後，按下 Enter 鍵或是離開該儲存格，資料就會更新到綁定的 DataSource 上，就像下面這樣：

但是呢，使用者會希望能在修改之後立即更新到 DataSource，不要再多敲 Enter 鍵或離開儲存格的動作，尤其是 ComboBox，我們來看一下怎麼弄？

如果我們的 Data Source 是非同步更新的話，那麼我們就很容易收到下面的錯誤訊息。

跨執行緒作業無效: 存取控制項 'xxx' 時所使用的執行緒與建立控制項的執行緒不同。(Cross-thread operation not valid: Control 'xxx' accessed from a thread other than the thread it was created on.)

一般遇到這個情況，我們通常就是判斷 Control.InvokeRequired 屬性，然後改用 Control.Invoke() 或 Control.BeginInvoke() 方法來修改控制項的屬性，如果是在有資料綁定的情況呢？怎麼解決這個跨執行緒的問題？

在 Windows Forms 當中，只要是繼承自 Control 的控制項，都有實作 IBindableComponent 這個介面，都具有資料綁定的能力，但是有一些控制項就沒有，例如：ToolStripStatusLabel，不過也不是不能做資料綁定，加給它就好了。

要在一支既有的 Windows Forms（Windows 視窗程式）上，增加一個 TextBox 控制項，它有一個特殊的需求，就是在 TextBox 修改的文字不能與綁定的 DataMember 連動，簡單來說，就是做單向綁定（One-Way Binding）。

以往用 .NET Framework 開發的時候，都是用 TopShelf 來建置 Windows 服務，現在 .NET Core 弄了一個叫 .NET Generic Host 的東西，我們可以直接將服務透過它來 Host 成背景服務，而且它是跨平台的，不只可以部署在 Windows 上，Linux 上也行得通，ASP.NET Core 應用程式就是用它來讓服務可以長時間執行。

在雲端上的虛擬機器，其磁碟機會是個瓶頸，以 GCE 為例，如果應用程式需要讀寫大量的小檔，就會發現磁碟機的 IOPS 不太夠用，這時候就要增加磁碟機空間或是增加 CPU 的核心數，磁碟機的 IOPS 才會隨之增加，但是為此所增加的磁碟機空間或是 CPU 的核心數，我們根本就用不了那麼多，所以我就想說建立 RAM Disk，檔案從裡面存取，在離峰時間才執行指令將檔案備份到永久磁碟去，Windows Server 上有方法可以建立 RAM Disk，我們來看看怎麼做？

自從 Windows Server 2019 有一次莫名地被重新開機之後，每次登入就會出現關機事件追蹤器的視窗，不堪其擾。

做了 Windows Update 還是一樣，原因不明，不過我找到了三個解法，提供給各位參考。

身為一名程式設計師，打開瀏覽器 Google 一些資料，或是開啟 IDE 寫點程式是常有的事，而當事情做到一半必須被打斷時，「睡眠」這個功能就可以讓電腦在下一次開機的時候，快速地回復到前一次的工作狀態，但是 Windows 10 自從更新了 1903 之後，電腦卻經常在清晨被喚醒，等到我發現的時候，早就不知道運轉了多久、浪費了多少電，甚至直到最近我也更新了 1909，問題依舊還在。

自從更新了 Windows 10 1903 之後，事件檢視器就經常爆出 ESENT 事件識別碼 455 的錯誤，是不影響平常的操作，但是這個錯誤實在太多了，多到整個事件檢視器有三分之二的空間都是這個錯誤，影響到查找其他錯誤的效率。

前些日子開了一台新的 SQL Server，最近從監控當中發現凌晨 02:10 ~ 02:30 之間 CPU 被拉高，日復一日都是相同的時間點。

看起來吃了不少 CPU 資源，由於這段時間嚴格來講並不算是服務的離峰時間，還是希望將珍貴的 CPU 資源留給服務，所以必須查出來到底是誰吃掉了 CPU 的資源？