By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,853 Members | 1,034 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,853 IT Pros & Developers. It's quick & easy.

Cant find a logical explanation for this error

P: n/a
Ok first off, i am a total beginner at this groups stuff and i have no
clue how this works. This is probabaly the wrong group for my problem
but i will post it anyways. Learning by doing right?

I will post a code snippet and explain my problem. I cant seem to find
a logical explanation why this problem would occur after trying to
figure it out for a few hours. However I am probably just blind and/or
stupid and you will realise where i go wrong at first glance. Using
Borland C++ Builder 6 btw.

This might get a bit long and it might be in the wrong group but it
also might be interesting. So...uhm....read it :)

SHFILEOPSTRUCT sfo = {0};

//-- Part 1:-----------------------------
m_PLCDest = m_PLCDest + "\\Vorbereitung\\";
CreateDir ( m_PLCDest );
sfo.wFunc = FO_COPY;
sfo.pFrom = m_PLCSource.c_str();
sfo.pTo = m_PLCDest.c_str();
sfo.fFlags = FOF_SIMPLEPROGRESS | FOF_NOCONFIRMATION |
FOF_NOCONFIRMMKDIR | FOF_RENAMEONCOLLISION;

SHFileOperation (&sfo);
// End Part 1-------------------------

//-- Part 2:--------------------------------
sfo.wFunc = FO_COPY;
sfo.pFrom = "J:\\PROGRAMM\\Beckhoff\\A_NeuerKunde\\ABxxxxx \
\Sys_Manager";
sfo.pTo = m_PLCDest.c_str();
sfo.fFlags = FOF_SIMPLEPROGRESS | FOF_NOCONFIRMATION |
FOF_NOCONFIRMMKDIR | FOF_RENAMEONCOLLISION;

SHFileOperation (&sfo);
//End Part 2-------------------------------

//-- Part 3: --------------------------------
strDestParam = strDestParam + "\\visfil3";
sfo.wFunc = FO_MOVE;
sfo.pFrom = strDestParam.c_str();
sfo.pTo = m_PLCDest.c_str();
sfo.fFlags = FOF_SIMPLEPROGRESS | FOF_NOCONFIRMATION |
FOF_NOCONFIRMMKDIR | FOF_RENAMEONCOLLISION;
SHFileOperation (&sfo);
//End Part 3-------------------------------

As you can see i am using SHFileOperation and SHFILEOPSTRUCT to copy
or move a few directories. Now what happens is the following. When i
execute the code, Part 1 works fine. Then in Part 2 i get an error
message saying "File cant be copied. Cant read sourcefile or cant read
from the source data carrier" (Freely translated from german). I click
away the error message. After that Part 3 is executed without
problems. BTW: All the directories I am trying to copy/move are on a
network drive which is mapped as J: on my PC.

Now comes the interesting part. If i remove part 3, part 1 and 2 work
perfectly. If I execute part 3 before part 2 ( meaning i simply cut
and paste the code of part 3 between part 1 and 2 all 3 parts work
fine. I have tried various other combinations and came to the
conclusion that it only works if part 2 is actually the last part to
be executed.
How can this be? How can code which has not even been executed (part 3
in this example) produce an error in previous code that works fine
otherwise.

Code should be executed line by line right?

Also you dont need to worry too much about the actual code. I simply
want to have an explanation how the existence of part 3 can have an
impact on the execution of part 2.

Any ideas?

Thanks to those who actually read this.
Jan 4 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
There are a couple of rules like post complete code (for us just to
copy-paste and compile), explicitely copy-paste all compiler and
runtime errors you encounter (your 'this works fine' gives nearly no
clue) etc. You'd better learn them by not doing but by reading
instead. Check a couple of pages of topics here and read the
newsgroup FAQ (now you know it exists, so find it).

WolfgangS wrote:
sfo.pFrom = "J:\\PROGRAMM\\Beckhoff\\A_NeuerKunde\\ABxxxxx \
\Sys_Manager";
The difference in part 2 is in this string. Doesn't it give you a
clue? ;-)
Jan 4 '08 #2

P: n/a
WolfgangS wrote:
>
Also you dont need to worry too much about the actual code. I simply
want to have an explanation how the existence of part 3 can have an
impact on the execution of part 2.
Hard to tell without a something that compiles, maybe part 2 writes
through an uninitialised pointer and corrupts something.

Two tips:

