Windows 窗体设计器中的设计时错误

Posted 试看将来的环球,必将是代码的世界。

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Windows 窗体设计器中的设计时错误相关的知识,希望对你有一定的参考价值。

image

image

 

 

在用 VS.NET进行窗体设计的时候,经常会遇到这样的问题:我们需要在构造函数或者在OnLoad事件中进行自己的一些初始化操作,比如连接一个数据库、调用一个资源文件或者后期绑定一个组件。如果代码通过编译,在运行时会执行得相当如你所愿。然而,当我们用窗体设计器打开这样一个窗体或者继承的窗体,IDE环境会抛出非常令人不愉快的异常,比如(NullReferenceException )。
 
究其原因,主要是窗体设计器在载入窗体时会自动初始化该对象,自动执行诸如构造函数、OnLoad方法和InitializeComponent方法,目的在于能使窗体设计器展现出可视化的编辑操作环境。(一些第三方控件也就是利用这个时机弹出注册认证的)。
现在大家明白了,原来我们通过窗体设计器打开一个窗体类或控件类时,IDE环境已经悄悄地在宿主进程中实例化了我们的类。
如果我们在构造函数中写了这样的代码:
  1. public class MyClass : System.WIndows.Forms.Form  
  2. {  
  3. public MyClass(string fileName)  
  4. {   
  5. InitializeComponent();  
  6. FileStream myFile = File.Open( filename ); // 窗体设计器可能抛出异常!  
  7. //…  
  8.          }  
  9.   
  10.          //…  
  11. }  
问题便由此产生,fileName参数的值是程序在运行时传递的,设计时当然无从获得。所以,窗体设计器在打开此窗体类时,必然会抛出异常,同时窗体将无法正常显示。
解决这种问题的办法网上其他朋友说了很多,归纳起来好像主要有以下三种途径:
一、判断 this.DesignMode 属性
这是让人一眼看过去就觉得最直接最有效的方法,绝对有一种踏破铁蹄无觅处,得来全不费功夫的欣快感——可惜的是,用起来一点不奏效。因为如果该窗体是个独立窗体或控件,那一点问题都没有,DesignMode的值如你所愿为true,但是如果它是包含在其他控件中被拖拽到设计器中(例如,把设计好的控件拖入新的WinForms窗体),那么那个接受拖拽的窗体才处于设计模式,而它不是,它已鬼使神差地进入了RunTime模式,然后如我所愿,抛出异常J
 
二、利用 Assembly.GetEntryAssembly()方法
判断执行程序入口的组件是不是我们预想的,如果不是,那么必然是IDE的窗体设计器调用的——问题解决——只是有点大炮打蚊子的感觉。
 
三、定义一个静态成员,指示程序所处的模式
此方法我认为最好。具体做法是写一个全局类,也就是构造函数为 private 限制的类,里面的成员都为static静态类型。这样的一个类由于构造函数是私有的,所以不可能自任何地方任何外部代码中实例化,从而保证了其内成员的唯一性。然后,在程序的入口处,把此类的一个用于表示运行模式的静态成员标识为“运行时”,下面….一切都好说了,看代码吧: 
  1. //全局类  
  2. public class GlobalClass  
  3. {  
  4. //私有构造器,防止实例化  
  5. private GlobalClass(){}  
  6. //用于标识运行时/设计时的bool型静态成员,初始值设为false  
  7. public static bool RunTimeMode = false;  
  8. }  
  9.    
  10. //包含程序入口的类  
  11. Public class Entry  
  12. {  
  13. …  
  14. //主线程入口点,窗体设计器绝不会执行此方法  
  15. static void Main(string[] args)  
  16. {  
  17.          //置为true  
  18. GlobalClass.RunTimeMode = true;  
  19. //…..  
  20.          }  
  21.          //…  
  22. }  
  23.    
  24. //某个窗体类  
  25. public class MyForm : System.Windows.Forms.Form  
  26. {  
  27.          public MyForm()  
  28.          {  
  29.                    //窗体设计器必须调用的  
  30.                    InitializeComponent();  
  31.                    //判断运行模式  
  32.                    If( GlobalClass.RunTimeMode )  
  33.                    {  
  34.                             //在此处做一些窗体设计器会报错的事情  
  35.                    }  
  36.                    //…  
  37.          }  
  38.          //…  
  39. }  
呵呵,问题圆满解决。其实这样一个全局类在我们平时设计系统的时候会经常用到,多用于存储一些对象间的交互数据或者运行时环境参数。
如果大家有什么更好的办法解决所述问题,记得分享哦 :)

 

print?

  1. public class MyClass : System.WIndows.Forms.Form 
  2. public MyClass(string fileName) 
  3. {  
  4. InitializeComponent(); 
  5. FileStream myFile = File.Open( filename ); // 窗体设计器可能抛出异常! 
  6. //… 
  7.          } 
  8.  
  9.          //… 

问题便由此产生,fileName参数的值是程序在运行时传递的,设计时当然无从获得。所以,窗体设计器在打开此窗体类时,必然会抛出异常,同时窗体将无法正常显示。
解决这种问题的办法网上其他朋友说了很多,归纳起来好像主要有以下三种途径:
一、判断 this.DesignMode 属性
这是让人一眼看过去就觉得最直接最有效的方法,绝对有一种踏破铁蹄无觅处,得来全不费功夫的欣快感——可惜的是,用起来一点不奏效。因为如果该窗体是个独立窗体或控件,那一点问题都没有,DesignMode的值如你所愿为true,但是如果它是包含在其他控件中被拖拽到设计器中(例如,把设计好的控件拖入新的WinForms窗体),那么那个接受拖拽的窗体才处于设计模式,而它不是,它已鬼使神差地进入了RunTime模式,然后如我所愿,抛出异常J
 
