Hi Samuel
>
>So this is a nice effort to work, I hope you'll also lend us a hand programing VFP in VFP. You'll be surprised the easy is this if you can build on top of the .NET Framework.

Mark me down on alines() as the first attempt if it is still free - this is one of the things I am using almost every day for some input/parsing routines from big-iron files and I often make use of the nflag parameter. As this routine is only implemented partially in the vfp-Toolkit it needs to be redone for my needs - and at least in the table on your site it is not marked down as finished <g>.

From reading Kemal's code my first assumption is that this should build on his solution with .split as this is probably quite fast. (I have been thinking on this during my drive to work )

regards

thomas

P.S. sorry for naming you David - must have been tired...


>
>Thanks,
>
>Samuel David
>
>
>>Hi David,
>>>
>>>Could you believe that what we get asked more is about the GUI part. I really thought this could be the last item to implement in our road, but now I guess We'll have to change our plans...
>>
>>The only context where this would make sense to me is that the person asking about that is concerned that you'll also go the last mile. As perhaps the most distinguishing factor of the vfp GUI is the tight coupling to datasources, manipulating those datasources via vfp language must be done before a GUI can be considered...
>>
>>>BTW, did you read our secret plans? some of the other things you mention, are already implemented or being actively worked.
>>
>>Naawh, I never read those - I sometimes visit that nice girl from third floor after they removed my permit for clairvoyance. Seriously, to me most of that is "just logical" if I visualize myself in your situation. At start I also had some doubts on you guys appearing out of nowhere with no track record and a very ambitous plan. But
>>
>>

you are not promising a pie in the sky
>>

you are open about the technical problem you encounter
>>

you are listening to some of the hints here - I saw the list of things implemented before you posted<g>
>>

you show the level reached with your compiler
>>

and your answers mostly fit my mental map / take on things
>>
>>so I am quite willing to try out the first release making business sense for me. Before you entered the scene I had eyed IronPython as my next step. Now I am hoping for you to finish your first release. Open sourcing or releasing the code to customers might help settle much of the current fear in others, but the main thing is shipping a working product helpful for your customers.
>>
>>Quickly getting more developers from the vfp pool might help - and in my best case scenrios you will still make a profit on your compiler. My personal belief on the value you will be providing is not [only] in prefinancing development, but mainly in establishing a rigorous test system for the compiler. vfp is/was a very stable and compatible environment, and the developers are used to that level. Testing effort will rise exponentially with more of vfp implemented, and for you to try to get to the level of the latest and greatest vfp in one step might overtax ETec capabilities.
>>
>>On the pro side you can reuse existing "plumbing" and already have a target to test against (only very few desgin meetings needed), but during the years the gifted vfp team has implemented quite a lot of features. As shipping definitely would be a feature, you might consider to give permanent discounts to developers writing some of the functions complete with a unit test for it - if you already have a scale for the difficulty of each functions implementation (Occurs() should get a smaller bonus than a complete SQL Select <bg>) and a "locking" schema to make sure each function is only being worked on by a single developer and each developer can only lock one task at a time. Such a move might lift some of the necessary grunt work without too much of a pre-financing problem. Something in-between an unpaid open source effort and a profit oriented endeavour.
>>
>>Also let me reiterate: releasing different parts at different times could make *business* sense to me to become a customer as early as the language and backend capabilities are solid at a non-GUI level similar to FPW/FPD capabilities - but make each implemented part compatible with todays level. But the discussions in the last days markedly showed quite a large spectrum of opinions amongst us fox developers<bg>, so perhaps not too many agree with me on this topic perhaps others can chime in and give you their opinion.
>>
>>Again, I think you should charge your customers for the effort of testing, fixing and so on so that the high level vfp has reached can be maintained for future releases (plural!) while acknowledging the effort some people went to to help you come to market early by charging them markedly less - as there are "only" about 400 steps missing the number of people actually delivering parts will not cut too greatly into your potential revenue.
>>
>>Much more difficult will be to determine when an implementation of the dreaded foundation read or DDE can be cosidered error free, if you plan to implement them at all.
>>
>>But coming to market sooner than later probably means a higher potential customer base - before too many are comfortable with different/new tools: especially as those willing to switch now/only recently are probably the people easiest to compel to try your compiler!
>>
>>my 0.02 EUR
>>
>>thomas