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?

>What do you need it for? The Project Manager doesn't care what is in that field. It'll be updated anyway next time the project is saved/built.
>
>>Does anyone know how to calculate the CKVAL field in a project file? I assume it's a checksum like the CKVAL in the resource file, but what's it calculated on?
>>
>>In a resource file it's calculated on the DATA field, like:
>>REPLACE CKVAL WITH VAL(SYS(2007, SUBSTR(DATA,3))) But the project has no DATA field so it's not the same as a resource file.
>>
>>I would think it's computed on the source file in some way to signal to the project that the source file has changed, but I tested a checksum of the entire form file, the object code, and some other things and couldn't get it to match the CKVAL in the project.
>>
>>I also tried SYS(2017) on the record in the project file but no match either.
>>
>>Does anyone know exactly now the CKVAL field in the project file is computed?