>Hi Walter:
>
>Our compiler effort actually let you write both the typical VFP code so flexible and dynamic that we all like. The type of code that makes working with automation so easy.
>
>And also it lets you use optional strong typing that let you perform checking at compile time and catch early errors, like those nasty when you invoke a method / procedure with more parameters that it takes, or when you spell bad a property / method. Strong typing also bought you a real speed over a dynamic model. You can check a little over the syntax extensions for strong typing here .
>
>So you can have both models where it makes sense.

And THAT makes perfectly sense. Thanks for that. I'll be following your product. It is just a pitty that all those nahsayers think inside the MS box and really have no clue about such advantages. I'm glad to see that you're taking the right and more sensible appraoch: taking the best of both worlds.

I wish you success in a david vs goliath project.


Walter,




>
>>>>Though I really want the compile to pick out those errors, it sometimes is a PITA.
>>>>Have you tried to write some office automation in .NET without knowing which office version the end user is using ??
>>>
>>>Walter,
>>>
>>>there is something that I would like to add to this :
>>>I would catagorize habbits like changing variable types througout code and using macro execution (&) under 'bad design'.
>>
>>Sure, but that is not exactly what I'm trying to refer to. If in VFP I do a
>>

oWord = CREATEOBJECT('Word.application')

>>Then it would execute fine no matter what office version you are using. You can now use the oWord variable to do your mailmerge without any difficulty as long as the code is correct and the methods, events and properties accessed do exist for that given office version. Now take your .NET and try to do the same and post your result up here.
>>
>>I agree that variables should stay the same type throughout the application, but there is more to it. In VFP you can add optional variables of different types and check them at the beginning of your procedure. In.NET you'll use overloading. It is not the same thing and from a complexity POV (i've programmed in C/C++), I personally don't like it. I find it a clumsy way to keep the compiler happy rather than it helps me in my productivity.
>>
>>Walter,
>>
>>
>>
>>
>>
>>
>>Of course there are always exceptions and maybe the office automation is one of them and in that case they are in the caterogy ('glad I have them'). Unfortunatly their usage is too often in the first ...