Post example the shows the problem and can be compiled (generating this
often flushes out the problem before you post).

Use whatever memory access checking your tools provide.

--
Ian Collins.
Jan 4 '08 #3

P: n/a
On 4 jan, 04:23, WolfgangS <wolfgang_stad...@gmx.atwrote:
[snip]
As you can see i am using SHFileOperation and SHFILEOPSTRUCT to copy
[snip
I have tried various other combinations and came to the
conclusion that it only works if part 2 is actually the last part to
be executed.
How can this be? How can code which has not even been executed (part 3
in this example) produce an error in previous code that works fine
otherwise.

Code should be executed line by line right?
I have no idea of what SHFileOperation does, nor of the values of
m_PLCSource and m_PLCDest, so this is pure guess:

One possible explanation is that SHFileOperation is asynchronous, so
that the operation made in part 3 start executing before the initiated
in part 2 have completed. You could verify this forcing a pause in
execution (with a sleep(), or by reading from std::cin, for example)
before part 3.
Jan 4 '08 #4

P: n/a
On Jan 4, 4:23*am, WolfgangS <wolfgang_stad...@gmx.atwrote:
[snip]
Now comes the interesting part. If i remove part 3, part 1 and 2 work
perfectly. If I execute part 3 before part 2 ( meaning i simply cut
and paste the code of part 3 between part 1 and 2 all 3 parts work
fine. I have tried various other combinations and came to the
conclusion that it only works if part 2 is actually the last part to
be executed.
How can this be? How can code which has not even been executed (part 3
in this example) produce an error in previous code that works fine
otherwise.
It's just a guess, since you have not really supplied enough
information to debug your code, but my guess is you have a
corrupted memory someplace. And moving code around means that
different stuff is getting over written.

Round up the usual suspects:
- Incorrectly initialized pointers.
- Dangling pointers.
- Array overflows.
- Off-the-end errors.
- Off-by-one errors.

And so on.

Often you can get some hints about this from debug tools.

Also, do what others have suggested. Find the minimal
chunk of code you can compile and show the problem.
Often this makes the probelm obvious and you don't need
to post anything.

Also, you might find more and better help if you posted in
a newsgroup that is related to the library you seem to be
using. A construct like

SHFILEOPSTRUCT sfo = {0};

sure isn't part of standard C++. Maybe it's a commercial
library? Maybe it's a roll-your-own? Either way it's not
part of standard C++, which is what we speak here.
Socks
Jan 4 '08 #5

P: n/a
On 4 jan, 11:18, "Eric.Malenf...@gmail.com" <Eric.Malenf...@gmail.com>
wrote:
On 4 jan, 04:23, WolfgangS <wolfgang_stad...@gmx.atwrote:
[snip]
As you can see i am using SHFileOperation and SHFILEOPSTRUCT to copy
[snip]
I have no idea of what SHFileOperation does, nor of the values of
m_PLCSource and m_PLCDest, so this is pure guess:

One possible explanation is that SHFileOperation is asynchronous, so
that the operation made in part 3 start executing before the initiated
in part 2 have completed. You could verify this forcing a pause in
execution (with a sleep(), or by reading from std::cin, for example)
before part 3.
Forget about that. Out of curiosity, I googled SHFILEOPSTRUCT and
found this:
http://msdn2.microsoft.com/en-us/lib...95(VS.85).aspx
Read the notes about the pFrom and pTo members.
Jan 4 '08 #6

P: n/a
Thanks for the replies and advice guys.

I will read the FAQ as soon as i find time to do so.

On 4 Jan., 20:03, "Eric.Malenf...@gmail.com"
<Eric.Malenf...@gmail.comwrote:
On 4 jan, 11:18, "Eric.Malenf...@gmail.com" <Eric.Malenf...@gmail.com>
wrote:
Forget about that. Out of curiosity, I googled SHFILEOPSTRUCT and
found this:http://msdn2.microsoft.com/en-us/lib...95(VS.85).aspx
Read the notes about the pFrom and pTo members.
What you are getting at is this right: "The list of names must be
double null-terminated."

I did of course read it but i seem to have misunderstood it. I assumed
the double null-termination was only necessary when actually using a
list and not only 1 value. Anyways i tried it with double null
terminating pFrom and pTo and no error has occured since then.

That still doesnt explain why switching the code around would make a
difference but im satisfied for now.

Thanks guys.
Jan 7 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.