Folks,
I want to make this semi-official, not that it really matters what I think or say about it in any truly "official" way, but still I wanted to write a post that says something definitive. FWIW.
Why I wrote https://spacefold.com/lisa/post/2008/02/03/Beyond-TMM-analysis-of-a-bug-and-aftermath-of-architecture-work-What-happens-now
Colin and I were never in any real doubt that the code for the _REPORT* apps should be on CodePlex at http://www.codeplex.com/VFPX.
What we wanted was to hand over the responsibility of moving the apps forward as needed by the community.
In my post, I described an ongoing interaction with Bo Durban of Moxie Data and Martin Haluza (http://www.eqeus.com/)… our feeling, from many previous conversations and an ongoing relationship with these two people was that they were best equipped to take on this responsibility.
As it turns out, Martin is much in the same position as we are, but Bo is willing and able. So…
The immediate answer to what happens now
Bo will be project managing the _REPORT* apps from the VFP code base on CodePlex, and we're very pleased about that.
Although we did not discuss this explicitly, I expect that this responsibility will include ownership for the _REPORTLISTENER.VCX and _FRXCURSOR.VCX libraries from FFC as well; up until now, _REPORTLISTENER.VCX and LISTENER.VCX from REPORTOUTPUT.APP have been exactly the same. Bo can decide to branch them if he likes.
This is the reason why the libraries have two different names, in fact: LISTENER.VCX is the "private" copy for the "official" REPORTOUTPUT.APP in case we found we needed to branch them. There should never be an equivalent need for _FRXCURSOR.VCX.
Colin and I will continue to offer materials related to this effort at http://spacefold.com/articles and, in particular, I will try to flesh out the topics not done in http://spacefold.com/articles/tmm — although a great part of those entries have been planned as pointers into the existing articles, rather than new work. Right now, we really don't have time to do that.
Additionally, Bo knows that he has our support and gratitude and that we will continue making every effort to give him information/coaching/help as we always have in the past.
A more complete answer
Martin has my gratitude and deep respect, as he has many other people's, for the creativity and work he has brought to VFP code extensions in the past, whether he has time to contribute right now or not. Of course I hope that Martin will have some time to contribute enhancements, code changes and/or fixes, in the future.
This isn't the end of the story.
I was a little disheartened by the comments I received in response to my follow-up post on this topic (https://spacefold.com/lisa/post/2008/02/17/I-gotta-ask-again-I-gotta-crow-and-you-gotta-voice-and-a-vote). I am going to quote from my last response to Cesar there, and amplify:
So Carl says "well, people don't like the way you explain it". And you say "well, people need more help". And I have to say "this is the limit of what I have to give you". And there we are.
While I appreciate the "thank you's" from Cesar and Carl… I'm personally not looking for them, you, or anybody else to say "thank you" or to acknowledge my work any more. I'm asking for you to pick up the ball and run with it.
Why would Bo, and/or Martin, and/or anybody else be motivated to go forward in VFPX, whether for reporting extensions or anything else?
Because there is a need and because other people are willing to do hard work, meeting that need, alongside them.
Cesar is probably right that "people need more time", and that's okay. But I think people also have to have a real-life need for the feature. When you have it, you'll be motivated and you'll learn.
By real need I mean something you have to have to produce an application. Not a stupid pet trick for a demo to a user group, or because Microsoft told you some particular capability is cool.
Do you have real needs, folks? And what are you going to do about them?
>> Do you have real needs, folks?
Precisely the question that needs to guide ongoing VFP enhancements from now on.
What are the real issues that VFP developers have to resolve?
They aren’t development issues – (typically at least) – they are BUSINESS issues.
Yes, we may need workarounds for specific crashes, UI style issues, or bug fixes for things introduced in SP2 but let’s focus on what we (or rather our clients) really *NEED* instead of getting wrapped around the latest stuff.
Great post <L> and congrats Bo.
Lisa, Thank you for the kind words. I am honored to help take the project forward. I have posted a more complete response in my blog (http://blog.moxiedata.com). I’m really glad you guys were able to provide these long awaited reporting enhancments to VFP.