|
You should capture the return value from WaitForSingleObject to see why it did not wait. You also need to check that your worker thread is actually doing some work rather than returning immediately.
NOTE: Please enclose your code snippet in <pre></pre> tags (use the "code block" button) to make it more readable.
Just say 'NO' to evaluated arguments for diadic functions! Ash
|
|
|
|
|
Wait on the thread handle, not on the pointer to the thread class.
|
|
|
|
|
Good point.
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]
|
|
|
|
|
I wonder why that compiles for him...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
it compiles 'cause Microsoft made a horrible decision with kernel handles in NT - they made them all void pointers so any type of pointer is compatible with them. You can pass any old rubbish pointer into most kernel functions where it expects a kernel handle and the compiler can't tell the difference.
Ironically this is unlike GDI handles which they'd already made specific structure pointers in Windows 3.1 - 3 years previously. Such is life... [1]
If you're prone to messing this sort of thing up a lot (as I am) then you can make things a bit more type safe in C++ by defining an overload of WaitForSingleObject:
DWORD WaitForSingleObject( CWinThread *thread_ptr, DWORD msec_to_wait )
{
return WaitForSingleObject( *thread_ptr, msec_to_wait );
}
which will catch this sort of error. It's a right pain in the bum to have to that though and you have to make sure that you include your API wrappers otherwise you're back to square one (and there's the old catch-22 - if you know enough to use the typesafe wrappers you know enough to not need to use them).
Cheers,
Ash
[1] I suppose the difference was that in Windows 3.1 if you got a handle wrong you had to reboot as you'd trashed the system, in NT you'd just mess up a process.
|
|
|
|
|
Damn, you are right, i should have thought of that...i must be getting old and senile...what are we talking about again?
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Leela: Fry, you're wasting your life sitting in front of that TV. You need to get out and see the real world.
Fry: But this is HDTV. It's got better resolution than the real world <
>Nothing is free in the universe.<
|
|
|
|
|
As already suggested, you have to check the return value of every API function you call, otherwise... troubles.
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]
|
|
|
|
|
OK, here is your problem: you are passing the returned value (CWinThread pointer) from AfxBeginThread to WaitForSingleObject, which is not correct. Instead, you should pass the HANDLE defined inside those m_pcThread1 and m_pcThread2. Like so:
WaitForSingleObject(m_pcThread1->m_hThread,INFINITE);
WaitForSingleObject(m_pcThread2->m_hThread,INFINITE);
--
Arman
|
|
|
|
|
Hello,
WaitForSingleObject takes a handle as first argument. You are passing a pointer to a CWinThread.
Changing your code to
WaitForSingleObject( m_pcThread1->m_hThread, INFINITE );
WaitForSingleObject( m_pcThread2->m_hThread, INFINITE );
should solve your issue.
Regards
Frank
|
|
|
|
|
Hi all
I have stranger problem in dialog box Control disappear from dialog.There is no issue of memory and cpu uses,both are normal.I want to know what reason behind this situation?
Please help me..
|
|
|
|
|
can you be more specific with the scenario?
|
|
|
|
|
Thanks for reply
[B]scenario[/B] I have a dialog A and modless dialog B.Modless Dialog B call on button click of Dialog A.I use timer to show Watch in Modless dialog B.When i set time for One hour then this thing is happen.
|
|
|
|
|
please tell that what is disappearing from where?
|
|
|
|
|
ok Button,Check Box,Static Box from Main Dialog A.
|
|
|
|
|
please be more precise, where do you set timer? or post code portions..
|
|
|
|
|
Set timer in main dialog A.
extern CStatic m_settime;
CdialogADlg* test;
m_dialogB= new CdialogB(test);
m_dialogB->Create(CdialogB::IDD,0);
m_dialogB->CenterWindow(test);
void CdialogADlg::OnTimer(UINT_PTR nIDEvent)
{
if(nIDEvent==1)
{
m_settime.SetWindowText("Time start.");
}
CDialog::OnTimer(nIDEvent);
}
|
|
|
|
|
MsmVc wrote: extern CStatic m_settime;
CdialogADlg* test;
m_dialogB= new CdialogB(test);
m_dialogB->Create(CdialogB::IDD,0);
m_dialogB->CenterWindow(test);
where are all these written? where do you call SetTimer?
|
|
|
|
|
written in button click of dialog A. and SetTimer also call in button click of dialog A.
|
|
|
|
|
some thing wrong with ur code, pls show the button click handler function as such.
|
|
|
|
|
What wrong in my button click handler?
afx_msg void OnBnClickedCall();
ON_BN_CLICKED(IDC_BUTTONCALL, &CdialogADlg::OnBnClickedCall)
void CdialogADlg::OnBnClickedCall()
{
}
|
|
|
|
|
MsmVc wrote: void CdialogADlg::OnBnClickedCall()
{
}
i mean, show code in this function as such.
|
|
|
|
|
i had already post some related code.
Can you tell me simple why these type of think happen?
I think possible solution is Invalidate or RedrawsWindos.
But i want to know why these type think happen?
|
|
|
|
|
you are not doing any paint code for that. All you do is simply create a child dialog and set up a timer. I can't find any possible issues in this in order to make the controls diasappear. Thats why i suspected your code. Ok you try those possible solutions.
|
|
|
|
|
MsmVc wrote: extern CStatic m_settime;
CdialogADlg* test;
m_dialogB= new CdialogB(test);
m_dialogB->Create(CdialogB::IDD,0);
m_dialogB->CenterWindow(test);
//Timer
void CdialogADlg::OnTimer(UINT_PTR nIDEvent)
{
if(nIDEvent==1)
{
m_settime.SetWindowText("Time start.");
}
CDialog::OnTimer(nIDEvent);
}
Call ShowWindow(SW_SHOW) before centering it.
|
|
|
|
|
My little application was compiling fine as is until I installed the VS2008 SP1 yesterday. I mean it compiled fine, then I installed the update, then I recompiled and started getting the following error:
1>------ Build started: Project: GTRNoteWorker, Configuration: Release Win32 ------
1>Compiling...
1>GTRNoteWorker.cpp
1>Automatically linking with ToolkitPro1321vc90S.lib
1>C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xtr1common(252) : error C2766: explicit specialization; 'std::tr1::_Is_integral<int>' has already been defined
1> C:\Program Files\Microsoft Visual Studio 9.0\VC\include\xtr1common(200) : see previous definition of '_Is_integral<int>'
1>Build log was saved at "file://c:\Coding\GTRNoteWorker - 2008\x86\Release\BuildLog.htm"
1>GTRNoteWorker - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
So I think OK, they tightened up something, so I checked to make sure I haven't included the header somewhere else ...then I realized that the error is stating that the thing has been defined already IN THE SAME HEADER file!
I think I must be missing a define or something
Any help would be appreciated!
Thanks,
Paul
|
|
|
|