现在的位置: 首页 > 综合 > 正文

MDI窗体关闭问题解决一例

2011年09月01日 ⁄ 综合 ⁄ 共 1679字 ⁄ 字号 评论关闭

由于工作忙,很久没有来这里了,久违了。

背景:

MDI子窗体中的一个是导航窗体,该窗体定义了CLOSING事件处理:检测窗体的关闭标志是否允许,如果不允许则取消关闭操作,这样保证了导航窗体的不被关闭而永久存在。


问题:

当关闭MDI容器窗体的时候,因为其中一个子窗体的关闭事件被取消了,所以关闭动作失败,导致要关闭MDI主窗体只能通过调用Application的Exit方法来实现真正的关闭操作。

解决:

当关闭MDI子窗体的时候,由于导航窗体有关闭控制处理,可能会取消窗体的关闭操作,因此设想:在主窗体关闭的时候,设置导航窗体的关闭标志为允许关闭,这样主窗体就不会因为子窗体的关闭被取消而取消了。但实验结果是不可行:所有子窗体的CLOSING事件都在主窗体的CLOSING事件之前触发,当在主窗体进行可关闭标志的设置的时候,对主窗体已经是无效的了。感觉很沮丧,总不能让用户执行两次关闭操作吧?使用Application.Exit来处理,也感觉不理想,便采用对导航窗体的可关闭标志进行置位后再次调用关闭函数来实现。

经过跟踪处理,发现,主窗体和所有的子窗体共用同一个CLOSING事件参数(System.ComponentModel.CancelEventArgs),因此导致只要任何一个窗体(包括主窗体和子窗体)取消的关闭事件,那么整个关闭操作就失败。基于这个原因,在主窗体的CLOSING事件里面,设置CANCEL=false轻松解决问题(因为主窗体的CLOSING事件永远都是最后一个被触发)。

以上解决方案又会带来一个漏洞:除了导航窗口外,如果有其它窗体确实需要取消关闭操作将会导致失败。对于这个问题,可以采用以下两个方案处理:

1——

在主窗体的CLOSING处理中,强制CANCEL标记复位,然后执行每个子窗体是否确实允许关闭的检测再来设置CANCEL标志。

这个方案不好的地方是主窗体必须知道子窗体是否定义了指定的函数,导致主窗体对子窗体的实现类型存在依赖

2——

基于方案1中存在的问题,考虑:各子窗体是否真的可以被关闭的标志置于Tag属性中,这样,子窗体与主窗体之间只要达成这个协议就可以很好的解决这个问题。

相关代码:

子窗体Closing事件代码:

if (CanClose)

{

    
if(Tag == null)

    
{

        Tag 
= true;

    }


    
else

    
{

        ArrayList arrTmp  
= new ArrayList();

        arrTmp.Add(
true);

        arrTmp.Add(Tag);

        Tag 
= arrTmp;

    }


}



主窗体Closing事件处理代码:

e.Cancel = false;

foreach(Form frmTmp in this.MDIChildren)

{

    
if (frmTmp.Tag == null)

        
continue;

    
if(frmTmp.Tag is bool)

    
{

        
if ((bool)frmTmp.Tag))

        
{

            e.Cancel 
= true;

            
break;

        }


        frmTmp.Tag 
= null;

    }


    
if(frmTmp.Tag is ArrayList)

    
{

        ArrayList arrTmp 
= frmTmp.Tag as ArrayList;

        
if(arrTmp.Count != 2 || !(arrTmp[0is bool))

            
continue;

        frmTmp.Tag 
= arrTmp[1];

        
if((bool)arrTmp(0))

        
{

            e.Cancel 
= true;

            
break;

        }


    }


}


抱歉!评论已关闭.