|
Hi Iain,
thanks for your reply. Got a new Question:
When I override the CWnd::PreSubClass for my sliders. Do I have a correct DC at that point? Or is ist created afterwards? Or did you mean I should override PreSubClass and ALSO create the memDC in the OnPaint Handler? What for do I need the PreSubClass-Method then?
Thanks
|
|
|
|
|
I would ignore the PreSubClass completely (for this reason at least - for all I know you have other work to do).
And in your OnPaint handler, I would use Keith Rule's CMemDC class - creating the bitmaps will be pretty speedy, and it keeps your code clean. It will even blt the image to the screen with it goes out of scope.
Flicker Free Drawing In MFC[^]
I cannot recommend this article highly enough.
I used to cache my own memory DCs, but it wasnt worth the hassle, and the speed hit of recreating them is essentially 0.
Iain.
|
|
|
|
|
hi i am having ascii file for a model. how to draw the model by reading the ascii file using opengl. i am new bie to opengl. pls guide me
|
|
|
|
|
Have you looked to the articles section here in CodeProject?
There are a lot of samples at every level (also for newbie)
saisp wrote: i am having ascii file for a model
If it is a known format you can probally hope to find some ready code to import it...elseway you will need to write your custom code.
Russell
|
|
|
|
|
Hi,
I want to develop a Multithread SDI application where a ball(drawing an ellipse) is created for every thread.
The user is given the option of selecting N no of balls ( say N < 5).
The trajectory/movement of the ball is random of each other. These bounce-off once they hit any one of the sides of the client rect.
Assume that I have the points through which each ball has to traverse (which is different for each ball), how do i start of with this application?
|
|
|
|
|
I never made an application like this, but do you think it's necessairy to create
for each ball a thread?
If i should make it, i create a class Ball and instanciate for each ball a new object.
Because the drawing is made (in every case) at the main thread (The GUI-Thread)
Normally the balls are flying with the same speed, so with a timer you redraw each time
the new position of the balls. The new position of the ball is calculated into the object.
I hope i don't say bullshit
|
|
|
|
|
baerten wrote: I never made an application like this, but do you think it's necessairy to create
for each ball a thread?
What I had in mind was for each thread, within that thread, I Create a ball object and in a while loop, get the necessary paramerers (trajectory) of the ball by making call functions. Periodically I keep updating the UI with the info.
|
|
|
|
|
You really don't need to be using a thread for each ball. As another poster said, create an instance of a class for each and update the class on each loop of your code.
You also might want to do some searching for an algorithm called "collision detection" which is almost exactly what you are trying to accomplish.
Waldermort
|
|
|
|
|
Marimuthu.pesit wrote: how do i start of with this application?
this[^] is a good article to start.
.
Russell
|
|
|
|
|
Your application sounds very similar to the sample program MTGDI in the MSDN Library. It might help you get started.
MTGDI[^]
Best Regards
Cliff
|
|
|
|
|
it seems that ON_COMMAND_EX just works in doc/view architecture. Can anyone give me some tips about it?
thank you.
|
|
|
|
|
have a look
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=514836&SiteID=1
http://www.codeguru.com/forum/showthread.php?t=61254
http://www.codeguru.com/forum/showthread.php?t=216400
|
|
|
|
|
Thank you for your reply.
I already google it and search it on codeproject and codeguru before posting this message.
Yes, it works well for Doc & View architecture.
my architecture is CMainFrame and CMyView (derived form CWnd, not CView) and without Doc.
And it has a custom tool bar and a custom status bar.
|
|
|
|
|
Do you need ON_COMMAND_EX() instead of ON_COMMAND() .
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
I need process the message in the child window and parent window.
child window uses ON_COMMAND_EX and parent window uses ON_COMMAND.
|
|
|
|
|
Rockone wrote: I need process the message in the child window and parent window.
Why would you need to do this?
"A good athlete is the result of a good and worthy opponent." - David Crow
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
just add
<br />
if ( m_wndToolBar.OnCmdMsg(...) )<br />
{<br />
return TRUE;<br />
}<br />
in function
<br />
CMainFrame::OnCmdMsg(...)<br />
before return default process.
|
|
|
|
|
I'm not sure why you think it ONLY works in doc/view.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I already try some cases, it works well in doc/view case.
I get some source codes from sourceforge.net, it uses ON_COMMAND_EX and is not doc/view case.
it just has CMainFrame and a view derived from CWnd, without doc.
|
|
|
|
|
this snippet below:
redmap::mapi::FoundProperty prop
= m_Message->FindProperty(PropertyID);
-----
will call this snippet:
class Message
{
enum Mode { CLOSED, OPEN };
IMessagePtr m_Message;
AutoMapiPtr<SPropValue> m_PropertyCache;
PropertyMap m_MessageProps;
SRowSet* m_AttachCache;
unsigned long m_AttachCount;
boost::scoped_array<PropertyMap> m_AttachProps;
Mode m_Mode;
public:
.
.
.
.
.
FoundProperty FindProperty(unsigned long PropertyTag)
{
assert(m_Mode == OPEN);
return m_MessageProps.find(PropertyTag);
}
now I am wondering as why m_Mode in the second snippet has no value at all.
Please enlighten me
If any of you requires additional code to expand this just say so.
Thank you,
Jj
-- modified at 4:12 Tuesday 18th September, 2007
|
|
|
|
|
As I read it, the programmer (I'm guessing it's not you) has just put an assert in there. (s)he could just be checking that things he expects to be true are actually true. Maybe unless m_Mode is OPEN, then m_MessageProps would be empty, and he wants to catch the reasons why the find routine would fail.
It's always possible this is a line of fossil code, and m_Mode is no longer necessary. But unless you understand the code, I'd leave it in also.
Iain.
|
|
|
|
|
hi,
I want to send a message on WinSock by calling socket.Send() in a thread.
UINT WorkerThreadForDelay1(LPVOID Param)<br />
{<br />
.<br />
.<br />
CMyView* ptr;<br />
iSent = ptr->m_sConnectSocket1.Send(LPCTSTR(m_strMessage), iLen);<br />
.<br />
.<br />
}
Note that:
1. CMyView is derived from CRecordView.
2. m_sConnectSocket1 is an object of a CAsyncSocket-derived class, declared in CMyView.
How do i initialize ptr here???
|
|
|
|
|
You could pass it as your thread argument. If you look at the documentation of the create thread function that you use, you'll see that it can accept an argument, that will be passed to your thread function through the LPVOID Param.
So, you can simply do that in your thread function:
UINT WorkerThreadForDelay1(LPVOID Param)<br />
{<br />
.<br />
.<br />
CMyView* ptr = (CMyView*)Param;<br />
But be carefull not to use the GUI object directly in your thread.
|
|
|
|
|
hey Cedric,
Thanks man....i tried this out and it works....thanks
I was calling the thread as follows:
.<br />
AfxBeginThread(WorkerThreadForDelay1,NULL,THREAD_PRIORITY_LOWEST,0,0,NULL);<br />
.
Now i changed it to:
CMyView* me;<br />
me=this;<br />
AfxBeginThread(WorkerThreadForDelay1,me,THREAD_PRIORITY_LOWEST,0,0,NULL);
and then ofcourse wat you wrote:
UINT WorkerThreadForDelay1(LPVOID Param)<br />
{<br />
.<br />
CMyView* ptr = (CMyView*)Param;<br />
iSent=ptr->m_sConnectSocket1.Send(.....);<br />
}
|
|
|
|
|
What you can do is to use the LPVOID parameter to hold a pointer to some class.
eg.
HANDLE CMyClass::CreateTheThread ()
{
m_hThread = CreateThread (MyThreadRoutine, ...., this, ...);
return m_hThread;
}
DWORD MyThreadRoutine (LPVOID pParam)
{
CMyClass *pThis = (CMyClass *)pParam;
....
return 0;
}
There are things to be careful of though. You have to ensure that the CMyClass object will last longer than the thread routine. Or at least longer than the thread routine will use it.
And in your routine, you are using CASyncSocket. This class uses asynchronous socket behaviour, and responds to messages from winsock, rather than blocking on them. It does *not* mean that it is thread safe. It *might* be if you only send from one thread, and read on another, but don't assume that. This is why I use pretty raw win32 code in my threads, as MFC is explicitly not thread friendly. I'll use CWnd derived classes for it, but only to get access to the m_hWnd member to post messages back to them.
Iain.
|
|
|
|