|
You need to understand how WM_PAINT and OnPaint works. If you call your OnPaint at an arbitrary time what happens is it creates a CPaintDC which won't (or rather probably won't) have any invalid region in it. So all your drawing is clipped to a non-existent region and nothing appears on the screen.
Try calling Invalidate() instead of OnPaint() and see if that improves the situation. Can't remember the parameters off the top of me head so you'll have to look them up! This signals that you want to paint the whole window and will cause a redraw (i.e. your OnPaint()) will get called indirectly. When that happens CPaintDC will be set up properly.
Oh, and only have one object of type CPaintDC in a given OnPaint method, you might get some strangeness otherwise.
Cheers,
Ash
|
|
|
|
|
Arindam Tewary wrote: BOOL CKeyDownTestDlg::PreTranslateMessage(MSG* pMsg)
{
// TODO: Add your specialized code here and/or call the base class
iKeyPressed = 0;
I think the iKeyPressed = 0 in the above code is you problem. Remove it and change the following piece of code
Arindam Tewary wrote: if(iKeyPressed==1)
{
CPaintDC dc(this); // device context for painting
AfxMessageBox(_T("iKeyPressed = 1"));
dc.Rectangle(5,5,20,100);
}
This way
if(iKeyPressed==1)
{
iKeyPressed = 0
CPaintDC dc(this);
AfxMessageBox(_T("iKeyPressed = 1"));
dc.Rectangle(5,5,20,100);
}
BTW calling OnPaint directly is a bad idea: you should replace it with
InvalidateRect(...);
UpdateWindow();
sequence.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Thanks Mr. Palini for reply.
I just started VC++ MFC couple of days back. I am still not very much comfortable in it after comming from C# background. So I directly called that OnPaint method. I would keep learning about it in comming days for sure.
I used your suggestion but still it does not repaint it. . Any other idea sir?
Thanks,
Arindam D Tewary
|
|
|
|
|
You should remove the Message Boxes calls to see it.
Also you're using too many device contexts in OnPaint .
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Hi All,
How to catch the new allocation failure exception in MFC
I am using CMemoryException but it is not catching.
I am using bad_alloc exception that also it is not catching.
|
|
|
|
|
With ellipsis you can catch all exceptions, if you are not sure about exception type:
catch (...) {
}
--
"Programming is an art that fights back!"
|
|
|
|
|
|
You are welcome!!
--
"Programming is an art that fights back!"
|
|
|
|
|
Here's a question to consider...
If you're not catching the exception, how do you know it's being thrown? Are you sure it's a memory allocation failure or could it be something else?
Cheers,
Ash
PS: Okay, that was two questions...
PPS: Just out of interest, where are you trying to handle the exception that may or may not have happened? You shouldn't throw exceptions through DLLs supplied by the operating system, so make sure you're trying the catch around all your window procedures or message handlers.
|
|
|
|
|
|
Okay, so what exception is being thrown and what effects does it have on the rest of your program? After the exception has been thrown are you sure you can carry on?
There's really only two uses for catch(...):
- Right at the top of main to make sure you report something's happened, you've got no idea what but you're telling the maintenance programmer they're in for a long slog sorting it out
- At the boundary of a subsystem and you want to convert something catastrophic into something slightly less catastrophic so the program can gracefully(ish) bail out with an error message
Ash
|
|
|
|
|
I want to catch that exception.
So that it should not give outofmemory messagebox.
Temporarly I will continue
but later (afer few days ) I will try to stop that exception.
Now I am doing some other thing.
I Will meet you again.
thank you
|
|
|
|
|
catch (...) is the wrong way to go about displaying an out of memory dialog box since it will catch all exceptions including ones that don't indicate allocation failure.
Steve
|
|
|
|
|
when the context menu is dismissed my application takes a long time to redraw the area that was obscured by the menu. Can anyone give solution to this.
|
|
|
|
|
Continue the other thread you started. You can add more info to that instead of opening a new one.
|
|
|
|
|
|
You waited 89 minutes before posting the same question again. Why so impatient? This forum is read by folks from around the globe. Give them a chance to see your question before reposting.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
I am trying to compile code that has worked previously, but I am getting the error cannot convert from '__missing_type__ *' to '__missing_type__'.
The code is #import "C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\vbe6ext.olb"
Any idea how I might fix the problem?
|
|
|
|
|
Hi
The project i am working currently draws collection of bitmaps in to screen. In the client area in some point
it display a context menu on the screen. But once the popup menu is dropped and disappear , it taking more time to redraw the bitmaps. It happens only to context menu portion.Also if it runs for 24 hours the delay is increasing.l
Thanks in advance.
|
|
|
|
|
You should post the relevant (drawing) code, I guess...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I'm not exactly sure what you're asking. Are you saying that when the context menu is dismissed it takes your application a long time to redraw the area that was obscured by the menu?
Steve
|
|
|
|
|
Exactly. But the other portions are ok.
|
|
|
|
|
I assume you're drawing in your WM_PAINT[^] handler?
Steve
|
|
|
|
|
How r u drawing the bitmaps? Call the InvalidateRect() function when the pop-up menu is exiting. Post us code for more clarity
|
|
|
|
|
Hi all,
I'm currently working on a program in C for a Win32 App where my parent window and its children have been created programmatically using CreateWindowEx(). I've set the extended style for the parent window to WS_EX_CONTROLPARENT and its children (edit controls) style to WS_CHILD | WS_TABSTOP, but no matter what I do, when I click inside the first edit control, type in the value, and then press TAB, the focus does not shift to the next window with WS_TABSTOP. Am I missing something here? The way I understood it, these two styles were all I would need, yet I am still unable to shift the focus from one edit control to the next.
All help is welcome. Thanks in advance.
|
|
|
|