|
|
|
thanks, I'll have a look when I get a moment.
Cheers,
Ash
|
|
|
|
|
Hi,
I am using SelectObject() in my code but confused with the MSDN description.
CFont font;
font.CreateFont(-12, 0, 0, 0, 400, FALSE, TRUE, FALSE, ANSI_CHARSET, OUT_CHARACTER_PRECIS, CLIP_CHARACTER_PRECIS, DEFAULT_QUALITY, FIXED_PITCH | FF_MODERN, _T("Courier New"));
CFont* oldFont = pdc->SelectObject(font);
pdc->TextOut(0, 0, str);
pdc->SelectObject(oldFont);
font.DeleteObject();
As per MSDN we should not use the object return by SelectObject because it is a temporary one.
But if we are restoring the old GDI object in the above way will it cause any problem
because the same dc can be used in some other place.
|
|
|
|
|
MSDN says:
This function may return a pointer to a temporary object. This temporary object is only valid during the processing of one Windows message.
So, it is ok to replace the selected object by the previous object like you did in your case.
|
|
|
|
|
Thanks for the reply. But if i want to use the same DC after this call wiil it be ok.
|
|
|
|
|
You can reuse the device-context how many times you want. The only thing you should be aware of is that:
- each time you select a GDI object (font, pen, brush, etc.) into a device-context you should restore the one that it held originally
- you should not save the pointers returned by
SelectObject to restore them later, because they could be temporary. To be more specific, the objects pointed could be destroyed during the idle-time of your application (i.e. inside the CWinApp::OnIdle). This means that you should restore these objects before returning from the message handler on which you have called SelectObject
|
|
|
|
|
But if we restore the temporary pointer returned from SelectObject in the DC immediately, the DC may be having some dangling references after the current call. Means if we store the current DC for some other call there are chances of using incorrect memory.
|
|
|
|
|
ashtwin wrote: But if we restore the temporary pointer returned from SelectObject in the DC immediately, the DC may be having some dangling references after the current call.
I think you mean: "the device-context hold a pointer that could became invalid". Isn't it?
Don't worry about it: once you have selected back the original object inside the device-context, everything will works fine. What you cannot do is to store that pointer and use it explicitly later.
|
|
|
|
|
There is a difference. The temporary object is a temporary MFC object wrapping the underlying HGDIOBJECT. The gdi object the handle is pointing to is not temporary.
|
|
|
|
|
I understood. Thanks you all for your replies.
|
|
|
|
|
Hello,
I created an ActiveXDll on C# and set parameters of COM in its interface.
And now I need to integrate this ActiveXDll in my C++ Form.
So can you help me?
|
|
|
|
|
If you're using MFC, then Visual Studio may generate a wrapper C++ class for you.
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]
|
|
|
|
|
Hello,
When running MFC\C++ project in 2003 VC++.NET env, resource files are always out of date,
even though there are no changes made.
Whenever I hit F5, it gives me the "These project configuration(s) are out of date:"
msgbox.
When building again, I see that all sources are up to date except resources
In the output window I see:
all is "up-to-date"
then "compiling resources..
Linking.."
Can anyone know how to get rid of this annoying msgbox?
Thanks,
Dor
|
|
|
|
|
in win32, where will keep the all messages are generated by the window? and how do know this message is belongs to this window? and who will maintain the message queue? what happand in background? what is the code in c++? what are the methods are fallows in background?
Regards,
Srinivas
|
|
|
|
|
Every thread has its own message queue that is setup by the system into which it posts the messages. Now that you have a start, dig into MSDN.
|
|
|
|
|
bleedingfingers wrote: Every thread has its own message queue that is setup by the system into which it posts the messages.
That's not completely true, see The Old New Thing - In pursuit of the message queue.
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]
|
|
|
|
|
CPallini wrote: bleedingfingers wrote:
Every thread has its own message queue that is setup by the system into which it posts the messages.
That's not completely true, see The Old New Thing - In pursuit of the message queue.
I know I know. And one would have to use PeekMessage(...) to force a queue to be created but I just gave him a start. Now, let him wipe that e-dust off his MSDN will ya 
|
|
|
|
|
[Edit] I overlooked it - A 5 vote is offered. [/Edit]
There are some really weird people on this planet - MIM.
modified on Monday, October 18, 2010 1:52 PM
|
|
|
|
|
There are lots of things to say about your question. Let's say:
- the operating system handle a message queue for each thread in your process;
- it's up to you to write down the message loop for each thread
- each time you call the
DispatchMessage from your message loop, the message is dispatched to the window procedure of the window to which the message is targeted
To learn about this topic, start from Messages and Message Queues (Windows)[^]
|
|
|
|
|
who will create a thread and message queue?
what relation ship between operating system, thread, message queue, and application?
Regards,
Srinivas
|
|
|
|
|
vasu_sri wrote: who will create a thread and message queue?
The first thread is created by the operating system when you start an application. Other threads will be created by the application itself, for example by calling the CreateThread Function (Windows)[^].
A message queue is created and maintained by the operating system; the OS creates it only when needed, i.e. when your thread creates a window or calls any function that involves message queues.
vasu_sri wrote: what relation ship between operating system, thread, message queue, and application?
It's a very generic question, and answer it requires thousands of words... Have you had a look at the documentation on MSDN that I suggested you?
|
|
|
|
|
Application crashes at RichEditCtrl.StremOut(), It says attempt to read write protected memory. this often an indication that the other memory is corrupt.
May I know some path to find the issue and fix the issue. Any idea ?
.....
if (0 != file.Open(m_str, CFile::modeCreate | CFile::modeWrite, &e))
{
EDITSTREAM es = {0};
es.pfnCallback = COleElement::CallFunction;
es.dwError = 0;
es.dwCookie = (DWORD)&file;
lRet = m_cRichEdCt.StreamOut(SF_RTF, es);
}..........
DWORD CALLBACK CMyClass::CallFunction(DWORD dwCookie, LPBYTE lpBuf,LONG nCount, LONG* Write)
{
CFile* pFile = (CFile*)dwCookie;
if (pFile)
{
pFile->Write(lpBuf, nCount);
}
*Write = nCount;
return 0;
}
|
|
|
|
|
I have already responded to this question here[^]. Did you follow my suggestion and run it with the debugger?
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
I tried to debug and got the below values for es
es {dwCookie=1231056 dwError=0 pfnCallback=0x05151631 } _editstream
and the blreadk poing in the call back function is not getting hit.
Please advice
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