二、利用 Assembly.GetEntryAssembly()方法
判断执行程序入口的组件是不是我们预想的,如果不是,那么必然是IDE的窗体设计器调用的——问题解决——只是有点大炮打蚊子的感觉。
 
三、定义一个静态成员,指示程序所处的模式
此方法我认为最好。具体做法是写一个全局类,也就是构造函数为 private 限制的类,里面的成员都为static静态类型。这样的一个类由于构造函数是私有的,所以不可能自任何地方任何外部代码中实例化,从而保证了其内成员的唯一性。然后,在程序的入口处,把此类的一个用于表示运行模式的静态成员标识为“运行时”,下面….一切都好说了,看代码吧: 
  1. //全局类 
  2. public class GlobalClass 
  3. //私有构造器,防止实例化 
  4. private GlobalClass(){} 
  5. //用于标识运行时/设计时的bool型静态成员,初始值设为false 
  6. public static bool RunTimeMode = false
  7.   
  8. //包含程序入口的类 
  9. Public class Entry 
  10. … 
  11. //主线程入口点,窗体设计器绝不会执行此方法 
  12. static void Main(string[] args) 
  13.          //置为true 
  14. GlobalClass.RunTimeMode = true
  15. //….. 
  16.          } 
  17.          //… 
  18.   
  19. //某个窗体类 
  20. public class MyForm : System.Windows.Forms.Form 
  21.          public MyForm() 
  22.          { 
  23.                    //窗体设计器必须调用的 
  24.                    InitializeComponent(); 
  25.                    //判断运行模式 
  26.                    If( GlobalClass.RunTimeMode ) 
  27.                    { 
  28.                             //在此处做一些窗体设计器会报错的事情 
  29.                    } 
  30.                    //… 
  31.          } 
  32.          //… 
呵呵,问题圆满解决。其实这样一个全局类在我们平时设计系统的时候会经常用到,多用于存储一些对象间的交互数据或者运行时环境参数。
如果大家有什么更好的办法解决所述问题,记得分享哦

 

print?

  1. public class MyClass : System.WIndows.Forms.Form 
  2. public MyClass(string fileName) 
  3. {  
  4. InitializeComponent(); 
  5. FileStream myFile = File.Open( filename ); // 窗体设计器可能抛出异常! 
  6. //… 
  7.          } 
  8.  
  9.          //… 

问题便由此产生,fileName参数的值是程序在运行时传递的,设计时当然无从获得。所以,窗体设计器在打开此窗体类时,必然会抛出异常,同时窗体将无法正常显示。
解决这种问题的办法网上其他朋友说了很多,归纳起来好像主要有以下三种途径:
一、判断 this.DesignMode 属性
这是让人一眼看过去就觉得最直接最有效的方法,绝对有一种踏破铁蹄无觅处,得来全不费功夫的欣快感——可惜的是,用起来一点不奏效。因为如果该窗体是个独立窗体或控件,那一点问题都没有,DesignMode的值如你所愿为true,但是如果它是包含在其他控件中被拖拽到设计器中(例如,把设计好的控件拖入新的WinForms窗体),那么那个接受拖拽的窗体才处于设计模式,而它不是,它已鬼使神差地进入了RunTime模式,然后如我所愿,抛出异常J
 
二、利用 Assembly.GetEntryAssembly()方法
判断执行程序入口的组件是不是我们预想的,如果不是,那么必然是IDE的窗体设计器调用的——问题解决——只是有点大炮打蚊子的感觉。
 
三、定义一个静态成员,指示程序所处的模式
此方法我认为最好。具体做法是写一个全局类,也就是构造函数为 private 限制的类,里面的成员都为static静态类型。这样的一个类由于构造函数是私有的,所以不可能自任何地方任何外部代码中实例化,从而保证了其内成员的唯一性。然后,在程序的入口处,把此类的一个用于表示运行模式的静态成员标识为“运行时”,下面….一切都好说了,看代码吧: 
  1. //全局类 
  2. public class GlobalClass 
  3. //私有构造器,防止实例化 
  4. private GlobalClass(){} 
  5. //用于标识运行时/设计时的bool型静态成员,初始值设为false 
  6. public static bool RunTimeMode = false
  7.   
  8. //包含程序入口的类 
  9. Public class Entry 
  10. … 
  11. //主线程入口点,窗体设计器绝不会执行此方法 
  12. static void Main(string[] args) 
  13.          //置为true 
  14. GlobalClass.RunTimeMode = true
  15. //….. 
  16.          } 
  17.          //… 
  18.   
  19. //某个窗体类 
  20. public class MyForm : System.Windows.Forms.Form 
  21.          public MyForm() 
  22.          { 
  23.                    //窗体设计器必须调用的 
  24.                    InitializeComponent(); 
  25.                    //判断运行模式 
  26.                    If( GlobalClass.RunTimeMode ) 
  27.                    { 
  28.                             //在此处做一些窗体设计器会报错的事情 
  29.                    } 
  30.                    //… 
  31.          } 
  32.          //… 
呵呵,问题圆满解决。其实这样一个全局类在我们平时设计系统的时候会经常用到,多用于存储一些对象间的交互数据或者运行时环境参数。
如果大家有什么更好的办法解决所述问题,记得分享哦 :)

print?

以上是关于Windows 窗体设计器中的设计时错误的主要内容,如果未能解决你的问题,请参考以下文章

MFC设计器中的“无法访问ActiveX控件类型库”错误

表单设计器中的组件数组

Windows窗体设计器会破坏表单布局

在 Windows 窗体设计器中加载窗体时出现“找不到类型”错误

Visual Studio Windows 窗体设计器错误:“构建框架内容失败。”

Windows 窗体设计器 - 如何防止删除子控件