Hi Mike,

>I'm sure many were more concerned with EXE size long ago. It doesn't seem to matter too much anymore. Even when it did matter, one could always create multiple exes, sending only the changed exes over the slow connections available at the time.

I agree that it is not a problem in many circumstances. However, faced with two situations where semi-automatical updates are done via dail-in RAS connections, compression of such exe files are sure welcome. Further I've got some client accessing the VFP application via a 512 Kbps WAN connection. Though I use a loader to place the executable locally, (new) users will not be happy waiting an (updated) application to start up when its size is 10 MB.

Another thing is that many of my clients have a incomming mail size limit of 1.5 MB. Usually I can get my update to be within 1 MB (Compressed, with winzip and the selfextractor), but sending 2 updates (for two different products) has been causing various problems. So in practise I try to get my exe size as small as possible (< 1.5 MB). With various coding techniques I have been able to write fairly complex application in a very small VFP exe size. Getting rid of the sourcecode of form and classes would be welcome not only from a size perspective, but also from a security standpoint.


>If its an integer key which starts incrementing at -2 billion, there will be a total of 4 billion keys. The key must be generated during an append when there is a parent-child-grandchild or greater relationship. With careful handling, the keys could be generated during save when there is only the one table or a parent-child relationship. However, with 4 billion keys, why not just generate them all at the add? It won't matter if some are wasted. Views will need a way to generate the PKs from the table in advance too.

It is my hunch this will not be possible from the autoincrementing key feature in VFP 8. because it will likely only generate a value when a record actually is written to the table, hence this problem.

>>I can imagine that for the thousands of traditional VFP desktop developers, VFP 7 has not too much to offer over VFP 6. Intellisense might look usefull at first site, but does it make a 6 month job a 3, 4, or even a 5 month job ? Personally I don't think so. Coding seems to cost only a fraction of the whole development process. Intellisense is speeding up the codingprocess just a littlebit, so the overall effect might be neglible. One of the main reason to switch to VFP 7 was the improved COM handling (capturing events), but I wonder if I could do it with the VFPcomm utility either. For the end-users the only visible thing seems the improved GUI. As I said before, it seems not to be that significant.
>>
>
>Intellisense helps in other ways. It can reveal properties and methods of other objects like MS Word. The time saved comes from not having to go dig in a manual or Words help as much.

I'm aware it does, but again, what is the impact on a 6 month project ? I guess it depends on the type of project, but I guess that for the majority of project the impact is not that significant as advertised by the introduction of VFP 7.

Walter,