在用vs.net進行窗體設計的時候，經常會遇到這樣的問題：我們需要在建構函式或者在onload事件中進行自己的一些初始化操作，比如連線乙個資料庫、呼叫乙個資源檔案或者後期繫結乙個元件。如果**通過編譯，在執行時會執行得相當如你所願。然而，當我們用窗體設計器開啟這樣乙個窗體或者繼承的窗體，ide環境會丟擲非常令人不愉快的異常，比如（nullreferenceexception）。
究其原因，主要是窗體設計器在載入窗體時會自動初始化該物件，自動執行諸如建構函式、onload方法和initializecomponent方法，目的在於能使窗體設計器展現出視覺化的編輯操作環境。（一些第三方控制項也就是利用這個時機彈出註冊認證的）。
現在大家明白了，原來我們通過窗體設計器開啟乙個窗體類或控制項類時，ide環境已經悄悄地在宿主程序中例項化了我們的類。
如果我們在建構函式中寫了這樣的**：
[c-sharp]view plain
copy
?public class myclass : system.windows.forms.form
//…
} 問題便由此產生，filename引數的值是程式在執行時傳遞的，設計時當然無從獲得。所以，窗體設計器在開啟此窗體類時，必然會丟擲異常，同時窗體將無法正常顯示。
解決這種問題的辦法網上其他朋友說了很多，歸納起來好像主要有以下三種途徑：
一、判斷this.designmode屬性
這是讓人一眼看過去就覺得最直接最有效的方法，絕對有一種踏破鐵蹄無覓處，得來全不費功夫的欣快感——可惜的是，用起來一點不奏效。因為如果該窗體是個獨立窗體或控制項，那一點問題都沒有，designmode的值如你所願為true，但是如果它是包含在其他控制項中被拖拽到設計器中（例如，把設計好的控制項拖入新的winforms窗體），那麼那個接受拖拽的窗體才處於設計模式，而它不是，它已鬼使神差地進入了runtime模式，然後如我所願，丟擲異常j。
二、利用assembly.getentryassembly()方法
判斷執行程式入口的元件是不是我們預想的，如果不是，那麼必然是ide的窗體設計器呼叫的——問題解決——只是有點大炮打蚊子的感覺。
三、定義乙個靜態成員，指示程式所處的模式
此方法我認為最好。具體做法是寫乙個全域性類，也就是建構函式為 private 限制的類，裡面的成員都為static靜態型別。這樣的乙個類由於建構函式是私有的，所以不可能自任何地方任何外部**中例項化，從而保證了其內成員的唯一性。然後，在程式的入口處，把此類的乙個用於表示執行模式的靜態成員標識為「執行時」，下面….一切都好說了，看**吧：
[c-sharp]view plain
copy
?//全域性類
public class globalclass
//用於標識執行時/設計時的bool型靜態成員，初始值設為false
public static bool runtimemode = false;
} //包含程式入口的類
public class entry
//…
} //某個窗體類
public class myform : system.windows.forms.form
//…
} //…
} 呵呵，問題圓滿解決。其實這樣乙個全域性類在我們平時設計系統的時候會經常用到，多用於儲存一些物件間的互動資料或者執行時環境引數。
如果大家有什麼更好的辦法解決所述問題，記得分享哦 :)
Windows 窗體中的事件順序
form 和 control 類公開一組與應用程式啟動和關閉相關的事件。windows 窗體應用程式啟動時，主窗體的啟動事件將按照以下順序引發 應用程式關閉時，主窗體的關閉事件將按照以下順序引發 備註當通過使用鍵盤 tab shift tab 等 通過呼叫 select 或 selectnextco...
Windows 中不規則窗體的程式設計實現
一 序言 二 實現原理 所有的 windows 窗體都位於乙個稱為 region 中，窗體的大小如果超出 region 的範圍，windows 會自動裁剪超出 region 範圍那部分的窗體，使其不可見。所以，要建立不規則窗體有兩個步驟 第一步就是建立不規則 region 第二步就是將窗體放到建立的...
Windows 中不規則窗體的程式設計實現
windows 中不規則窗體的程式設計實現 一 序言 在絕大多數的windows 應用程式中，其窗體都是使用的正規正矩的矩形窗體 例如我們常用的，記事本 掃雷 等等。矩形窗體，具有程式設計實現簡單，風格簡潔的優點，所以在普通文件應用程式和 簡單小遊戲中使用足矣。但在某些娛樂遊戲程式中使用就略顯呆板些...