Window and Taskbar becomes unresponsive

**NightCode** · 12-12-2009

I have made a RPC server that displays that status of what the client is doing with the application. The RPC server is a simple windows app that draw the text with DrawText along with the task bar icon display a 'busy status' that show a spinning icon to indicate that the client is doing something.

After awhile the windows app will just stop being responsive and the taskbar icon will disappear. The menu bar will also become unusable. I'm not sure what's going on since there are no memory leaks.

Is the issue would be that there is too many WM_PAINT occurring? The client send a text to the server and it can call "UpdateStatus" to tell the server that it need to display the information in the windows app. The server will call "InvalidateRect(m_hWnd, NULL, TRUE);" since the server doesn't know exactly how much string need to be redrawn on the window so I just invalidate all of the window so that the WM_PAINT will get sent to my windows callback and then I just call my "CServer::Paint()".

Code:

void CServer::Paint(void)
{
    RECT        rt;
    HDC         hdc;
    LOGFONT     lf;
    PAINTSTRUCT ps;
    wstring     wstr;

    wstr = GetStatus();

    hdc = BeginPaint(m_hWnd, &ps);

    SelectObject(hdc, GetStockObject(DEFAULT_GUI_FONT));

    GetClientRect(m_hWnd, &rt);

    DrawText(hdc, wstr.c_str(), wstr.length(), &rt, DT_LEFT);

    DeleteObject(SelectObject(hdc, CreateFontIndirect(&lf)));

    EndPaint(m_hWnd, &ps);

    return;
}

**novacain** · 12-13-2009

You are leaking GDIs.

In Taskmanager, select 'View', then 'Select Columns'. Check 'GDI Objects' and run your app, look for a leak (comment out the paint).

The reason is that you have to return the DC back to the default state and you can not delete STOCK GDI objects (though usually nothing bad happens).

Also CreateFontIndirect() is probably failing to create a font based on an uninitialzed structure.

SelectObject() 'pushes' out the current/default object and you should 'catch' it and put it back when you clean up.

Code:

//not at a complier so my not be 100% bug free

//change the font, but catch default
HFONT *hOriginalFont = (HFONT*)SelectObject(hdc, SomeFont); 

//draw

//clean up font
SelectObject(hdc, hOriginalFont); //put the DC back teh way we got it
DeleteObject(SomeFont);//delete any GDI we got from a CreateXXX()

//If we used GetDC() call ReleaseDC()

The DC will also probably already contain the default GUI font (the paint DC has the windows current brush, pen, font etc)
Have a look at FillRect() to clear previous text.
I would also be worried if GetStatus() is a long process.

It might be better to have some pump looking for status changes. This is because paint has to be as fast as possible and can be called repeatedly by the OS. (Drag a msgbox over your app and see if it 'shears')

Code:

wstr = GetStatus();
if(wstr != m_wstrCurrentStatus)//see if status changed
{
     //set member string
     m_wstrCurrentStatus = wstr;
     //send a paint msg
     InvalidateRect(m_hWnd, NULL, FALSE);
     //send direct to callback for faster response
     UpdateWindow(m_hWnd);
}

in paint just use m_wstrCurrentStatus in Drawtext() (instead of calling GetStatus() )

**NightCode** · 12-13-2009

It was DeleteObject(SelectObject(hdc, CreateFontIndirect(&lf))); that was leaking the GDIs, never thought of checking that before. And also you mentioned that lf was not initialized and that line should have been removed since I was doing other things and decided not to use lf.

Now my window is running much better.

As for the SelectObject, is it okay that I remember the font handle as in

Code:

if (m_hOriginalFont == NULL) {
    m_hOriginalFont = (HFONT*)SelectObject(hdc, SomeFont); 
}

And never delete it until the application is exiting?

**novacain** · 12-13-2009

No, not in this case.

You do not keep/get the same HDC each paint msg.

BeginPaint() returns the HDC, EndPaint() cleans up the GDI, including releaseing/deleting the HDC.

If you had called CreateCompatibleDC() and saved the HDC (for the same time as the font) as a member, then yes.

I suggest you move towards the 'pump' I suggested (paint msg handler contains as little code as possible).
When any of your app is covered by another window a paint msg will be called from the OS, so GetStatus() will be called, many times per second (and not just when you want it to). Windows has some protection against this (paint msgs are merged in the msg queue) but you will see 'shearing' if GetStatus() takes more than a few millisec.

That pattern will save you headaches in the future.

**NightCode** · 12-14-2009

I moved the GetStatus to the CServer::RunStatusUpdate thread that was forcing the WM_PAINT. CServer::Paint() should be faster.

Thread: Window and Taskbar becomes unresponsive

Thread Tools

Search Thread

Display

Window and Taskbar becomes unresponsive

Similar Threads

WM_CAPTION causing CreateWindowEx() to fail.

Getting all window handles on taskbar

Making dialog box the only window

Create window without taskbar icon?

Winamp Vis if anyone can help