|
C-P-User-3 wrote: yes, I know about google.
So what is wrong with some of these links[^]?
Use the best guess
|
|
|
|
|
Here's what's "wrong" with them: they came from google.
Some time ago, google became the premier web search tool.
Some time after that, money came into play.
Some time after that, Newton's third law, in terms of psychodynamics and economics, produced the "Search Engine Optimization" (SEO) phenomenon.
Some time after that, the financial aspect of "finding the best" came into the procedure.
I don't understand all the inputs, but I have seen enough of the outputs to understand that the algorithm is now different from what it was several years ago.
Hence, asking the direct opinion of a bunch of guys on a site like this can produce a far more easily understood "search result" with the biases and prejudices far more easily inferred than a list that google produces. With those biases and prejudices more clearly evident and understood than an "automated" response, I can make a decision with which I'm far more comfortable.
I guess the concept parallels wikipedia these days; i.e.,
"...NPOV is absolute and non-negotiable..."
From what I've seen, the same thing that happened to wikipedia's "...NPOV..." closely approximates what has happened to google's algorithms.
All this is from guessing, based on the results I've personally observed.
So,,,,,,,,,,
That's why I like opinions from here better than from there.
|
|
|
|
|
C-P-User-3 wrote: Here's what's "wrong" with them: they came from google.
And how do you think we find "the best", whatever that may mean. I learned C from Kernighan & Ritchie[^], which is, in my opinion, one of the best programming guides ever written. But then I may well have missed lots of others.
Use the best guess
|
|
|
|
|
K&R and programming.
Since you already know Google, a foundation book and experience is all other you need.
Veni, vidi, vici.
|
|
|
|
|
Hey there
In my VC++ application i see that this function fails in certain times, but was not able to reproduce it.
So am trying to debug and have few questions.
Does the DeleteFile() fails if multiple files are deleted quickly inside a loop and if some files are larger in size?
What other possible causes can lead to DeleteFile() to fail?
|
|
|
|
|
There are some reasons lead to DeleteFile() failure:
1. File not found
2. Path not found
3. Access denied
The first two reason maybe avoidable, but when you delete a large amount of file, depending on the disk status, there is a possibility that the access error happens. I also encountered this error when manually delete a directory which contains a large amount of files and sub directories, so I have to retry several times.
If you use DeleteFile() in your program, I think you should use catch and retry deleting several times before give it up.
"Never memorize something that you can look up." - Albert_Einstein
|
|
|
|
|
Donguy1976 wrote: What other possible causes can lead to DeleteFile() to fail?
If the call fails then you can find the reason by calling GetLastError(), as described in the documentation[^].
Use the best guess
|
|
|
|
|
From the MSDN documentation of DeleteFile:
If the function fails, the return value is zero (0). To get extended error information, call GetLastError.
GetLastError returns an error code which you can convert into a string via the FormatMessage function. See http://msdn.microsoft.com/en-us/library/windows/desktop/ms680582%28v=vs.85%29.aspx[^] for an example. One possible reason might be that you are trying to delete the same file more than once.
|
|
|
|
|
Donguy1976 wrote: What other possible causes can lead to DeleteFile() to fail?
Well, the blindingly obvious are:
1) It doesnt exist.
2) Somthing else has it open.
The less obvious is that your calling code doesnrt have Delete authorisation.
Loo ak the error return, it will tell you all about it.
|
|
|
|
|
Hi,
I created a source filter and is registered successfuly. Every time I use GraphEdit it works fine but when I try to use under MFC/C++ CoCreateInstance fails as not registered (error 0x80040154).
hr = CoCreateInstance(CLSID_PIAsyncFile, NULL,CLSCTX_INPROC_SERVER, IID_IBaseFilter, (void **)&pAsync);
I tried again and again with regsvr32 and successfully registers the filter.
What seems to be wrong here?
I use 32Bit debug builds, on Win7 64bit system.
Regards,
sdancer75
|
|
|
|
|
Make sure you've called CoInitialize or CoInitializeEx properly before calling CoCreateInstance.
|
|
|
|
|
Thanks,
I have called the
HRESULT hr = CoInitializeEx(NULL, COINIT_APARTMENTTHREADED);
at the class construction and
CoUninitialize();
at the destruction.
Any other filter is successfully CoCreateInstance except my filter.
sdancer75
|
|
|
|
|
Get the error returned in hr and use the Error Lookup tool check what the error is.
|
|
|
|
|
Hi,
As you can see in question at the very begging, the error code is 0x80040154 which means "class is not registered"
This is strange since the class is indeed registered at sysWOW3264 (a mirror registry for 32-bit windows apps running on 64bit windows) since my source filter is 32-bit.
Under ms filter graph, I can find and use successfully the filter, but the problem still exists under my MFC project.
PS:In my stdafx.h I declare my filter as follows
#include "INITGUID.H"
DEFINE_GUID(CLSID_PIAsyncFile,
0x8576CEC8, 0x964D, 0x4B51, 0xAC, 0x45, 0x2B, 0x24, 0xDE, 074, 0x8E, 0x23);
Thanx
sdancer75
|
|
|
|
|
Sorry, I didn't notice the error code you posted in your question.
I'm assuming that the MFC project is built as a 32-bit application.
One more thing you can try -
There are both 32-bit and 64-bit versions of regsvr32.exe available in %SystemRoot%\Windows\System32 and %Systemroot%\Windows\SysWOW64.
Try registering the component with either of the 2 and check if the MFC application is able to find it.
|
|
|
|
|
Thanks,
Yes I know and I already tried both versions of regsvr32 (32 & 64 Bit) but still does not work.
Regards,
sdancer75
|
|
|
|
|
All I can think of is that the COM component uses some dependency files like DLLs that GraphEdit is able to find but the MFC application is not.
Does the COM component reside is some folder along with other dependency files.
If so, you can either try to copy the EXE to that folder or change the working directory using the SetCurrentDirectory API.
|
|
|
|
|
I am not sure about that.... The filter resides is a local folder and not in windows subfolder and is a "debug build". I will try to move the filter inside the C:\windows\SysWOW64 and register again.
sdancer75
|
|
|
|
|
|
Finally Solved ! A tiny error at the CLSID declaration !
sdancer75
|
|
|
|
|
Can you please tell me what is the small fix from CLSID declaration?Even i am suffering with this class not registered problem
|
|
|
|
|
Not fix at all, just a typing error in my CLID declaration. What error do you get ?
sdancer75
|
|
|
|
|
Hello there,
If i call DeleteFile on a file that's pretty large, does the function wait until the entire file is deleted before returning?
Or does it return immediately? i.e., the control is passed to OS to complete the task of deletion and then return immediately?
For e.g., if i am deleteing 5 files inside a loop and 2 of them happen to be larger size, will it wait until each file is completely deleted before going to the next one?
If it doesn't, then there's a probability that when the next file is called by DeleteFile the previous one might still be in the process of deletion and it could fail.
Is there a possibility like that?
|
|
|
|
|
From the documentation I'm guessing that it will not return immediately, accurate return codes require the operation to complete. Yikes! Note to self...read the whole thing first! sorry.
modified 3-Jul-13 14:27pm.
|
|
|
|
|
As far as I know, the function returns immediately and the deletion occurs in the background. This is always true if the file is still opened (see DeleteFile[^] in the MSDN):
Quote: The DeleteFile function marks a file for deletion on close. Therefore, the file deletion does not occur until the last handle to the file is closed.
Overall, there should be no significant difference in time for large and small files because the file data itself are left unchanged on the disk. Only the directory entries are touched.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
