Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Trusting VFPA 2

Status
Not open for further replies.

Carlos Yohn - AGP

Programmer
May 19, 2021
7
ES
thread184-1821033

Continuing with the previous conversation: we have been using VFPA 10.0 32 bits for a couple of years. Now we would like to start with the 32-bit one to see if the speed improves.
In general, it works correctly, but there are times when you encounter problems that make you doubt whether they are bugs inherited from VFP9 or our errors or new bugs.
I've talked to Chen a couple of times about the need to know how many users are using this system and to have a forum for sharing problems, ideas, etc. He doesn't seem to like the idea; I don't know the reason; but this makes me doubt the wisdom of continuing with almost no support.
 
One more thought on Chen ending his roadmap or not even publishing a roadmap, I don't know about that.

He has a codebase he could publish so someone else could pick up. I just fear he won't because at that moment Microsoft would be interested and look into copyright infrinngements. There's a reason MS didn't publish the VFP sourccode as was suspected by some poeple who misunderstood MS plans to open source some advances called Sedna which would have gone into VFP10 as open sourcing all of VFP.

Now, 15 years later, none of the VFP sources might reveal something that would make Microsoft file under revealing business critical secrets. But it surely is looking very much as a decompilation of VFP and advances made on that basis. Perhaps Chen also made some parts new from scratch, that are easy enough to do without decompiling the old codebase. Many VFP functions like VAL() or FOPEN() even have there similar working functikons back in C++ and you don't even need one line of new programming for that. But things like the SQL Engine? I doubt you can make up the same functionality just knowing the dialect the engine has to suppport and the file strcutures of DBFs, CDXes and FPT files.

So, what#s my guess when Chen stops? This will also NOT mean open sourcing of VFPA and the end of that road, too.

Chriss
 

Hi,
We extensively tested VFPA32 10.1 across a range of Visual FoxPro (VFP) applications, including some of considerable size featuring over 100 forms, serial communication libraries, external protocols via DLLs, and ODBC connectivity with MySQL and SQLite databases. I can confidently affirm that VFPA32 10.1 performs exceptionally well for our applications, exhibiting no issues whatsoever.

For those who may harbor reservations, I encourage you to give it a try. The experience is far from disappointing. Chen has diligently addressed and resolved numerous known bugs, consistently enhancing the project. This not only speaks to the stability of the 32-bit version but also demonstrates a commitment to ongoing improvements.

In contrast to other ActiveX extensions we've utilized in the past, some of them are no longer maintained. At present, Chen's support on Foxite is commendable, and the 32-bit version of VFPA10.1 has proven to be a reliable choice for our current developments. Ultimaty its your own decision.
Pricing is very reasonable and i think we shoud be happy that we have a tool available do the job
 
Mike & Mike
I would say that a VFPA forum on Tek-Tips is fully out of the question.
About 2 or 3 years ago the FoxPro forum became very very slow, and I recommended the merging of FoxPro and VFP forums into just a Microsoft: FoxPro forum, which was "wish granted", and here we are today.
I don't think I've seen more than 1 or 2 pre-VFP questions in a year on the forum since then.
I see even less questions about "VFPA, VFP 10" "VFP 64bit" or whatever name you want to give it here in that same time. No one objects to those questions in this forum, so this is where it should be corralled.
As a round table member, which I know you both are as well, I would not support it if the question were asked there.
It's long been known as well the FoxPro is the most active forum on this site, has been for decades and continues to be. There's no point in diluting it.


Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS, ATD

"I try to be nice, but sometimes my mouth doesn't cooperate.
 
Scott24x7 said:
I would say that a VFPA forum on Tek-Tips is fully out of the question
I agree. No users (unless they hide themself) no threads... no interest.

Pieter Koemans said:
I can confidently affirm that VFPA32 10.1 performs exceptionally well for our applications, exhibiting no issues whatsoever.
I wouldn't say that of 10.1; i almost would say it of 10.0
VFPA32 10.1 did crash one table with millions of records (not too big in mbs) every time the project use it; with release 10.0 did work fine. Because of we didn't have enough time to build a small sample, we had to return to 10.0
Maybe in the next months we will try again.


TIA
Regards
 
Scott,

I don't disagree with you about the possibility of a VFPA forum here on Tek-Tips. I simply said that it would cost nothing to ask. I expcect Mike Gagnon feels the same way.

