|
Hello,
I'm having a problem when I try to save a file in a different directory (let's say that I simply want to duplicate the file). I have a "default.wav" in my directory and I use a dialog to save it (duplicate it) in another directory with a different name. This is my code:
============
CString strFile;
(...)
strFile = dlg.GetPathName();
(...)
CFile file_orig,file_dest;
char *pBuffer;
(...) <- part that creates "default.wav" in the same directory
file_orig.Open("default.wav", CFile::modeRead);
int length = file_orig.GetLength(); // <<<<< here is the problem !!
pBuffer = (char*)malloc(length);
file_orig.Read(pBuffer, length);
file_orig.Close();
file_dest.Open( strFile, CFile::modeCreate|CFile:: modeReadWrite);
file_dest.Write(pBuffer, file_orig.GetLength());
file_dest.Close();
free(pBuffer);
==============
Any solution that works can be valid (without including aditional libraries if possible). I just want to keep it as simple as possible.
Thanks in advance!
|
|
|
|
|
|
Without knowing the problem you are having, I do believe you should have an access mode AND a
sharing mode when using CFile::Open()
file_orig.Open("default.wav", CFile::modeRead | CFile::shareDenyWrite);
int length = file_orig.GetLength();pBuffer = (char*)malloc(length);
file_orig.Read(pBuffer, length);
file_orig.Close();
file_dest.Open( strFile, CFile::modeCreate|CFile:: modeReadWrite | CFile::shareExclusive);
file_dest.Write(pBuffer, file_orig.GetLength());
file_dest.Close();
If that doesn't help, maybe try checking the return code
|
|
|
|
|
The error consists on an error box saying that it didn't find a file without a name (not exactly in those words because my OS is in spanish language, but that's basically what it says).
I've also tried the CopyFile option without success. I have to include "Windows.h" with the headers, include Kernel32.lib in my project settings, and then i would have to put something like this: CopyFile('default.wav',PChar(strFile),TRUE); (am i right?)
but it gives "error C2015: too many characters in constant" and error "C2065: 'PChar' : undeclared identifier"
Well, i think it it is a little bit too late for me . Tomorrow I will keep trying to find a solution.
|
|
|
|
|
I'd say check your pathnames - the source pathname may require the full path with the name unless
you set the current directory or it's in the system path.
Also, when using CFile::Open, use the 3rd param and you can examine the exception if it fails
(returns 0).
And you need to do all this before you sleep 
|
|
|
|
|
I've always used the shell for this:
SHFILEOPSTRUCT sf;
sf.hwnd = m_pMainWnd->m_hWnd;
sf.wFunc = FO_COPY;
sf.pFrom = pSrc;
sf.pTo = pDest;
sf.fFlags = FOF_NOERRORUI | FOF_SILENT | FOF_NOCONFIRMATION | FOF_NOCOPYSECURITYATTRIBS;
BOOL bSuccess = (SHFileOperation(&sf) == 0);
|
|
|
|
|
Use can use CopyFile for this purpose
Known is a drop, unknown is an ocean
|
|
|
|
|
Ravi Bhavnani said 
|
|
|
|
|
Hi,
I have a problem and I could not find the answer on the internet. In my code I create a filter graph for rendering video files with audio components. I create the filters automatically using the RenderFile() function. I want to insert another filter just vefore the video renderer filter in order to process the video component of the file. Since i use the code for different kinds of video files I cannot find the renderer filter using its name.
For the files without audio, I enumerate the filters and I check for the output pins of the filters one by one. For the filter with no output pin I understand that its the video renderer filter, so i disconnect it and insert my OpenCV ProxyTrans filter. However, for the video files with audio I don't know how to find the video renderer file. In the method I mentioned above it is possible to find the audio renderer filter as well. Could you please help me on this? I would appreciate if you explain your solution with one or two lines of codes. Since I am a beginner in DirectShow it sometimes gets difficult for me to implement the suggestions of the expert people.
Thank you in advance.
Regards.
|
|
|
|
|
Before disconnecting the pin, can you call ConnectionMediaType() on it and check the majortype
member of the AM_MEDIA_TYPE struct? MEDIATYPE_Video would be the one to look for.
Mark
|
|
|
|
|
This is pretty cryptic. Anyone with ideas would be appreciated. This line of code in a header file generated by the Typelib Wizard
#import "C:\\Program Files\\Microsoft Office\\OFFICE11\\MSOUTL.OLB" no_namespace
causes the compiler to issue the following warning
d:\projects\reds\filemail\cfolders.h(3) : warning C4278: 'CopyFile': identifier in type library 'C:\\Program Files\\Microsoft Office\\OFFICE11\\MSOUTL.OLB' is already a macro; use the 'rename' qualifier
Does this mean that the typelib is unusable since CopyFile exists within the typelib and I can't change it?
Chris Meech
I am Canadian. [heard in a local bar]
I agree with you that my argument is useless. [Red Stateler]
Hey, I am part of a special bread, we are called smart people [Captain See Sharp]
The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
I wish I could remember what it was like to only have a short term memory.[David Kentley]
|
|
|
|
|
You may have seen this, but if not maybe it will help...
From the error msg docs:
'identifier': identifier in type library 'tlb' is already a macro; use the 'rename' qualifier
When using #import, an identifier in the typelib you are importing is attempting to declare an
identifier identifier. However, this is already a valid symbol.
Use the #import rename attribute to assign an alias to the symbol in the type library.
|
|
|
|
|
Thanks Mark. I understand using the rename to eliminate the warning, but won't that cause other problems. If the writer of the typelib used 'identifier', isn't it reasonable to assume that elsewhere in the code there will be references to this 'identifier' type and these will now compile to the incorrect 'identifer' type as I've aliased away the intended one with the rename?
Also I'm probably missing something, but why doesn't the producer of the type library recognize that a macro and an identifier share a common name and change one to avoid the warning.
Chris Meech
I am Canadian. [heard in a local bar]
I agree with you that my argument is useless. [Red Stateler]
Hey, I am part of a special bread, we are called smart people [Captain See Sharp]
The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
I wish I could remember what it was like to only have a short term memory.[David Kentley]
|
|
|
|
|
What Mr Hewitt said
Depending on the office version, there's others like PlaySound and RGB 
|
|
|
|
|
From <winbase.h> which is included by <windows.h>:
#ifdef UNICODE
#define CopyFile CopyFileW
#else
#define CopyFile CopyFileA
#endif // !UNICODE
This is the macro the warning is referring to. This is all part of the evils of macros: because macros don't obey C++ scoping rules namespaces and such can't be used to have multiple but non-conflicting duplicate names. I don't think this warning will cause you any problems however. To rename the method (although you don't really need to) you do something like this:
#import "C:\\Program Files\\Microsoft Office\\OFFICE11\\MSOUTL.OLB" no_namespace rename("CopyFile", "OfficeCopyFile")
Steve
|
|
|
|
|
Great explanation, Stephen. Clears things up perfectly for me.
Chris Meech
I am Canadian. [heard in a local bar]
I agree with you that my argument is useless. [Red Stateler]
Hey, I am part of a special bread, we are called smart people [Captain See Sharp]
The zen of the soapbox is hard to attain...[Jörgen Sigvardsson]
I wish I could remember what it was like to only have a short term memory.[David Kentley]
|
|
|
|
|
There's a flag to #import called (I think) exclude that will prevent certain symbols from being included in the generated tli/tlh files. Try that if you don't need the CopyFile method in the typelib.
|
|
|
|
|
I am managing some medium sized projects in C++ 6. Are there some good reasons to migrate to Visual C++ 2005? The only ones I can think of are:
1. Potentials to utilize 64bit technology. I guess c++ 6 compiler will not support 64 bit.
2. Potentials to write .NET modules to the project. However, it could be complicated to have managed code and unmanaged code mix together.
3. Better IDE.
Anyone already done the migration? Please share your precious experience with me.
Thanks!
|
|
|
|
|
VC6 is rubbish, in terms of STL and standards conformance. That's why I would move.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
|
|
Just be careful of the potential headaches caused by VS2005's manifest generation. Apps built by VS2005 require the presence of an embedded or external manifest when run on XP and Vista. I've suffered (and continue to suffer) no end of pain trying to get my app to run on other people's XP boxes, thanks to VS2005's inconsistent generation of manifests. 
I've had no such problem with VC6 built versions of the same app.
/ravi
|
|
|
|
|
There's no simple answer. If VC6 is meeting your current needs, why switch? I for one don't think the VC8 IDE is better.
|
|
|
|
|
If you're writing VC++ code, VS2005 makes your life harder because the new IDE is built around .Net development.
For VC++ programmers, the ONLY real reason to switch is to get the newest version of MFC, but be prepared for a bit of work to get your code to compile clean. A lot of MFC functionality has changed (be especially aware of COleDateTime changes). Also, if you do move to VS2005, make sure you also download and install the service pack that was released in December.
We had an app that was over 670,000 lines of code spread across 24 sub-projects. The initial compile resulted in over 2000 errors, and over 4000 warnings. It only took about two hours re-factor the code code because a lot of the warnings/errors were just duplicates of prior entries.
Lastly, despite what Christian said, VC6 is most certainly NOT rubbish. If you're in the middle of development on a project using VC6, I'd stick with VC6 for that version and move to VS2005 for the next major revision.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Thanks for all the input. It's very helpful.
When do you think that Visual C++ 6 will be out-of-date? i.e, Microsoft may decide one day to stop supporting it and it may have trouble with compatability with the next version of windows.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
