Which FindFiles function is that?The FindFiles function will loop and not provide any progress until I explicitly ask for it
Which FindFiles function is that?The FindFiles function will loop and not provide any progress until I explicitly ask for it
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
My custom designed one,
pp< std::vector<CString> > Stuff::FindFiles(const CString& strFolder, const CString& strPattern, bool bSearchSubFolders, UINT64* pnCurrentFile, CString* pstrCurrentFile, bool bThread, bool* pThreadFinished, bool* pCancel, pp< std::vector<CString> > pBuffer)
Originally Posted by Adak
Well, give it another parameter:
and whenever you've got a file, doCode:HWND hUpdateWnd
Note: MFC's classes are thread-bound. Do not pass them to other threads. That's why I use a plain window handle here.Code:if(hUpdateWnd) PostMessage(hUpdateWnd, UM_FILEFOUND, 0, 0);
UM_FILEFOUND is, of course, a constant with a value of WM_USER+x.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
That would hinder efficiency. The thing is that I wrote it explicitly so that it wouldn't do anything else than find files unless asked by the caller. And just posting a message doesn't really help.
I would have to make a buffer and probably pass a struct. But it takes unneccesary time, which is why I made the whole explicitly ask approach.
Yes, I know. MFC classes are generally thread un-safe.Note: MFC's classes are thread-bound. Do not pass them to other threads. That's why I use a plain window handle here.
UM_FILEFOUND is, of course, a constant with a value of WM_USER+x.
Compared to searching the hard disk for files, posting a message is nothing. And it's certainly more efficient than another thread polling a global variable.
You haven't answered yet, by the way: are these globals atomic?
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
We'll see about that, I guess...
No, afraid not.You haven't answered yet, by the way: are these globals atomic?
I don't know very much about atomic.Code:HANDLE heRequestData_CountFiles; HANDLE heRequestData_FindFiles; bool bRequestData_CountFiles = false; bool bRequestData_FindFiles = false;
But theoretically, a flag should take a cycle to update. But I don't think that's a good thing to rely on?
No, it's not. Basically, what you have there is a time bomb.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
What do you propose to fix it?
Use proper communication methods as I have outlined.
Or as a bare minimum fix, use the Interlocked* APIs for manipulating the things.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
