Re: Compiler doesn't seem to work properly at all times

From: Anynomous (wipeout64_at_hotmail.com)
Date: 11/04/04


Date: Thu, 04 Nov 2004 18:07:10 GMT

I just learned that not using the project hook causes this. I suppose this
means a re-write of the entire app? I was converting non-visual code to
visual foxpro which is why I didn't use a proj. hook

"Dan Freeman" <spam@microsoft.com> wrote in message
news:%23q0KD8owEHA.1092@TK2MSFTNGP10.phx.gbl...
> Well, let's boil down the symptoms: something is preventing your changes
> from being written to disk, and it's a problem that is not often reported.
>
> What can prevent disk writes? Anti-virus software actually has that as
part
> of its job. <g> Likewise disk caches (turn off write-ahead cacheing --
it's
> on by default).
>
> What else is unique about your environment that's giving your this unique
> behavior?
>
> Dan
>
> Anynomous wrote:
> > This sounds like a good guess, but wouldn't everyone have this
> > problem if it were the antivirus software? It was on someone else's
> > machine when I first discovered that my changes were not being saved
> > properly and it wasn't even the same application that I normally work
> > with. My antivirus software doesn't allow me to choose what file
> > extensions to ignore.
> >
> >
> > "Dan Freeman" <spam@microsoft.com> wrote in message
> > news:u5X03ScwEHA.2600@TK2MSFTNGP09.phx.gbl...
> >> I've never experienced that.
> >>
> >> Do you have VFP file extensions excluded from your anti-virus
> >> program?
> >>
> >> Dan
> >>
> >> Anonymous wrote:
> >>> In version Visual FoxPro 7.0, the compiler doesn't always seem to be
> >>> doing it's job. I've noticed this also in version 6.0 regardless of
> >>> the service packs. Well, frequently I dismissed it thinking perhaps
> >>> it's an error in code or I changed something that effected it. Well,
> >>> just the other day I simply took a label off of a screen and I
> >>> thought I deleted all references to it. Ran the screen several
> >>> times with no problem. Either later in the day or the next day, I
> >>> ran the screen and received an error that I had not deleted a
> >>> reference in the init of the screen. Regardless of what I had done
> >>> in the screen, the reference in the init error should have
> >>> displayed. It was a plain no conditional reference. I did notice in
> >>> version 6.0, changes that I had done seemed to be undone after a
> >>> few compiles. I stopped this from occurring by deleting the .bak
> >>> files frequently. Well I have the .bak file option shut off in
> >>> version 7.0. It seems that the files in the background (screens can
> >>> be treated as tables like the reports), these changes aren't saved
> >>> properly or permanently for some reason. Anyone else experienceing
> >>> this? Anything I can do about this? It's embarassing and I can't do
> >>> my job properly if I have to be my own manual compiler!
>
>