|
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
|
|
|
|
|
If the stack goes to crap, the rest of your application is screwed. It wouldn't matter what data you were trying to store, it would be junk.
Generally, stack overruns are a sign of buggy code and poor implementations (or that you are forcing the stack size to be too small). There are rare occassions (mostly on embedded systems) that have issues with stack overruns, but even that is fairly rare these days. For guidelines on writing robust code, check out "Effective C++" (3rd ed) and "Effective STL" by Scott Meyers, and "Exceptional C++" by Herb Sutter. Those 3 books are invaluable.
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
|
|
|
|
|
It's technically possible to recover from a stack overflow but extremely low level. It would involve more machine code then C/C++.
Steve
|
|
|
|
|
risingtechie wrote: Is there anyway to handle stack over flow without using windows exceptions?
When you run out of stack space, you'll end up trying to write to the guard page that's set up just beyond the end of the stack. This is what triggers the Stack Overflow exception, and any chance you have of handling it is going to have to work with SEH in some way, because that's how Windows does it. (yeah, you could probably write your own stack code, and compiler to go with it... but that's getting a bit excessive)
Handling the Stack Overflow exception is tricky - there's little or no stack left, so calling any methods will likely fail (the sort of failure where it's impossible for the OS to do anything but terminate the app and move on). If you really, really need it to work, you can use SEH or XP's Vectored Exception Handler support to catch the exception, and then immediately switch to another stack.
This is... decidedly non-trivial. And as Zac mentioned, if you're overflowing the stack, you probably have other problems with your program. There will be very little you can do to salvage the situation.
If you have the need for a system tolerant of such errors, you'll probably be better off using a separate watchdog program to monitor the main app, and restart it when things go wrong.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
