Jump to content

  • Log In with Google      Sign In   
  • Create Account


My custom WIN32 framework


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
5 replies to this topic

#1 GlenDC   Members   -  Reputation: 543

Like
0Likes
Like

Posted 06 September 2012 - 05:51 AM

Hi everyone, I believe this is my first topic, created by me. Helping people gives me great joy, but sadly enough I have a problem of my own at the moment, which I'm unable to solve. The solution is probably very simple and/or my mistakes are probably something stupid. But somehow I can't solve it. So that's why I need you guys! I still suck at expressing myself in English, I apologize for this. I'm working on it by speaking and writing it regularly, helping people at Gamedev and writing blog posts on my website.

In my University College we work via DirectX and WIN32 for our Windows PC Games. ( For some project we work with XNA, which enables us to create Xbox360 games). For my private windows projects I'm creating a WIN32 API based framework. So what do I already have and how do I do certain things?
  • Create very fast a win32 application with custom style settings, windows class settings, window general settings, etc...
  • Draw simple geometrical figures(normal or filled), polygons. Normal or filled), lines, etc...
  • Change window application settings dynamically at runtime
  • Draw Text
  • I paint everything via the Double buffering concept. I got that concept from here. I made some changes to it and extended it, thanks to the help of my prof.
Now what are my problems?
  • When I start the application the menu is hidden by default, it is only when I resize my window that the menu appears. From then on the menu stays as well.
  • After a short period, between 30 and 40 seconds, my entire window ( client rect + caption + ... ) gets filled with a static gray color. So the entire window is just that gray color. Nothing is disabled nor painted. So for example, you can still click the close (cross at the top right corner ) button to close the application.
Because of the size of my framework, and the many files + my own library (which is getting quite big) it is impossible to upload all my code. Here you can see the code which paints everything. If something is unclear or if you need more code related to a specific action, then please ask it. I'm trying to be as clear as possible.
Code from my WinMain part:
//..... a lot of code lines
//.... WinMain() {
//.....some code lines
#pragma warning ( disable : 4127 )
    while(true)
{
  if (PeekMessage(&msg, nullptr, 0, 0, PM_REMOVE))
  {
   // Process the message
   if (msg.message == WM_QUIT) break;
   TranslateMessage(&msg);
   DispatchMessage(&msg);
  }
  else // Game Cycle / OpenGl Cycle / DirectX Cycle
  {
   if(!WinEngine::GetSingleton()->GetSleep() && _bAppLoop_) //win engine aint sleeping
   {
    // Make sure the game engine isn't sleeping
    //Tick timing is independent from Paint timing
    _swpAppTimer_->Tick();
    double tickTimeNow = _swpAppTimer_->GetAppTime();
    if( tickTimeNow > GetFrameRate())
    {
	 //.... Keyboard stuff
	 RECT rect;
	 HDC hDC = GetDC(_hWND_);
	 GetClientRect(_hWND_, &rect);
	 //Double buffering code (c) Kevin Hoefman
	 HDC hBufferDC = CreateCompatibleDC(hDC);
	 //Create the bufffer
	 HBITMAP hBufferBmp = CreateCompatibleBitmap(hDC, GetWindowWidth(), GetWindowHeight());
	 HBITMAP hOldBmp = (HBITMAP) SelectObject(hBufferDC, hBufferBmp);
	 // user defined drawning
	 _hDC_ = hBufferDC;
	 _bIsDoubleBuffering_ = true;
	 _pApp_->AppTick(tickTimeNow);
	 _fpspApp_->Tick(tickTimeNow); // FPS timer...
	 UserPaint();
	 //UserPaint();
	 _bIsDoubleBuffering_ = false;
	 // As a last step copy the memdc to the hdc
	 BitBlt(hDC, 0, 0, _iWinWidth_, _iWinHeight_, hBufferDC, 0, 0, SRCCOPY);
	 //reset the old bmp of the buffer
	 SelectObject(hBufferDC,hOldBmp);
	 //kill the buffer
	 DeleteObject(hBufferBmp);
	 DeleteDC(hBufferDC);
	 //Release DC
	 ReleaseDC(_hWND_, _hDC_);
	 //reset Timer
	 _swpAppTimer_->Reset();
	 _swpAppTimer_->Start();
    }
    else
	 Sleep(1); // if no cpu cycle has ellpases sleep than for 1 ms
	    // doing this prevent the loop from hogging the cpu hog
   }
   else
    WaitMessage(); // If sleeping or if looping is disabled we just
	    // handle the window messages...
  }
}
#pragma warning ( default : 4127 )
//..... some code lines
// } // WinMain closes
//..... a lot of code lines

