|
Did you try WM_ERASEBKGNDwhat happens?
|
|
|
|
|
|
I glad you find your answer.
|
|
|
|
|
Hi,
After creating a button for a toolbar on the OnCreate msg handler, I need to include a bitmap to the ie toolbar. However, after receiving a WM_PAINT message, the button disappears, even if I do nothing inside the OnPaint msg handler, like:
<br />
<br />
LRESULT CMFToolbar::OnPaint(UINT uMsg,WPARAM wParam, LPARAM lParam, BOOL& bHandled)<br />
{<br />
::OutputDebugString("WM_PAINT");<br />
<br />
PAINTSTRUCT ps;<br />
<br />
HDC hdc = ::BeginPaint(m_hWnd,&ps);<br />
::EndPaint(m_hWnd,&ps);<br />
<br />
return 0;<br />
<br />
}<br />
and I just can't make it appear again, but it is still there, it is "clickable", but not visible.
Anyone???
|
|
|
|
|
Are you really using MFC...? 
--
The Show That Watches Back
|
|
|
|
|
IS your erase background message also being called ? What if you invalidate the button in your paint handler ( although that should happen by itself ) ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
I tried
<br />
::InvalidateRect(m_hWnd,&btnRect,TRUE);<br />
inside the OnPaint and just before the
<br />
HDC hdc = ::BeginPaint(m_hWnd,&ps);<br />
but the button is still not showing. I also tried, inside the HDC hdc = ::BeginPaint(m_hWnd,&ps); setting the background to TRANSPARENT, but...
The button is created inside OnCreate with
<br />
TBBUTTON Button;<br />
ZeroMemory((void*)&Button, sizeof(TBBUTTON));<br />
Button.idCommand = IDM_GETQUOTE;<br />
Button.fsState = TBSTATE_ENABLED;<br />
Button.fsStyle = BTNS_BUTTON | BTNS_AUTOSIZE | BTNS_SHOWTEXT;<br />
Button.dwData = 0;<br />
Button.iString = iIndex;<br />
Button.iBitmap = 0;<br />
::SendMessage(m_hWnd, TB_INSERTBUTTON, 0, (LPARAM)&Button);<br />
I also tried, inside OnPaint to send a message
<br />
::SendMessage(m_hWnd, TB_HIDEBUTTON, 0, (LPARAM)FALSE);<br />
but... 
|
|
|
|
|
Hi,
I managed to make the button appear, but I had to make it HIDDEN and then UNHIDE it, with the following code:
<br />
LRESULT CMFToolbar::OnPaint(UINT uMsg,WPARAM wParam, LPARAM lParam, BOOL& bHandled)<br />
{<br />
::OutputDebugString("WM_PAINT");<br />
<br />
PAINTSTRUCT ps;<br />
<br />
bHandled = FALSE;<br />
::SendMessage(m_hWnd, TB_HIDEBUTTON, IDM_GETQUOTE, (LPARAM)TRUE);<br />
<br />
HDC hdc = ::BeginPaint(m_hWnd,&ps);<br />
::SendMessage(m_hWnd, TB_HIDEBUTTON, IDM_GETQUOTE, (LPARAM)FALSE);<br />
HDC hdcMem=::CreateCompatibleDC(NULL);<br />
<br />
HBITMAP hBitMem = SelectBitmap(hdcMem,hBitmap);<br />
<br />
BITMAP bm;<br />
<br />
GetObject((HGDIOBJ)hBitmap,sizeof(bm),&bm);<br />
<br />
BitBlt(hdc,0,0,bm.bmWidth,bm.bmHeight,hdcMem,0,0,SRCCOPY);<br />
<br />
SelectBitmap(hdcMem,hBitMem);<br />
<br />
DeleteDC(hdcMem);<br />
::EndPaint(m_hWnd,&ps);<br />
return 0;<br />
but, like this, the bitmap disappears. However, if I comment the line
<br />
::SendMessage(m_hWnd, TB_HIDEBUTTON, IDM_GETQUOTE, (LPARAM)FALSE);<br />
then the bitmap appears but the button disappears... how confusing is this??
|
|
|
|
|
This is overkill, and likely to cause problems. Don't go that way.
|
|
|
|
|
mfranco_neto wrote: HDC hdc = ::BeginPaint(m_hWnd,&ps);
BeginPaint() erases the update region. So unless your window class is set up to clip child windows, you'll draw over them (though they should subsequently be getting their own WM_PAINT messages).
See:
BeginPaint()[^] - MSDN.
Guide to Win32 Paint[^] - Paul Watt
|
|
|
|
|
I have a main dialog app. I would like that on start up of that app, the app would go through the ::onInitDialog() to display the main app, however, it is at this point that i would like to pop up another dialog. I can't seem to find where the program control will go next. Where can i place that second dialog code to pop up automatically after the main dialog is up?
|
|
|
|
|
WM_SHOW is a likely candidate - when your parent dialog is first visible.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Where would i check for MW_SHOW?
|
|
|
|
|
I take it back, it's WM_SHOWWINDOW. That's a windows message, which is what your command handlers like OnInitDialog handle. So, look for an OnShowWindow handler, or something like that. In VC6, it actually says the message, WM_SHOWWINDOW.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
well what i get from query all you need to do is use the Create method in the dialog class
something like this...
<br />
void OnInitDialog()<br />
{<br />
pPopUp = new CDialog;<br />
pPopUp->Create(IDD_DIALOG1,this);<br />
pPopUp->ShowWindow(SW_SHOW);<br />
}<br />
cheers
Sky is the limit 
|
|
|
|
|
This ShowWindow function works well, however is there any way to make the second dlg be the focus and nothing can be done on the first dialog unless a choice is made on the second dialog?
|
|
|
|
|
LCI wrote: This ShowWindow function works well, however is there any way to make the second dlg be the focus and nothing can be done on the first dialog unless a choice is made on the second dialog?
Modeless window, so call .DoModal() instead of ShowWindow().
if(IDOK == dlg.DoModal())
{
// OK was returned from child modal window
}
else
{
// Cancel was clicked (IDCANCEL)
}
I'd love to help, but unfortunatley I have prior commitments monitoring the length of my grass. :Andrew Bleakley:
|
|
|
|
|
http://functionx.com/visualc/howto/calldlgfromdlg.htm
plz search this link it will help u and u understand how we call one dialog to another
|
|
|
|
|
LCI wrote: ...at this point that i would like to pop up another dialog. I can't seem to find where the program control will go next.
That all depends on whether the second dialog is modal or modeless.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
|
Then control will naturally go to the second dialog's OnInitDialog() method. Control will not return to the first dialog until the second dialog has been dismissed.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Every program has the potential to run out of stack space. The following does so on purpose. I'm using Borland C++ Builder 5.5 and it doesn't throw an exception for stack overflows. I think Visual C++ does but it's using SEH, (not C++ exception handling), which is also not available in Borland C++ Builder. The program below just terminates after the stack overflows. The error message ("An exception was thrown. Probably out of stack space.") never prints. Is there anyway to handle stack over flow without using windows exceptions? Is it even possible to recover from a stack overflow? Any help would be appreciated.
<br />
#include <iostream.h><br />
<br />
void StackOverflow(int depth)<br />
{<br />
try<br />
{<br />
char blockdata[10000];<br />
cout << "Overflow: " << depth;<br />
StackOverflow(depth+1);<br />
}<br />
catch (...)<br />
{<br />
cout << "An exception was thrown. Probably out of stack space." << endl;<br />
}<br />
}<br />
<br />
<br />
int main(<br />
{<br />
StackOverflow(0);<br />
return 0;<br />
}<br />
-- modified at 16:59 Wednesday 27th September, 2006
|
|
|
|
|
risingtechie wrote: Is it even possible to recover from a stack overflow?
Not really. When you think about it, using exceptions would require placing more items on the stack, calling a function to clean up the stack would also require putting items on the stack first. Basically, once the stack overruns the heap, you are screwed.
However, this should rarely happen with the amount of memory applications are afforded in systems these days. Generally, when it does, it is a sign of a bug (like the code you posted shows).
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Thanks Zac,
What if this error happens during an operation that must be completed in it’s entirety or else something catastrophic happens. For example, maybe some massive amount of invaluable, irreplaceable data on secondary storage (like the U.S. Treasury's database mapping bond holder names to bond serial numbers) was being manipulated and becomes corrupted rendering it practically indecipherable. So, even though the risk of a stack overflow is minimal, let's say it's still too likely for comfort. I guess your only option is to keep regular backups and simply design your code in such a way that a stack over flow and any other unpredictable event that may occur doesn't cause any catastrophic loss. Am I correct in thinking this? I may sound like I'm being petty but I'm really just trying to live up to the highest standards of professional, robust, and secure software development. I guess I just don't know for sure what the limits are to how robust an application is expected to be. This issue is a constant thorn in my side.
|
|
|
|
|
Any recursive function will have a maximum depth possible. I would tend to ask design questions like 'what's the maximum value I could be passed here', then engineer it using values that will go twice as deep. That seems to me a reasonable margin for error.
The other thing is, don't use recursion unless it really makes sense to do so.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
