|
|
Yeah, it works.
But the bmp must be an external file, what if I want to load a resource?.
I look into your CPintureWindow::Load() function and you always wait for a file path. Is there a chance to change this?, (maybe adding an overloaded Load() function receiving a ID resource).
I could load the bitmap resource and then create the bmp file in some folder and use that path, but I don't like all this stuff.
Beside that, your CPictureWindow is very usefull, really, it's simple and great!.
Thank you very much.
Demian.
"I have always wished that my computer would be as easy to use as my
telephone. My wish has come true. I no longer know how to use my telephone."
-Bjarne Stroustrup, computer science professor, designer of C++
programming language (1950- )
|
|
|
|
|
Did you try WM_ERASEBKGND what 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
|
|
|
|
|