|
I'm beginning to suspect the error is valid. The file has not been corrupted, I copy from the vista machine to the XP machine via a USB pen, and I have done this quite a few times. I have also put a few MessageBox alerts in error prone places, but none of them are being triggered.
You'll have to forgive my translation of the error, the XP machine is a Chinese version, and Chinese isn't exactly my first language. But thats more or less what it say's.
|
|
|
|
|
hi
this is a common error that occurs in XP.
It occurs sometimes when u run exes from the Explorer in XP.
try it in command prompt or just restart.
thx Slipnit
|
|
|
|
|
If you are seeing that happen so often that you consider it a "common error", I would guess that you either are either dealing with some really f-ed up software, or something is seriously wrong with your system!
I have only seen that problem with trunated copies/downloads. Never on a complete, valid executable (unless it was a 32-bit vs. 64-bit problem).
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
maybe theres something wrong with my XP.
but i do get it.
maybe i should inform this error msg to Microsoft.
thx Slipnit
|
|
|
|
|
This is not a 64-bit vs. 32-bit problem, is it?
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
James R. Twine wrote: This is not a 64-bit vs. 32-bit problem, is it?
Unfortunatly not. Other from the basic 64-bit compatibility checks, all builds and OS's are 32-bit.
|
|
|
|
|
The problem could lie in the manifest that's being baked into the .exe. I just dragged myself through 48 sleepless hours trying to debug a problem with an app that ran fine on my development machine but wouldn't start on other XP boxes. (The error was mine).
/ravi
|
|
|
|
|
Good to know that a broken manifest file (for a native C++ app) can cause exe not valid errors. I never would have guessed that...!
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
I would have to agree. The manifest has been part of VS2005 for quite some time and is not related to vista. It's something most of us know about, and know how to deal with, yet it would not produce these errors.
|
|
|
|
|
More correctly, the problem was caused by SxS, which was introduced in XP.
/ravi
|
|
|
|
|
|
Hello
Please help me, I want to make an application that deletes all files
from the folder in wich my application is, but one wich's name
I give in the command line.
Are there some functions in Visual C++ for getting all files in a folder?
Thanks
snoopy
|
|
|
|
|
snoopy_321 wrote: Are there some functions in Visual C++ for getting all files in a folder?
See the FindFirstFile()/FindNextFile() pair.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: See the FindFirstFile()/FindNextFile() pair.
Don't forget to use FindClose() after you done with searching. I had a bad expeirence of forgetting of same. which may causes crashes and locking file system resources...
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
Thanks, I think they will work.
bye...
|
|
|
|
|
In additional FindFirstFile()/FindNextFile() use of SHFileOperation or DeleteFile
|
|
|
|
|
In code how can we distinguish a removable drive whether it is a CD/DVD or an USB removable drive (pen drive, flash memory reader/writer)? I used the SDK function GetLogicalDrive() to collect the drive letter and DeviceIoControl() to check if the drive is removable but I don't know how to tell if the drive is a CD/DVD drive or a pen drive asumming that I have both unformatted CD in the CD drive and pen drive in the USB port.
My objective is to format the pen drive from code. At the moment, I rely on the user to select the correct drive. But if he choose the CD drive by mistake, an attemp to format the CD for FAT system would crash the program or put the format call into a loop forever (I spawn to call format.com to format the drive).
Any help would be greatly appreciated. Thanks in advance
|
|
|
|
|
Try GetDriveType to see if that helps make a distinction.
The GetDriveType function determines whether a disk drive is a removable, fixed, CD-ROM, RAM disk, or network drive.
Return Values
The return value specifies the type of drive. It can be one of the following values.
Value Meaning
DRIVE_UNKNOWN The drive type cannot be determined.
DRIVE_NO_ROOT_DIR The root path is invalid, for example, no volume is mounted at the path.
DRIVE_REMOVABLE The drive is a type that has removable media, for example, a floppy drive or removable hard disk.
DRIVE_FIXED The drive is a type that cannot be removed, for example, a fixed hard drive.
DRIVE_REMOTE The drive is a remote (network) drive.
DRIVE_CDROM The drive is a CD-ROM drive.
DRIVE_RAMDISK The drive is a RAM disk.
Maybe you get different value for CD-ROM and the Pen Drive ?
|
|
|
|
|
Thanks Blake. My problem is on the labtop, the CD drive is removable and GetDriveType() would return all removable drive "DRIVE_REMOVABLE"
|
|
|
|
|
If you have code that goes into an infinite loop or crashes, you need to first fix that code! 
Have you looked at the SHFormatDrive(...) function? You can use it to format a drive (after you have determined that you should be formatting it).
You did not mention if you were getting user permission or not, so I would think this is a bad idea. You would have to put some extra code in there to make sure you are not formatting a volume that is in use, and that you really have the one you want. What if the user had multiple storage devices plugged in at once? Which one would you be formatting...?
This sounds like a very dangerous thing to do without first having the user confirm the format action. You could find yourself dealing with a lawsuit over lost data.
Peace!
-=- James Please rate this message - let me know if I helped or not!<HR>If you think it costs a lot to do it right, just wait until you find out how much it costs to do it wrong!
Avoid driving a vehicle taller than you and remember that Professional Driver on Closed Course does not mean your Dumb Ass on a Public Road!
See DeleteFXPFiles
|
|
|
|
|
Thanks James. I thought the infinite loop was because the spawn to format.com never return when a removable CD drive was selected. I can prevent this by checking the media type before formatting. That's what prompted this question.
Yes, SHFormatDrive would do the same job.
I do prompt warning to the user before format the media. Your suggestion to check for user permission is a good idea as the extra precaution. I didn't think about it. Thanks
|
|
|
|
|
Please anyone can send a sample application using CAsyncSocket for communicating two clients which are in different ports. Thanks.
Regards,
Vijaya
|
|
|
|
|
wrote: Please anyone can send a sample application using CAsyncSocket for communicating two clients which are in different ports. Thanks.
This[^] will make a good read.
|
|
|
|
|
Hi you back to the codeproject 
|
|
|
|
|
WhiteSky wrote: Hi you back to the codeproject
Yes. I was always here. Didn't find the time to post replies or queries.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
