>> But this probably maps into an _environmentvar, or how do you set it for compile
>> classlib ?
Actually we already implemented the COMPILE command and we added some keywords as REFERENCES "SomeAssembly". We could add a few more keywords as WARN_UNDECLARED [0 | 1 | 2}.

But if you check this, it should go to the file level something like in C++ where you can put some switches at the file level. VFP already supports some data in the file level as the CODEPAGE info for prgs. So it could go there.



>Hi Samuel,
>
>>It will be a global switch actually. You just mark the checkbox in the Compiler Project Form. I know there are some advantages to make it a #pragma, but we have not pragmas yet.
>
>Even at project level it will be a great help - so sometimes I'll have to add another compile run if building a project with some included code not yet fixed up to level 2. But this probably maps into an _environmentvar, or how do you set it for compile classlib ?
>
>
>>With regards to the tables.
>>You can match your table types to any interface provided that at least one of the fields in the table could match to the interface. The types has not to be exactly the same just compatibles. You will use this syntax:
>>
>>TLOCAL myTable as SomeInterface
>>myTable = GetTableInterface([eSomeAlias],typeof(SomeInterface))
>>It automatically generates on the fly an interface to match SomeInterface. The order of fields is irrelevant.
>>
>>It does not create a struct with offset. Instead when you Request the interface on an USED table it matches the interface / class to the current table layout. If you alter the table it automatically invalidates the cache of matched interfaces. So you can add / remove fields after compilation and your code likely will work if you did not make an incompatible change. Of course if you removed a field and then run your code without recompiling:
>>
>>? MyTable.MyRemovedField && it will blow away.
>
>As that would happen in vfp as well, it should<g>. But I was wondering about changing from date to datetime and vice versa, or int to double and vice versa. Changing Int to VarChar I'ld expect a crash, even if in bare vfp it would still run. Some enhancements have sharp edges, especially if something REALLY nice like the further possibilities described with
>MyTable.SomeField = eValue
>
>come into possibility. This makes coding "intermediate datastructures" more exchangable, as a switch from cursor to collection or array of scatter objects needs drastically less changes and changes belonging to"real" data representations can be kept in "old" syntax for clearness or in new if speed is needed. verrry nice.
>
>regards
>
>thomas