Of course, VFPA users are free to post questions here in the FoxPro forum.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Hello and happy new year,

on foxite there is a new area for VFPA.

We got a product with only 64 bit api. So we need to use vfpa to access it.
(Never found a way to use a 64bit dll with VFP and we do not want to "exclude" something into c# programs on this project)

Regards
tom
 
tomk3 said:
on foxite there is a new area for VFPA
Hi, Tom

This VFPA area in Foxite was asked by me.
There are no activity there, except mine.
Seems to there are no many VFPA users. That's what i would love to know.


TIA
Regards
 
Just a side comment on VFP vs. VFPA. VFP version 3.0 (start of Visual FoxPro) was released June 1995 and MS ended with VFP 9.0 in 2006 -- 11 years duration. Chen started his development of VFPA in 2012 and it is now 12 years later and he is still in progress. So, he has 1 year longer in the track record for development...

Greg
 
I agree with Mike,

Greg, you should really look into details of the history published in
Up until today Chen still works on fixing things so they work in VFPA 64bit as they work in the official VFP9. I'm not in the details and since Griff can use it for a project since a longer time I think it's in a relatively stable nd compatible state already for a while, but you shouldn't take 2012 as the reference. What you can see is that Chen already dedidactes time for VFPA for that long. If you look at manhours MS still wins by far, as their team was many more members, and what they added from VFP3 to VFP9 is a lot more than was added into VFPA compared to VFP9, so progress is slower, and that's natural with only a single developer.

So what happens if Chen's talent is recognized by a company making an offer you can't deny and he has to stop VFPA development or reduce it to something he can do in his free time? Or simpler, what about VFPA when Chen dies, if by accident?

I'd solely base a decison for VFPA on the basis of whether I deem it sufficient in its current state also for the next years, so base it on the pessimistic perspective. That's not meant to scare you off. You can see also from my earlier post that I'm satisfied with the advance limitations VFP9 has by only extending it with VFP code. So it's not an unrealistic perspective.

I keep in mind the extensibility with FLLs that enable to use C/c++ libraries, too and that's still an active community. There's not much going on in that domain at all, VFP features are mostly enabled by projects mostly based on VFP code. That extensibility is also still available for VFPA, I think, though it depends on an object code file Winapims.lib that Chen either also has upgraded to 64bit already or not.

But notice I'm not only using VFP9. I already had several languages in my repertoire before even starting VFP development.

So, I think all in all you would need to take the optimisitc point of view that regards the active VFP9 community as integral part of the VFPA community for its good compatibility, you'll only ever get stuck on issues that only apply to VFPA and less people willling to look into those issues. They might still be able to find a workaround.

Chriss
 
I don't really know about Chris's analysis of the pitfalls, but for myself - I'm happy to use it for a given project in house where
there are performance advantages and I don't have to implement a whole suite of integration things (image processing or other
features where I might be using a 32bit tool).

If a customer came and wanted to migrate an existing app to VFPA 64bit, I would discourage that...

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you.

There is no place like G28 X0 Y0 Z0
 
Okay Griff,

thanks for clarifying that and sorry for making assumptions based on your enthusiasm for VFPA.

Chriss
 
My point in the comparison of time was not to show any future longevity of Chen. It was only to show how long he has been at it. Any product's future longevity is always a question that cannot be answered by anyone outside of the owning company. Chen's current continuation is probably mostly due to his own desire as I suspect there are not a sufficient number of paying developers for his work. As I understood, from Microsoft's perspective, VFP did not have the revenue stream that justified its continuation as a product. There was not a large number of VFP developers buying each release since VFP6; hence, no revenue, no work - end of product.

Greg
 
Greg,

I think that it wasn't so much a question of not enough developers buying each release. It was more that the product only earned one sale per developer rather than one per end user. This is in contrast to the likes of SQL Server (or perhaps Access) where the more people using a given applicaiton, the more revenue for Microsoft.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
Mike,

I'd say VFP10 development wouldn't have started, if it wasn't funded already. It's rather VFP8 that funded VFP10, but that's not even the major point. MS won't ever be completely transparent with the reasoning of product continuation or discontinuation. Arguing with the business success is obvously plausible, as that's a need for any product, unless it's a prestige or a pet project, which VFP surely wasn't.

For Chen this most likely is a pet project with own interest in it. So he'd do it anyway, no matter if there are any sales or not.

