>The project manager appears to use it (along with the timestamp field) to determine if a source file has changed so it can recompile it. The problem is that the project manager often gets confused and recompiles forms/classes even if they haven't changed which can play havoc with a source control system (during a DST change, for example, but there are other circumstances as well). It seems to be more profound with large projects like ours. I'd like to be able to "trick" the project manager into thinking that the current version of a source file matches the timestamp and checksum in the project so it won't recompile it.
>
>I can update the 32-bit timestamp in the project file to match the source file, but the CKVAL field seems to signal the project manager that the source file has changed.
>
>Do you know how it's calculated?

It's obviously a sys(2007) of something involving the symbols memo, because it's blank when this memo is empty, but for the several things I tried (similar to sys(2007, substr(...)) it does in foxuser), I wasn't getting anything meaningful, but then, this being a CRC (16-bit - ckval never goes over 65535), you never know whether you're close or not. Off by one or off by hundred, the results are equally far from right ;).

But then even if you manage to hit it off with ckval, it's still no guarantee that it won't recompile from time to time (or more often). I'm fighting the same battle every day, and it always recompiles the same classlibs, no matter the dates. I still can't make any sense to why do some get recompiled each time, others never.

OK... got back to this message after an hour or two, dug a bit more, and it seems the ones which get recompiled are those with .h files. I'm still not quite clear why, but at least that's some start.