code from in my WM_PAINT message in my WndProc function
case WM_PAINT:
​//..... a lot of code
// .... WndProc {
// .. some code
   GetClientRect(_hWND_, &rect);
   nw = rect.right-rect.left; // new main window width
   nh = rect.bottom-rect.top; // new main window height
   if(_bDoubleBuffering_ == false)  //Single Buffer
   {
    _hDC_ = BeginPaint (hwnd, &ps);
    _bIsPainting_ = true;
    UserPaint();
    PaintRatioBorders(rect);
    _bIsPainting_ = false;
    EndPaint (hwnd, &ps);
   }
   else	    //Double buffer
   //http://www.gamedev.net/topic/411559-win32-double-buffering/
   {
    hdc = BeginPaint(hwnd,&ps);
  
    _hDC_ = CreateCompatibleDC(_hDC_);
    bitmap = CreateCompatibleBitmap(hdc,nw,nh);
    hOldBmp = (HBITMAP) SelectObject(_hDC_,bitmap);
    _bIsPainting_ = true;
    UserPaint();
    PaintRatioBorders(rect);
    _bIsPainting_ = false;
    BitBlt(hdc, 0, 0, nw, nh, _hDC_, 0, 0, SRCCOPY); // copy the memdc to the hdc
    SelectObject(_hDC_, hOldBmp); // reset old buffer.OldBMP
    // Kill buffer
    DeleteObject(bitmap);
    DeleteDC(_hDC_);
    // End paint
    EndPaint(_hWND_,&ps);
   }
   return 0;
// some code
// } // WndProc closes
//... a lot of code

Here you see what I mean with the second problem. (The problem which specifies that everything gets gray after a short period of running time ).
Posted Image
I hope you guys can help me. Thanks already for your time!

Sponsor:

#2 Aardvajk   Crossbones+   -  Reputation: 5268

Like
2Likes
Like

Posted 06 September 2012 - 06:46 AM

I've had that gray issue before when I was leaking GDI resources. After a while, the program would exhaust the supply of GDI resources from the kernel and gray out like that. Have a look at your program in Task Manager with the GDI objects column enabled - see if this number keeps increasing. If so, you have a GDI leak somewhere.

Hard to say on the menu, need to see how you are creating the menu and displaying it, or your code to register your window class if you are loading the menu from a resource.

#3 GlenDC   Members   -  Reputation: 543

Like
0Likes
Like

Posted 06 September 2012 - 07:18 AM

Hard to say on the menu, need to see how you are creating the menu and displaying it, or your code to register your window class if you are loading the menu from a resource.


Code in the WinMain function:
if(_bWinMenu_ == true && _vMenuContainer_.size() > 0) // Menu
  _hMenu_ = CreateMenu();

Code in my WM_CREATE handling in the WndProc function

//... a lot of code
// ... WM_CREATE:
// ... some code
if(_bWinMenu_ == true && _vMenuContainer_.size() > 0) // Menu + submenus, if wanted
   {
    std::for_each(_vMenuContainer_.begin() // Add all menu's in container via the CreatMenu() void function
	    ,_vMenuContainer_.end()
	    ,CreateNewMenu);
    SetMenu(_hWND_,_hMenu_);
   }
// ... some code
// .. break; // end WM_CREATE
// ..a lot of code

The CreateNewMenu function:

void CreateNewMenu(_sMenu & menu)
{
HMENU nMenu = CreatePopupMenu(); // new menu
if(menu.itemlist.size() > 0 )  // if there are subItems
{
  for ( auto it = menu.itemlist.begin()  // Create every submenu
   ; it != menu.itemlist.end() ; ++it )
  {
  
   HMENU subMenu = CreateMenu();
   AppendMenu ( nMenu, (*it).wFlags, (WORD)subMenu, (*it).tsTitle.c_str());
  }
}
AppendMenu(WIN_ENGINE->_hMenu_,MF_STRING | MF_POPUP,(WORD)nMenu,menu._tsMenuTitle.c_str());
}

