Walter and Houston:

VB does indeed allow for a compile to native code (since version 5.0). However, this has no bearing on forms. The speed gains are found in iterative calculations.

I remember a few years ago (maybe still?) some books suggested that VFP programmers consider writing out intense calculations to a C-penned library file, to gain some speed (I worked on one stats-based project that did just that for some specialized algorithms and the gains were noticeable). These are exactly the sort of cirsumstances where the VB native-compile option is helpful. And yes, for those types of circumstances, the native code compile option creates extremely quick code - probably quicker than the VFP p-code equivalent. But, think about it in your own apps -- how often does this type of code represent your performance log-jam? Probably not too often.

Again, though: VB's native compile has absolutely zero effect on form refreshes.

(Walter, perhaps you are confused by the fact that this is not a Delphi-style one-file EXE. VB apps compiled to native code still require the run-time files. But, the calculations that it can compile into native code, rather than p-code, are indeed compiled that way.)

OT: I wish there was a way to cross-post this to the VB side of the UT...


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Houston,

VB does not compile to native code, nor will future versions.

Walter,

>>Probably VFP faster, many VFP objects are just simple drawings on form, when VB objects are real Windows.
>>>are screen updated fast in VB than in VFP ?
>>>Rajesh
--------------------------------------------------------------------------------
I was under the impression that because VB is compiled to 'native' code it typically runs faster than VFP in most regards. The only area in which VFP excels (relative to VB) is in data processing - fortunately this is pretty much all we want to do in VFP ;-)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>