What about VPME9.1X
We've gotten a couple of questions about VPME9.1X lately: are we going to produce a version of xCase2VPM to go with this version of VPM? In short, the answer is no. The longer answer follows <s>.The reasons for our decision are many, some more important than others of course. Here are some, in no particular order of importance.
- With VFP now in an end-of-life cycle, we don't foresee a move by developers to VFP; and since developers moving to VFP were a key component of the VPM market (because VPM is such a huge help in getting going with VFP when doing useful work), we don't foresee an increased market for VPM.
- Our libraries provide the capabilities we need to produce great business applications in VPME9.
- It would be a lot of scut-work changing everything in our libraries to work with VPME9.1x. Nothing has changed in the essence of the processing; but what things are called or where they are located has changed.
We would love to have a reason to change our decision. One thing that would help do that would be if VFP applications could be compiled into .Net. "What," you say? "We've been told VFP can never run within .Net, and the person telling us that was the Product Manager for VFP!" Well, we'll see how it turns out, but you might want to take a look at a Community Support Group for etecnologia.net's VFP.Net compiler. If/when Samuel et al. get this thing working, then VPME9.1X will have another life (well deserved), and it would make sense for us to proceed with a version of xCase2VPM that implements the interface we have already planned for xCase2
For the moment, we're producing great business applications in VPME9, using our libraries combined with xCase2VPM, and haven't found any reason to do otherwise. We see reasons to be preparing for the future, of course. Right now, what we have is working great.
