|
<br />
void CFileChangeEvent::stopProcessThread()<br />
{<br />
TRACE( "> > > > CFileChangeEvent::stopProcessThread() entered - Event handles < %X, %X >, Event ID < %s >\n",<br />
m_hProcessStopEvent, m_hProcessRespEvent, getIdentifier() );<br />
<br />
::SetEvent( m_hProcessStopEvent );<br />
}<br />
<br />
UINT CFileChangeEvent::MultiFileProcessThread( LPVOID lpParam )<br />
{<br />
CFileChangeEvent* pEvent = (CFileChangeEvent*)lpParam;<br />
<br />
CFlightDataHandler* pFlightDataHandler = NULL;<br />
CLogWriter* pLogWriter = NULL;<br />
HANDLE hProcessStopEvent = pEvent->getProcessStopEvent();<br />
HANDLE hProcessRespEvent = pEvent->getProcessRespEvent();<br />
<br />
try<br />
{<br />
CDataMovement* pDataMovement = pEvent->getDataMovementParent();<br />
CLogWriter* pLogWriter = pDataMovement->getLogWriter();<br />
pFlightDataHandler = new CFlightDataHandler( pLogWriter );<br />
<br />
HRESULT hRes = ::CoInitialize(NULL);<br />
<br />
CString strInboxPath( pDataMovement->getInboxPath() );<br />
vector<CString> vecFifFiles = UtilK::findAllFiles( "*.fif", strInboxPath );<br />
<br />
int nLen = strInboxPath.GetLength() + 1;<br />
vector<CString>::iterator iterFile = vecFifFiles.begin();<br />
CString strFile = *iterFile;<br />
CString strLastPath = (*iterFile).Mid( 0, strFile.Find( "\\", nLen ) );<br />
<br />
int nFileCount = 0;<br />
bool bCancelled = false;<br />
for( ; iterFile != vecFifFiles.end() && ! bCancelled; iterFile++ )<br />
{<br />
CString strPath = UtilK::getFsPart( *iterFile, UtilK::FsPath );<br />
pFlightDataHandler->importRawFlightData( strPath );<br />
<br />
DWORD dwWaitStatus = ::WaitForSingleObject( hProcessStopEvent, 1 ); <br />
if ( dwWaitStatus == WAIT_FAILED )<br />
bCancelled = true;<br />
else if ( dwWaitStatus == WAIT_OBJECT_0 )<br />
bCancelled = true;<br />
}<br />
}<br />
catch( CMultiLevelException e )<br />
{<br />
CString strMsg;<br />
strMsg.Format( "importVARFile() failed - error description is %s", e.getUserMessage() );<br />
<br />
TRACE( "> > > > CFileChangeEvent::MultiFileProcessThread() exception < %s >\n", strMsg );<br />
if ( pLogWriter )<br />
pLogWriter->writeEntry( "CFileChangeEvent", CLogWriter::LE_OPERATION_FAILED, strMsg );<br />
}<br />
catch(...)<br />
{<br />
CString strMsg( "importVARFile() failed with unexpected exception" );<br />
TRACE( "> > > > CFileChangeEvent::MultiFileProcessThread() exception < %s >\n", strMsg );<br />
if ( pLogWriter )<br />
pLogWriter->writeEntry( "CVarFileEvent", CLogWriter::LE_OPERATION_FAILED, strMsg );<br />
}<br />
<br />
if ( pFlightDataHandler )<br />
delete pFlightDataHandler;<br />
<br />
CFileChangeEvent::setProcessCompleted();<br />
<br />
TRACE( "> > > > CFileChangeEvent::MultiFileProcessThread() exiting\n" );<br />
<br />
::CoUninitialize();<br />
<br />
if ( hProcessStopEvent )<br />
::CloseHandle( hProcessStopEvent );<br />
<br />
if ( hProcessRespEvent )<br />
{<br />
::SetEvent( hProcessRespEvent );<br />
::CloseHandle( hProcessRespEvent );<br />
}<br />
<br />
::AfxEndThread( 0 );<br />
<br />
return 1;<br />
}<br />
|
|
|
|
|
A couple things I see going on here.
1. You should verify pFlightDataHandler got created before using it.
2. I am assuming that the calls to getProcessStopEvent and getProcessRespEvent actually open a handle, otherwise, when you close them at the end of your thread, you have closed them off for the 'parent' as well.
3. It is not necessary to call AfxEndThread if you are going to exit the thread via its return. Just return the value 0 at end of thread function to accomplish same result.
4. I am assuming that pLogWriter's writeEntry will not throw exceptions, otherwise, you could just flag a problem in your exception handling code and then write to log after leaving the exception.
5. I would consider moving the CoInitialize ahead of your main try block, since the CoUninitialize is already outside of it.
6. If the pFlightDataHandler is a 'risky' object, consider putting its delete in a try/catch block.
7. Why not wait for 0 milliseconds, as per MSDN The function returns if the interval elapses, even if the object's state is nonsignaled. If dwMilliseconds is zero, the function tests the object's state and returns immediately. Then I think it might not even suspend your thread if the system is not busy.
Otherwise, I am not sure why you would have a problem, unless one of your obejcts is bad, as there are a couple other retrieval functions there where the pointers are not verified against NULL.
|
|
|
|
|
I've installed "Visual C++ 2008 feature pack", but the documents couldn't be updated.
The documents are already on www.msdn.com[^], any way to make it local?
|
|
|
|
|
Did you install MSDN on your system and it doesnt work?
|
|
|
|
|
The most up-to-date docs for the feature pack are only available online
unfortunately. Hopefully they'll make them available for download in
the near future.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
I've got a problem that I've tried to figure out, but can't.
Here's my code:
CString str = "C:\\Wells\\Program\\DataBases\\Drivers\\R and S\\OurDrivers.ddb";
CStdioFile myFile;
if(!myFile.Open(str, CFile::modeRead | CFile::typeText))
{
TRACE(_T("Unable to open file\n"));
}
DWORD dw = GetLastError();// error_path_not_found (3)
Here's the error with the CString str
ERROR:
error C2440: 'initializing' : cannot convert from 'const char [58]' to 'ATL::CStringT<BaseType,StringTraits>'
now I realize that this is correct:
CString str = _T("C:\\Wells\\Program\\DataBases\\Drivers\\R and S\\OurDrivers.ddb");
Here's the problem. I have to send "str" to the FileSave" function with the data already in it! I can't convert it like above (hard-coded) because I don't know what cchoices the User used to build the above string(str). I just hard-coded it for testing purposes.
Isn't there someway to use a CString as the filename/path in CStudioFile?
Help Please!
A C++ programming language novice, but striving to learn
|
|
|
|
|
Larry Mills Sr wrote: ...the FileSave" function...
What does its signature look like?
Larry Mills Sr wrote: I just hard-coded it for testing purposes.
So str will actually be populated by the user?
Larry Mills Sr wrote: Isn't there someway to use a CString as the filename/path in CStudioFile?
Yes, and it normally does not require anything special.
"Love people and use things, not love things and use people." - Unknown
"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne
|
|
|
|
|
You can use the ATL and MFC String Conversion Macros[^] to convert from wide string to LPCTSTR. Note that it is normally not recommended to use CStringA directly. In addition it is also not recommended to call the GetBuffer() member when there are better alternatives. However with those disclaimers out of the way lets continue to hammer a square peg into a round hole.
An ugly dirty method would be:
CString str = _T("C:\\Wells\\Program\\DataBases\\Drivers\\R and S\\OurDrivers.ddb");
USES_CONVERSION;
myFile.Open((LPCTSTR)CStringA(T2A(str)).GetBuffer(),0,0);
A better way of doing this would be:
CString str = _T("C:\\Wells\\Program\\DataBases\\Drivers\\R and S\\OurDrivers.ddb");
char szPath[MAX_PATH + 1] = {0};
USES_CONVERSION;
strcpy(szPath,T2A(str));
myFile.Open((LPCTSTR)szPath,0,0);
An even better way of doing this might be:
#ifdef _UNICODE
char szPath2[MAX_PATH + 1] = {0};
WideCharToMultiByte(CP_ACP, 0, str, -1, szPath2, MAX_PATH, NULL, NULL);
myFile.Open((LPCTSTR)szPath,0,0);
#endif
Best Wishes,
-David Delaune
|
|
|
|
|
Larry Mills Sr wrote: I have to send "str" to the FileSave" function with the data already in it! I can't convert it like above (hard-coded) because I don't know what cchoices the User used to build the above string(str).
That seems FileSave functions takes CString as parameter, then why do you worry, it is the user who has to ensure proper data in str expected by FileSave method.
Answer DavidCrow's query, don't think about conversion unless you know what you are doing.
|
|
|
|
|
1. I'm using GDI+, when I press F1 to see the help of Pen, it'll try to find Gdiplus::Pen, but find nothing. If I typed Pen manually, it'll be found.
Any way to let F1 find it automatically?
2.
Pen pen(Color::Red);
When compiling with warning level 4, it reports a warning as below:
warning C4245: 'argument' : conversion from '' to 'Gdiplus::ARGB', signed/unsigned mismatch
What a type mismatch!
How to write it correctly?
|
|
|
|
|
hi to all
i am a new bie 
i want to know usage of GetDetaitsOf() , NameSpace() , ParseName()
there are JScript , VBScript , Visual Basic examples
on MSDN[^] but i need a C++ example can you show me one
thanks
|
|
|
|
|
reteset wrote: hi to all
i am a new bie
Then you should be studying C++ fundamentals not trying to reproduce code from Javascript and other languages.
led mike
|
|
|
|
|
you probably need to use the IShellFolder2 Interface.
|
|
|
|
|
reteset wrote: i am a new bie
hope the following gives a start, assuming you are not c/c++ newbie but the shell interface newbie,
C++ example for the example[^],
#include <shlobj.h>
#include <shlwapi.h>
#include <stdio.h>
#include <tchar.h>
#pragma comment (lib, "shlwapi.lib")
#define SAFE_RELEASE(_x) if (_x){_x->Release(); _x = NULL;}
int main()
{
LPMALLOC pMalloc = NULL;
IShellFolder *psfShell = NULL;
IShellFolder2 *psfWindowsFolder = NULL;
LPITEMIDLIST pidlWindowsFolder = NULL;
LPITEMIDLIST pidlFile = NULL;
TCHAR szDisplayName[MAX_PATH];
SHELLDETAILS shDetails;
HRESULT hr = E_FAIL;
hr = SHGetMalloc(&pMalloc);
if(FAILED(hr))
goto END;
hr = SHGetDesktopFolder(&psfShell);
if(FAILED(hr))
goto END;
hr = SHGetFolderLocation(NULL, CSIDL_WINDOWS, NULL, NULL,
&pidlWindowsFolder);
if(FAILED(hr))
goto END;
hr = psfShell->BindToObject(pidlWindowsFolder, NULL,
IID_IShellFolder2, (VOID **)&psfWindowsFolder);
if(FAILED(hr))
goto END;
hr = psfWindowsFolder->ParseDisplayName(NULL,
NULL,
_T("clock.avi"),
NULL,
&pidlFile,
NULL);
if(FAILED(hr))
goto END;
hr = psfWindowsFolder->GetDetailsOf(pidlFile, 2, &shDetails);
if(FAILED(hr))
goto END;
hr = StrRetToBuf(&shDetails.str, pidlFile, szDisplayName, sizeof(szDisplayName));
if(FAILED(hr))
goto END;
_tprintf(_T("Details at Column 2 : %s \n"), szDisplayName);
END:
if (pMalloc)
{
if (pidlFile) pMalloc->Free(pidlFile);
if (pidlWindowsFolder) pMalloc->Free(pidlWindowsFolder);
}
SAFE_RELEASE(psfWindowsFolder);
SAFE_RELEASE(psfShell);
SAFE_RELEASE(pMalloc);
return 0;
}
modified on Friday, May 2, 2008 1:31 AM
|
|
|
|
|
Just curious... do you actually use the goto statement that much in production code?
Best Wishes,
-David Delaune
|
|
|
|
|
It's a valid way of doing cleanup in this case; if you do not do that, you will have to copy the same "cleanup" code
all over the place.
|
|
|
|
|
Maximilien wrote: if you do not do that, you will have to copy the same "cleanup" code
all over the place.
No you don't. Just nest the if's and cleanup as you unnest, like so:
hr = SHGetMalloc(&pMalloc);
if(SUCCEEDED(hr))
{
hr = SHGetDesktopFolder(&psfShell);
if(SUCCEEDED(hr))
{
hr = SHGetFolderLocation(NULL, CSIDL_WINDOWS, NULL, NULL, &pidlWindowsFolder);
if(SUCCEEDED(hr))
{
hr = psfShell->BindToObject(pidlWindowsFolder, NULL, IID_IShellFolder2, (VOID **)&psfWindowsFolder);
if(SUCCEEDED(hr))
{
hr = psfWindowsFolder->ParseDisplayName(NULL, NULL, _T("clock.avi"), NULL, &pidlFile, NULL);
if(SUCCEEDED(hr))
{
hr = psfWindowsFolder->GetDetailsOf(pidlFile, 2, &shDetails);
if(SUCCEEDED(hr))
{
hr = StrRetToBuf(&shDetails.str, pidlFile, szDisplayName, sizeof(szDisplayName));
if(SUCCEEDED(hr))
_tprintf(_T("Details at Column 2 : %s \n"), szDisplayName);
}
}
pMalloc->Free(pidlFile);
}
psfWindowsFolder->Release ();
}
pMalloc->Free(pidlWindowsFolder);
}
psfShell->Release ();
}
pMalloc->Release ();
}
I prefer this way since it is obvious where the allocate / deallocate pairs are located.
Judy
|
|
|
|
|
|
I agree with you.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Maximilien wrote: It's ugly.
I agree whole-heartedly. However ... it was an example to refute your unqualified statement that "you will have to copy the same "cleanup" code all over the place" which is NOT true. There's no pretty way to deal with this kind of code. All alternatives are ugly when there are so many consecutive statements that both a) depend on the success of the preceding statement and b) each statement allocates something new.
Judy
|
|
|
|
|
JudyL_FL wrote: No you don't. Just nest the if's and cleanup as you unnest, like so:
Hi Judy,
That's a good point. However, the code readability decreases proportionally and it starts looking very ugly with an increased number of if conditions in this approach.
I would personally prefer the sinful goto way of doing it.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
how wide you go (if i don't want the overhead of another function call)
|
|
|
|
|
The wider you go, the more the danger of your code being classified as horror.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
Randor wrote: do you actually use the goto statement that much in production code?
never, not because of my interest but it is not in my control, i used to follow the organisation standards. some force to use the do..while(0) horrors, i personally not against it. but i never do the nested way for readability unless the number of statement is less or there is considerable need of inline function.
BTW, what's your opinion?
modified on Friday, May 2, 2008 3:13 AM
|
|
|
|
|
Rajkumar R wrote: BTW, what's your opinion?
The goto statement has always had a bad reputation. I can remember reading many arguments in the C++ usenet newsgroups debating these issues. And beyond the argument 'The goto statement causes spaghetti code' nobody ever gave a reason why the goto statement was bad.
I'm much older now and more experienced so I can now answer this question myself now. It is my opinion that the goto statement should be avoided. The code that Judy posted is a superior method of implementing the function regardless of how ugly it is. My reasoning is quite simple in that the compiler cannot perform optimizations with all of those unconditional jumps all over the place. So by placing all of those goto statements in your function it causes the compiler to produce very different code. You can confirm this by editing your project and enabling 'Assembly With Source Code (/FAs)' for producing the ASM file.
Now I will argue a point in favor of a well placed goto statement. An experienced programmer may have intimate knowledge of compiler optimizations and determine that a goto statement will be beneficial. For example:
for(int x =0; x < iLimit;++x)
{
for(int y =0; y < iAnotherLimit;++y)
{
for(int i =0;i< ilastlimit;++i))
{
if(FALSE == DoWork(SomeArray[x][y][i]))
{
goto critical_error;
}
}
}
}
critical_error:
CleanUp();
In this example the compiler output will greatly benefit from the goto statement. There is no faster way to exit the nested loops. So here is my final statement regarding the issue.
Randors Conjecture:
The only time at which a C++ programmer should use a goto statement is to escape a deep nested loop.
Best Wishes,
-Randor (David Delaune)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
