Printable View
hBrush is never assigned a value anywhere in my program. Yet the function works.Code:HBRUSH hBrush, hDfltbrush;
hDfltbrush = SelectObject(hDc, GetStockObject(DC_BRUSH));
void updateclient(void)
{
static PAINTSTRUCT ps;
SetDCBrushColor(hDc, 0x000000);
BeginPaint(hWnd, &ps);
FillRect(hDc, &ps.rcPaint, hBrush);
EndPaint(hWnd, &ps);
}
SelectObject(hDc, hDfltbrush);
Is the hBrush argument ignored with stock objects?
There is a difference between 'working' and 'undefined behaviour returning the right result on this occasion'.
The difference is that 'working' always does what you told it to but undefined behaviour does not always return the expected result.
You are probably testing in a DEBUG mode and the IDE is protecting you from your mistakes (by not selecting into the DC a unititialised GDI object).
I am asking because it could just "happen" to work now and not later.
How do I tell if I am in debug mode? I noticed it (Pelles), but wasn't using it.
Could it be that the handle for DC_BRUSH is zero, and hBrush was also zero?
I don't know the exact mechanism... you stand a better chance of seeing it in Pelles Debugger than me guessing right...
However, playing with uninitialized variables --no matter what kind, no matter where-- is playing with fire.
I once saw the perfect definition of "Undefined Behavior"...
"Your program will work perfectly until the day you show it to your boss."
I don't remember seeing this in particular described at msdn, but should I be doing this:
hBrush = GetStockObject(DC_BRUSH);
SelectObject(hDc, hBrush));
No DC_BRUSH can not be zero AND valid.Quote:
Originally Posted by megafiddle
HBRUSH is a HANDLE or pointer (memory address) so can not be NULL and valid.
In DEBUG mode (as opposed to Release mode build) the hBrush is probably initialised to NULL by the IDE.
FillRect() would call SelectObject() and probably is coded not to allow a NULL GDI object to be selected into a DC (as then the DC would throw errors when it tried to use the non existent GDI object).
BUT!Code://why is the PAINTSTUCT static?
HDC hdcPaint = BeginPaint(hWnd, &ps);
FillRect(hDc, &ps.rcPaint, hBrush);
//should be
FillRect(ps.hdc, &ps.rcPaint, GetStockObject(WHITE_BRUSH));
// or
FillRect(hdcPaint , &ps.rcPaint, GetStockObject(WHITE_BRUSH));
EndPaint(hWnd, &ps);
//then there is no need to create or clean up any GDI objects
Other events generate WM_PAINT msgs (ie another window crossing yours) with differing invalidated rects in the PAINTSTRUCT so your code will not always draw the way you expect.
What is the difference between hDc and ps.hdc? Shouldn't they have the same value?
Also would this be correct?
No reason for the static definition. Left over from something else and never fixed.Code:hBrush = GetStockObject(DC_BRUSH);
FillRect(ps.hdc, &ps.rcPaint, hBrush);
hDc appears to be a global HDC variable (but you did not show where or how you created it).Quote:
Originally Posted by megafiddle
ps.hdc is the HDC specific to this specific dialog/window/control's screen that has just been invalidated.
They probably contain different GDI objects.
Your hDc is not required and, in general, global variables are bad (or show poor design). [in some cases global varaibles are required / better, but the exception proves the rule.]
Yes, that code is the interchangeable.Quote:
Originally Posted by megafiddle
My function above is only called when a WM_PAINT is received.
Far as I can tell it works ok.
Did you mean there would be problems if it were used independantly from receiving a WM_PAINT?
Also, my hDc is a global, and it did happen to be the handle for that device context.
But how would I get it to the various functions that needed it, if it was declared in WinMain,where
it is assigned it's value?
The chain of funtion calls to the functions that require it begin in the callback procedure, WndProc.
Your global HDC will be invalid in many circumstances (ie if the window changes shape / size).Quote:
Originally Posted by megafiddle
WinMain is not the right place to create the HDC, as the window may not be full 'setup' intill the WM_CREATE / WM_INITDIALOG msg is processed (ie most windows are first created with a default size and then sent msgs to set them to the correct / desired size.)Quote:
Originally Posted by megafiddle
If you are using double buffering then you use private member variables or properties to hold the memory DC (back buffer).
Otherwise you pass the HDC into the function from your callback.
When processing a simple paint (like yours) you use the HDC in the PAINTSTRUCT or returned by the call to BeginPaint(). Note that this HDC is only valid until the call to EndPaint().
So do I need to use:
hDc = GetDC(hWnd);
or something, every time the window changes?
Does GetDC return the new and current handle?
I've been using that same global hDc for all my drawing. Would have never known,
so far, that it wasn't actually "working". I only caught the uninitialized hBrush while
looking for something else.
No.
Your current paint method does not need a HDC.
Re-read my previous posts, they show you 2 ways to get the required DC.
Definition of "Undefined Behaviour"...Quote:
Originally Posted by megafiddle
1) Code that works perfectly until someone else tries to use it.
2) Code that works perfectly until you show it to your boss.
3) Bugs and problems that only show up after you've taken delivery of 50,000 CDs.
I fixed my updateclient, using handle returned from begin paint. No problem with that. It'sQuote:
Originally Posted by novacain
about the other parts of the program that need an HDC. I use MoveTo, LineTo, SetPixel, etc
in many different parts of the program.
How do I retrieve a valid HDC to pass to these other subroutines?
You require a form of 'double buffering'Quote:
Originally Posted by megafiddle
The 'rules' are;
You have a member DC (global is normally not required and can be eliminated by better design). Generally this DC is called the 'memDC' or memory DC. Making it a member means you do not need to pass the HDC, otherwise make it static in the callback and pass into the methods.
All drawing should be done in other methods, which update your memDC and then generate a paint message.
Your paint handler should never consist of more than a single BitBlt(), where the memDC is copied to the HDC from BeginPaint() using the rect in the PAINTSTRUCT
You create memDC as a compatible DC in the WM_CREATE / WM_INITDIALOG msg and compatible bitmap.
You destroy the current bitmap and create a new bitmap the correct size in WM_SIZE msgs (coping the current one with BitBlt() or StretchBlt() as required).
You clean up the memDC in the WM_CLOSE
You generate fast paint by using InvalidateRect() followed by UpdateWindow() [this is IMPORTANT!]
You only invalidate the minimun rect required (not the entire client area).
Search my posts for actual code.
Thanks, I appreciate all the info.
I can find almost all that you mentioned at msdn. I can't find anything about "member", though.
Where can I find more info on that?
This question came up because some examples for using the GDI from msdn and other tutorials,
use the DC for the client area and do the drawing directly onto it.
Should every graphics operation happen only in a memory DC then?
Are there any cases where you can draw using the DC for the client area?
Member variables are used to provide encapsulation in C++ and C#.
Classes have 'member' variables; variables that are local to the class and are accessable in any of the classes methods / functions. [not available in C as C has no classes]
Member variables have 'global' scope within the class but are not accessable outside an instance of the class (a class variable) unless marked as 'public'.
[google 'member variable' or 'encapsulation' for more detail]
Each instance of the class has its own copy of the variable (unless the member is declared as 'static').
To answer your next question. 'Why use this feature?'
google 'inheritance in c++'
>>Are there any cases where you can draw using the DC for the client area?
Yes and no.
It all depends on the requirements of the application. If you read my posts carefully you will notice I mention your 'current paint'. This is because simple drawing (as in your example code), or drawing that does not need to be presistent, can be done in the WM_PAINT.
>>This question came up because some examples for using the GDI from msdn and other tutorials,
use the DC for the client area and do the drawing directly onto it.
These are simple examples used to show basic concepts, not actual implementations used in more complex applications.
Doing all the drawing in a memory DC does make sense. I will be converting the program over
to using this method at some point.
I am still not clear on the client area HDC becoming invalid. I see how a rectangle in the client area
becomes invalidated. But why is the handle to the client area no longer valid?
I assume you are refering to my comment;
>>You only invalidate the minimun rect required (not the entire client area).<<
By 'invalidate' I mean 'mark the rectangle for painting' (ie set it to be redrawn in the paint).
You make an area 'invalid' by calling InvalidateRect(). This generates a WM_PAINT msg for the given window (HWND) and for the given area (RECT).
You can use the whole client rect or, better, the minimum rect that includes all the changes.
When you call BeginPaint() this invalidated RECT is copied into the PAINTSTRUCT rcPaint RECT struct.
You then use the rcPaint RECT in your drawing (ie in the BitBlt())
No, I think I understand that.
I was referring to:
"Your global HDC will be invalid in many circumstances (ie if the window changes shape / size)."
The HDC in this case was the handle to the client area of my window.
In other words, does the original handle returned by:
ShowWindow(hWnd, nCmdShow);
hDc = GetDC(hWnd);
become invalid when the first WM_PAINT message is received? Or else when?
I am wondering at what point I can no longer use the handle returned by GetDC(hWnd),
and what to do if I need a handle to that window outside of BeginPaint ... EndPaint.
For example, won't I need my global hDc to release the window device context as in:
ReleaseDC(hWnd, hDc); ?
A HDC is a handle to a Device Context.
A handle is a void pointer.
A pointer is only valid if the memory pointed to has not been freed, re-alloced etc.
Why would you need to GetDC() inside a WM_PAINT?
I think you need to read exactly what BeginPaint() and GetDC() do.
I don't need that inside a WM_PANT. I am using the one returned by BeginPaint
as you recommended.
I am talking about outside a WM_PAINT. For example when terminating the program.
If my hDc can become invalid, how will ReleaseDC(hWnd, hDc); ever work?
(just added this)
If you are saying that I shouln't have to do this:
hDc = GetDC(hWnd);
And therefore wouldn't have to do this either:
ReleaseDC(hWnd, hDc);
then that makes sense.
And would that mean that sooner or later, this will fail:
hDc = GetDC(hWnd);
...
...
...
ReleaseDC(hWnd, hDc);
?
I have explained this in many threads over the last decade...which is why I told you to search my previous posts.
When you get a WM_CREATE or WM_INITDLG msg you use GetDC() to get a pointer to the main screen's DC.
You create compatible DC and bitmap, saving the 1x1 monochrome bitmap originally in the created DC but 'pushed' out by you selecting in the created bitmap.
You ReleaseDC()
This means your GetDC() is guaranteed to retain scope, as it's scope is very limited (and not global for the life of the app as you are trying to do).
You use the compatible DC anywhere you need to do drawing and then generate a paint msg.
You BitBlt() the compatible DC to the PAINTSTRUCT DC in a WM_PAINT
You SelectObject() the orig bitmap into the created DC, then delete the bitmap and DC, when you get a WM_CLOSE.
Search for code on what to do when you get a WM_SIZE.
Thanks again.
I do intend to incorporate your suggestions and recommendations.
I have been trying to search, but the searcher is turning up nothing.
Anyway I have attached my source code in the C programming section, "large number variables...",
although i haven't added any of the things you recommended yet.