|
You're causing recursive repeated calls to OnDraw() by calling InvalidateRect()
from within OnDraw(). That'll certainly slow things down
gurucplusplus wrote: What is the better way of display text without calling InvalidateRect()
Don't call InvalidateRect()!
Mark
-- modified at 14:29 Thursday 7th June, 2007
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
How can I update this text to graphic without calling invalidateRect()?
|
|
|
|
|
When you call DrawText, you ARE updating the text.
You use Invalidate methods to force a repaint from outside of OnPaint/OnDraw.
For example, if the text you are drawing changes as the result of some process in the application
and you want the window updated to reflect the change, then you'd call Invalidate. This will
mark the given area of the window as invalid. On the next WM_PAINT message (which will call
OnDraw() for CViews) you will call DrawText() with the updated text.
I hope that made sense
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
So, If my text drawn changes I have to call invalidateRect to mark invalid for the next WM_PAINT message to update the text. Where should I call invalidaterect then? Not in ondraw()? thanks
|
|
|
|
|
gurucplusplus wrote: If my text drawn changes I have to call invalidateRect to mark invalid for the next WM_PAINT message to update the text. Where should I call invalidaterect then?
Right. If the text characters never change (like pDC->DrawText("Text") then there's no reason
to ever call InvalidateRect() because every time the window needs repainting the text will
just be redrawn.
Now suppose you are drawing the text of a string that changes (pDC->DrawText(str)). The user
does something that causes the value of str to change and you want to reflect that change in the
window. Any time after you change str, call InvalidateRect() to mark the area as invalid. When
the resulting WM_PAINT is received by the window, CView::OnPaint() will call OnDraw(). In your
OnDraw() override, you call pDC->DrawText(str), drawing the new text on the window.
Also remember, WM_PAINT messages are LOW priority (they can get bumped to the back of the message
queue). If you need an instant update, like if the text string is changing as the result of a
timer (like in a clock implementation), then you can add a call to UpdateWindow() right after
the call to InvalidateRect(). This will cause a WM_PAINT to be sent immediately.
Remember that, when responding to WM_PAINT, it is your responsibility to validate the region
of the window that is invalid to prevent repeated WM_PAINT messages. Most of the time this
is done for us by MFC or the default window message handling. So if you invalidate regions of
a window while it's trying to validate it, the WM_PAINT messages keep coming.
If you want to see the recursive action/result of doing this in your OnDraw(), try this in your
OnDraw(). This consumes all the CPU time of one of my processors and renders dialog controls
useless:
Invalidate();
UpdateWindow();
return;
I'm actually surprised it doesn't crash
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
|
|
One way is to use "command enablers"...
BEGIN_MESSAGE_MAP(CMyFrameWnd, CFrameWnd)
...
ON_UPDATE_COMMAND_UI(ID_BUTTONID, OnUpdateButton)
...
END_MESSAGE_MAP()
void CMyFrameWnd::OnUpdateButton(CCmdUI* pCmdUI)
{
if (some_condition)
pCmdUI->Enable(TRUE);
else
pCmdUI->Enable(FALSE);
}
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark thanks for reply, but I have dialog based application, there is no ON_UPDATE_COMMAND_UI
|
|
|
|
|
Then try in OnPaint.
if (condition)
button->EnableWindow (TRUE);
else
button->EnableWindow (FALSE);
is not the best way, but it will maybe work
NOTE: I have not read the article, so im not sure if I'm saying something catastrofical :P
Greetings.
--------
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
|
|
|
|
|
Well, anytime after a toolbar is created and the buttons are added to it, you can enable and
diable buttons when you need to:
// Disable a button
m_ToolBar.GetToolBarCtrl().EnableButton(ID_BUTTON1, FALSE);
// Enable a button
m_ToolBar.GetToolBarCtrl().EnableButton(ID_BUTTON1, TRUE);
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark, many thanks it works , but button was not greyed .
|
|
|
|
|
Romiks wrote: but button was not greyed
Looking at the article, it looks like there's a separate image list for disabled.
Are the images in that image list the same as the regular images?
You could try omitting the last parameter in the call to LoadTrueColorToolBar() - the system
should do its default "greying" for disabled buttons.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Mark, many thanks for help. I have tried to omit the last parameter, but it doesn't work .
I will try to use CButton instead of tool bar.
|
|
|
|
|
So the buttons diable but they don't look disabled?
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Hi Mark,
If I ommited the last parameter, buttons are not disabled.
|
|
|
|
|
I just downloaded the source - I'll take a look.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Ok..
It all works fine in the authors demo app.
The author actually omits the last parametr in the call to CTrueColorToolBar::LoadTrueColorToolBar
for the RIGHT toolbar. So, the right toolbar shows button bitmaps grayed by the system.
For the left toolbar he uses special bitmaps for disabled buttons that don't have any color,
just white/black/grays.
All the buttons except the first three on left and right are disabled. If you try to disable them
yourself they won't look any different
To enable them, you can add command enablers. For example, there's 9 buttons on the toolbars.
I enabled the 7th and 8th buttons like this (in MainFrm.cpp/.h):
afx_msg void OnUpdateButton32777(CCmdUI* pCmdUI);
afx_msg void OnUpdateButton32778(CCmdUI* pCmdUI);
ON_UPDATE_COMMAND_UI(ID_BUTTON32777, OnUpdateButton32777)
ON_UPDATE_COMMAND_UI(ID_BUTTON32778, OnUpdateButton32778)
void CMainFrame::OnUpdateButton32777(CCmdUI* pCmdUI)
{
pCmdUI->Enable(TRUE);
}
void CMainFrame::OnUpdateButton32778(CCmdUI* pCmdUI)
{
pCmdUI->Enable(TRUE);
}
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Ok...
I have dialog based MFC application
There is no ON_UPDATE_COMMAND_UI command
|
|
|
|
|
Romiks wrote: I have dialog based MFC application
Oh yeah, I forgot about that, sorry
Well I still go back to this:
// Disable button ID_BUTTON32777 in m_ToolBar
m_ToolBar.GetToolBarCtrl().EnableButton(ID_BUTTON32777, FALSE);
// Enable button ID_BUTTON32777 in m_ToolBar
m_ToolBar.GetToolBarCtrl().EnableButton(ID_BUTTON32777, TRUE);
I'm not sure why that doesn't work for you - I just tested it in a dialog toolbar here.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
If you have working dialog based project, could you please send me?
my mail:losqut@yandex.ru
As for me, buttons are not greyed
|
|
|
|
|
When using the Visual Studio Installer to create an installation, if I add a VC++ redistributable merge module (.msm) file to the solution, the installation puts the .dll(s) into the target directory.
Is there a way to have the installer put those in a subdirectory of the targetdir without having to open the .msi up with orca.exe and modifying stuff in there?
I'm trying to put those dll(s) in the equivalent of a bin directory along with my other dll(s) and ocx files.
|
|
|
|
|
While creating simple test multithreading application ,I am getting this bug.
I made function global.I dont want to declare static,I dont know whats wrong.
void CCustom1Dlg::OnButton1()
{
// TODO: Add your control notification handler code here
int m = 5;
CWinThread* tt;
tt = AfxBeginThread(Myfunc,&m,THREAD_PRIORITY_NORMAL,0,0,NULL);
}
UINT Myfunc(LPVOID pParam)
{
int* co = reinterpret_cast<int*>(pParam);
return 0;
}
Can anyone tell me,I searched many articles for bug,and all concludes that it must be
global or static,now I have global.still bug is pidding. My project settings are proper
for run time library.
|| ART OF LIVING ||
|
|
|
|
|
Do you still get the error if you declare your thread proc before the call to AfxBeginThread()?
UINT Myfunc(LPVOID pParam);
void CCustom1Dlg::OnButton1()
{
// TODO: Add your control notification handler code here
int m = 5;
CWinThread* tt;
tt = AfxBeginThread(Myfunc,&m,THREAD_PRIORITY_NORMAL,0,0,NULL);
}
UINT Myfunc(LPVOID pParam)
{
int* co = reinterpret_cast(pParam);
return 0;
}
*edit* You don't want to pass &m to your thread...m can/will go out of scope before MyFunc() uses<br />
it.
Mark
"Posting a VB.NET question in the C++ forum will end in tears." Chris Maunder
|
|
|
|
|
Looks like we posted a response at the same time
|
|
|
|