The info gets passed and filled in by custom things in my framework, but I do nothing specific to windows there. So not really important to show all that code.

Here is the code where I create the windows class:
void WinEngine::InitiateWindow()
{
_hWND_ = CreateWindow (  _tsAppTitle_.c_str(),	  // window class name
	    _tsWinCaption_.c_str(),  // window caption
	    _lWindowStyle_,  // window style
	    CW_USEDEFAULT,			  // initial x position
	    CW_USEDEFAULT,			  // initial y position
	    _iWinWidth_,    // initial x size
	    _iWinHeight_,    // initial y size
	    nullptr,				    // parent window handle
	    _hMenu_,	 // window menu handle
	    _hMainInstance_,   // program instance handle
	    (DWORD)0);	 // creation parameters
}

I hope this enables you to check the menu problem.

#4 Aardvajk   Crossbones+   -  Reputation: 5268

Like
3Likes
Like

Posted 06 September 2012 - 07:36 AM

Dunno. There's no point passing the menu pointer into CreateWindow if you are then going to call SetMenu directly. Maybe that is confusing it. Or maybe WM_CREATE is not a safe place to call SetMenu.

I'd try populating your menu in WinMain before you create the window then just passing the menu into CreateWindow. Get rid of the code in WM_CREATE. Just speculating here though.

#5 GlenDC   Members   -  Reputation: 543

Like
0Likes
Like

Posted 06 September 2012 - 09:05 AM

Aardvajk, you nailed both problems.
I have indeed 2 resource leaks, one device context handle and one Brush Handle. I already found the HDC (forgot to delete a certain HDC), still searching the brush.
Btw I also found this free 3rd party application. It enables you to see the addresses and specific GDCI objects.

I fixed the menu by moving the code from WM_CREATE to my WinMain, just like you said. That solution worked perfectly. Thank you for finding these 2 problems so fast.
Can I re-use this topic later, if I bump into new problems regarding my custom win32 framework? Or should I make a new topic for new problems?

[EDIT] I found the Brush leak. Often I used CreateSolidBrush() as a parameter for a certain windows function. By doing this I was unable to delete the brush. I fixed this problem by creating a HBRUSH object and assigning the CreateSolidBrusH() to that local variable, Than I use that local variable in the scope of the function. near the end of the scope of the function I delete the HBRUSH object via DeleteObject(). Now my application is free from leakage. Thx again Aardvajk you really made my day. My framework is really getting awesome and it is now bug free thanks to you. You're my hero of the day :)

Edited by GlenDC, 06 September 2012 - 09:45 AM.


#6 Aardvajk   Crossbones+   -  Reputation: 5268

Like
0Likes
Like

Posted 07 September 2012 - 06:23 AM

Aardvajk, you nailed both problems.
I have indeed 2 resource leaks, one device context handle and one Brush Handle. I already found the HDC (forgot to delete a certain HDC), still searching the brush.
Btw I also found this free 3rd party application. It enables you to see the addresses and specific GDCI objects.

I fixed the menu by moving the code from WM_CREATE to my WinMain, just like you said. That solution worked perfectly. Thank you for finding these 2 problems so fast.
Can I re-use this topic later, if I bump into new problems regarding my custom win32 framework? Or should I make a new topic for new problems?


Normally best form to create a new thread for a new topic, increases the chances that someone knowledgeable about the subject or seeking a similar answer will find it.

[EDIT] I found the Brush leak. Often I used CreateSolidBrush() as a parameter for a certain windows function. By doing this I was unable to delete the brush. I fixed this problem by creating a HBRUSH object and assigning the CreateSolidBrusH() to that local variable, Than I use that local variable in the scope of the function. near the end of the scope of the function I delete the HBRUSH object via DeleteObject(). Now my application is free from leakage. Thx again Aardvajk you really made my day. My framework is really getting awesome and it is now bug free thanks to you. You're my hero of the day Posted Image


Yeah, GDI is a pain like that. Maybe you could look into using GDI+ is you are sticking with Win32? As well as providing more functionality, it provides a C++ wrapper around the library that frees you up from a lot of this sort of pain.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS