OK. I can understand that - though I personally would focus on the ones that don't work - maybe have a wiki where you list the functions (I think someone suggested that earlier) and whether or not they are implemented, and in what language - then people can focus on the ones that are underimplemented or not implemented - getting quicker betas out with more functionality.

Anyway, that's my 2 cents...

In any case, good luck with your work.

yag


>Hi Alan:
>
>We don't want to reinvent the wheel, Kamel and Flash put a lot of effort, but Several of the functions are not compatible with the functionality of VFP, those functions have the intention but not the functionality... Some that come to my mind are the FOpen, FCreate, those even don't return a number!. For those we better come with our own implementation and what better than to do it in VFP language.
>
>Of course, we are not closing the doors to any implementation in other languages. We just like more a VFP implementation and also most of the functions can be written easily in VFP.
>
>Another reason is for extensibility, we want our community to be able to improve and perfect the functionality and as you know it is easier to do that in VFP than in other languages, and you really know that, the code in the FFC and XSource would have taken a lot more of effort to write it in another language as C++ or C#.
>
>So if not solution comes implemented in VFP and there is one in other language, we'll use it because we want to speed this as much as possible, but for our community right now the best language for this task is VFP.
>
>
>>I find this interesting - but I do have one question. Why not just use the VFP functions for .NET that Kamal and Flash put out there over 5 years ago? For folks that want the similarity, doesn't that solve the issue? Why take the time to rewrite them again? I'm sure that you'll have more interesting (read: difficult) issues to solve - so why not take that part as a given.
>>
>>yag