Hi -

I have a client that is using a FPW 2.6 application and has suddenly
started getting an I/O operation failure. I researched into the Foxpro
archives and found that just inserting a CD drive takes care of the
problem and it did.

Q. Why in thw world is the FPW 2.6 appliction NOW trying to access the
CD drive? I am familiar with the code and there is nothing in the code
that accesses a CD drive?


Thanks in advance...

Shah

shahjagat (AT) aol (DOT) com schrieb:
On Fpw put everything needed for development on C:\
or always use the patch program for this kind of error.

HTH

tg

What 'Patch Program' is this? I am familiar with the 'Divide by Zero
Error'. Is there another patch?

Shah

This is a "known" problem when you develop your app on anything but C:

Put all files on C: or patch your resulting exe/app looking for D: e: f: etc
and replace it with C: (personally; it's easier to develop all on C

On 2 May 2005 06:27:07 -0700, shahjagat (AT) aol (DOT) com wrote:


---
Remove x's to send.

Shah,
There actually was a MSDN KB article on this issue a number of years ago, but
has been purged (even VFP 3, 5 and 6 are unsupported now!).
Go to http://www.abri.com/foxpro.html and get the free FixDrive - it's not a
patch to FP - just your .EXE.

Rick

<shahjagat (AT) aol (DOT) com> wrote

Josh Assing wrote:
user move their CD drive letter up one, so that there is a blank. It
will stop looking as soon as it hits a non-existent drive letter. I
used to have a program that would fix this problem, but finally purged
it and the source code long ago.

The actual problem is that there are references to drive letters other
than c: in the FPW application. If you had something that could open
the file and replace any reference to a drive letter to c: this would
fix the problem. I think that Abri technologies has an program on their
site for free that will deal with this. Frankly, those who are
referring to a patch, are talking about patching your application/exe,
not FPW.

As a matter of fact, I just took a quick look and found my code in FPW
that will fix this problem. This actually uses low level file I/O to go
through your app and change all drive letter references to c: so that
the problem goes away. Someone at some point had written the same code
is C++, but I have misplaced it and frankly it's just not worth the time
to do it again. Fix code starts below:

-->
* Program....: FIXAPP.PRG
* Version....: 1.0
* Author.....: Cy Welch
* Date.......: April 29, 1997
* Notice.....: Copyright (c) 1997 MetSYS Inc, All Rights Reserved.
* Compiler...: FoxPro 5.0
* Abstract...:
* Changes....:

PARAMETERS lcFileMask

lnParm = PARAMETERS()
IF lnParm = 1
nCount = ADIR(aApps,lcFileMask)
IF nCount > 0
FOR nCurApp = 1 TO NCount
WAIT WINDOW "Processing: "+aApps(nCurApp,1) NOWAIT
DO fixpaths WITH aApps(nCurApp,1)
ENDFOR &&* nCurApp = 1 to NCount
ELSE
WAIT WINDOW "Nothing Matches your FileMask, try again" TIMEOUT 25
RETURN
ENDIF
ELSE
cOldDir = SYS(5)+CURDIR()
cDirectory = GETDIR("r:\demo\metdemo","Find the Dist Files")
IF !EMPTY(cDirectory)
SET DEFA TO (cDirectory)
ELSE
WAIT WINDOW "You MUST select a directory to continue" TIMEOUT 25
RETURN
ENDIF
nCount = ADIR(aApps,"*.APP")
IF nCount > 0
FOR nCurApp = 1 TO NCount
WAIT WINDOW "Processing: "+aApps(nCurApp,1) NOWAIT
DO fixpaths WITH aApps(nCurApp,1)
ENDFOR &&* nCurApp = 1 to NCount
DO fixpaths WITH "security.exe"
DO fixpaths WITH "metsys.exe"
DO fixpaths WITH "reindex.exe"
SET DEFAULT TO (cOldDir)
ELSE
WAIT WINDOW "There aren't any App's in this Directory" TIMEOUT 25
SET DEFAULT TO (cOldDir)
RETURN
ENDIF
ENDIF
WAIT CLEAR
CLOSE ALL

************************************************** **********
* Function....: fixpaths
* Called by...:
*
* Abstract....: Fixes Paths in Apps to point to C:
*
* Returns.....:
*
* Parameters..:
*
* Notes.......:
************************************************** **********
FUNCTION fixpaths
PARAMETERS cAppName
PRIVATE cChar1, cChar2, cChar3, nReadPos
STORE " " TO cChar1, cChar2, cChar3
STORE 0 TO nReadPos
nFile = FOPEN(cAppName,2)
IF nFile > 0
DO WHILE !FEOF(nFile)
nReadPos = nReadPos + 1
cChar = FREAD(nFile,1)
cChar1 = cChar2
cChar2 = cChar3
cChar3 = cChar
IF cChar2 = ":" .AND. cChar3 = "\" .AND.
INLIST(UPPER(cChar1),"D","E","F","G","H","I","J"," K","L","M","N",;
"O","P","Q","R","S","T","U","V","W","X","Y","Z ")
= FSEEK(nFile,nReadPos -3)
= FWRITE(nFile,"c")
= FFLUSH(nFile)
= FSEEK(nFile,nReadPos)
STORE " " TO cChar1, cChar2, cChar3
ENDIF && cChar2 = ":" .AND. cChar3 = "\"
ENDDO && !FEOF(nFile)
=FCLOSE(nFile)
ELSE
WAIT WINDOW "Warning: File Not Found:"+cAppName
RETURN
ENDIF && nFile > 0
RETURN
*EOF fixpaths
-->
Code ends.

--
Cy Welch
Senior Programmer
MetSYS Inc
http://www.metsysinc.com

Thanks everyone for the info. You were right. I recently moved
everything from my Hard Disk C: to a second hard disk D: and then
compiled the project. Things went back to normal when I moved it back
to C: drive and then compiled it.

Thanks again....

Shah

This isn't always a "good" choice tho.

Windows (if you use SFC) wants teh cd to be the same letter as it was when
installed.

And if the author is using FPW -- chances are, his target audience isn't
"modern" either.

-j

---
Remove x's to send.

I think Josh is right, We are 'old fashioned' here. We have a
humongous application out there and was developed in 1995 in FPW 2.6.
Over the years we kept on adding enhancements to it and it grew and
grew. We are in process of migrating to VFP but it is such a mind
boggling task and is taking us forever.