Steve,

>>Well, think about it a little. On the command line the object is actually created. In code that's not the case. It would surely be nice to have, and perhaps we'll see it in a future version and in VFP7 you could check the syntax in the command window, but I'd think that it would be fairly tricky to do in an editing window.
>>
>
>
>Doug,
>VC++ & VB already do it in an editor window, and have for a while. And, according to reply from Chris, VFP7 does work in a editor with proper declaration...so it sounds great to me.

I saw that. I meiised the part about having to declare the object with the line

LOCAL loObj AS ADODB.Recordset

which also makes sense now that I think about it. Duhh... <g>


>
>
>>>
>>>>OPTIONAL NATIVE COMPILER
>>>
>>>Will never happen...use VC++ for that, and be glad VFP is not going to rely on CLR. :)
>>
>>You know, I think there's an outside chance we could get this in a future version. You'd probably need some sort of compiler directive that would be on the order of SET MACRO SUBSTITUTION ON/OFF where the compiler could check to see if you're using '&' or other p-code-dependent type commands. That and making sure that all variables and their types were pre-declared ....
>>
>
>Well, I would certainly not mind the native compile option, but it falls into the 'I'll believe it when I see it' category :)

<g>

Sure.. Did you ever hear of a product named "Force" ? It came out originally sometime in the late 80's but required that everything be declared up front, hence the inability to deal with macro substitution commands. It was really really fast even compared with FoxBase+, which even then was Speed King. Just no macro subs. If you had the ability to flip some sort of switch and were willing to take the hit on having no macro subs then I'd think that would be a fair tradeoff. If you could then the next question would be to determine whether or not there were enough speed benefits to make the effort worthwhile. That seems to me to be an unknown at this point I'd suppose...