MFC中的OnTimer和SetTimer

　　有一段程序我调试了很久，直到今天一个偶然的灵感才想到问题的所在，事情是这样子的：

　　在MFC的View类里面有这么一段代码：

void CMyView::OnTimer(UINT nIDEvent) 
{
    CMyDoc* pDoc = GetDocument();

    if(pDoc->b_ShowContour)
    {
        DrawDynamicContours();
    }
    else
    {        
        boundaries.clear();
    }
    CView::OnTimer(nIDEvent);
}


void CMyView::OnInitialUpdate() 
{
    CView::OnInitialUpdate();    
    SetTimer(1,100,NULL);
}

　　此段代码的作用是用来刷新屏幕，从而达到动态显示的效果，在此程序的另一处，有一段代码，与之相呼应：

BOOL CImageProcessing::CheckMessageQueue()
{
    MSG msg;    
    while(PeekMessage(&msg,NULL,0,0,PM_REMOVE))
    { 
        if(msg.message==WM_QUIT) 
            return FALSE; 
        TranslateMessage(&msg); 
        DispatchMessage(&msg); 
    } 
    return TRUE;
}

　　即不断的获取windows的消息序列，然后执行，这样的效果就是定时器的消息将能传递过去，并且得到执行。但很神奇或者说让我很郁闷的是，居然有时候卡在消息循环里，这个问题我想了很久，并且引起win7和xp上的结果不一致。我开始以为是windows版本间的获取消息循环的不同引起的，但后来查阅各资料，发现并非如此。今天晚上，我最初想到的是时间片轮转不同，记得《编程之美》书上第一题，有一个sleep()环节，在设定sleep进行多长时间上，充分考虑到了系统的时间片对程序设定的影响，于是我开始怀疑是

void CMyView::OnInitialUpdate() 
{
    CView::OnInitialUpdate();    
    SetTimer(1,100,NULL);
}

中的 SetTier(1,100,NULL)，100ms时间可能跟系统时间片产生冲突，于是上网搜索windows的时间片长度，发现大部分说法都是20ms左右（后来发现我这个怀疑很可笑，但给了我另外的灵感），于是我又灰心了……

　　然而，后面我却想到，SetTimer设置的100ms时间进行刷新一次，如果在100ms之内OnTimer没有执行完，那会不会出现资源的抢占问题？即这边OnTimer没有执行完，SetTimer又开始调用OnTimer(这是个神马问题？)为了测试，我设定变量，统计了OnTimer里面的一次执行的时间，发现超过100ms的都会出现卡死的状态，我将

SetTimer(1,100,NULL);
        |修
        |改
        V
SetTimer(1,200,NULL);

　　结果发现之前会卡死的测试用例都不会再发生了(灰常happy~~~)，虽然不知道上述抢占函数是属于个神马问题，但起码确定了是由上述引起的问题

　　ok，解决一个大问题。