Regarding Access, notice you can also run (an ddistribute) Access applications with a royalty free redistributable Access runtime:

Chriss
 
MS Killed VFP because it was in direct competition with Access. Microsoft bought VFP to take Rushmore Optimization from VGP and add it to MS SQL Server. Once they were done with that it justified them discarding VFP. It was always a strategic acquisition to begin with. It had the unfortunate issue of being a step-child of a solution Microsoft already had.

If certainly wasn't an issue of popularity among developers, as is evidenced by this forum that such a site as Tek-Tips more than 20 years on now, remains the most visited forum of all their other forums. And yes, now some 15+ years since "the end" of VFP it is starting to dwindle, but every day there are still multiple new posts to this site.

MS is notorious through its history for buying competing products for sole purpose of killing them off. VFP was even easier, because it also had something they wanted.
That's the reason they killed it.

Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS, ATD

"I try to be nice, but sometimes my mouth doesn't cooperate.
 
If Microsoft had bought VFP solely for the Rushmore engine, I doubt we would have had 6 versions (plus Service Packs) from them. That said, absolutely Rushmore was a big factor in the sale. But I also believe (from things that were said at the time) that Microsoft wanted to bring along the FoxPro community. They've tried to recreate that over and over.

As for ending VFP development, I think it was several factors. First, VFP didn't fit into their vision for the future of software development as they moved to the web. Second, it was absolutely about sales; they said that to us pretty regularly. Third, I remember conversations with 'Softies asking us in the community what the big back-of-the-box features would be in a VFP 10, and the answers they got were either things that weren't big enough for back-of-the-box, or that were enormous like breaking the 2GB limit.

And, of course, I think a key factor in VFP's downhill slope was that awful report from Gartner.

Tamar
 
Tamar said:
If Microsoft had bought VFP solely for the Rushmore engine, I doubt we would have had 6 versions (plus Service Packs) from them.

Exactly, Scott, what you state is almost the first joke that was made when MS announced end of life of VFP 2008: "HA, I knew they only baught it to kill the best competitor of Access."

Tamar,
Do you mean the Gartner report that was made 1996? As Joel Leach mentions it in
Joel Leach said:
I was there, in a meeting with 40 people, and the formal announcement was made to the Fox team that VFP was dead. It was very early 1996, and that meeting lead to the Gartner Group releasing their report that VFP was dead, which had a major impact on future VFP sales.

Joel cites Ken Levy here, who said
Ken Levy said:
But the Fox team members along with the community helped convince the developer tools management to keep VFP evolving while decreasing the resources.

In tht sense the Gartner report was reducing the VFP team and thus slowing down progresss of it. To me it's now the chicken or egg question whether that lead to less sales of VFP with less progress or less progress because of les sales.

And the next Ken Levy sentence reflects something I also already said: Any application running on Windows supports MS platform, mainly:
Ken Levy said:
In fact, the primary reason VFP lasted another decade with 4 more versions released was more about Windows sales than VFP sales. There are many Windows machines running VFP apps. When Steve Ballmer jumps around like monkey boy and yells “developers, developers, developers”, he’s thinking about selling Windows and Office more than sales of developer tools.

And later on Joel says wht I thought is another major reason of the end of VFP development:

Joel Leach said:
the Fox Team was disbanded and assigned to other projects

Well, it's again the chicken or egg question again whether assigning the team members to other projects was just a logical consequence of discontinuing VFP or whether it was actually the main driver to need the team members in these other projects to end the VFP development.

Regarding the reason of sales:
Tamar said:
it was absolutely about sales; they said that to us pretty regularly.
That just fits into the plausibility reasoning, of course they pointed this out and likely even since VFP5 already. But I'm still not convinced it finally became the major reason with VFP 10. I can imagine VFP sales dropped since VFP5 and that became more visible when VFP7 became a separate product from the Visual Studio. But then I bet VFP8 and VFP9 already were made despite too little VFP7 sales.

Chriss
 
Well... AI is here now. I suspect I (and most others) won't need to continue developing much longer, at least not in the sense we have in the past. Solution architecting and business analysis will feed AI development systems, and we'll get our systems independent of developer tools, as the AI will pick the right tool for the job.
I'm personally looking forward to that stage. It will bring about solutions to small business at a pace unachievable currently. It's already accelerating our development.



Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS, ATD

"I try to be nice, but sometimes my mouth doesn't cooperate.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top