>Hi
>
>I'm an old (DOS) foxpro programmer. Old in years as well. I have been trying to come to grips w/VFP recently and have run into a problem. I have created a form with a two tab pageframe. Page one contains parent records. Page two the child recs. Two free tables are open in the data environment. The relationship is created by setting a filter to a key field in the parent in the active method of page two.
>
>Tried using the component gallery: When I used the "simple navigation buttons" _nav2buttons1 they worked fine on both pages. I thought this was gonna be a snap. When I tried to use the more elaborate "data edit buttons" the form froze.
>
>I'm just feeling my way at this point and not locked into anything I've described above. I've toyed with the 1 to many builder and I think I need to be closer to what's under the hood in order build my ultimate app.
>
>Any advice/direction greatly appreciated.

You don't see the component gallery discussed much. I think it's because it's pretty limited in what it can do, my understanding is it was really designed as working samples rather than production-ready code.

If you have just one or two quick-and-dirty forms you need to wire up, then spending some time with the component gallery might be OK. But if you have a large project in mind and with this thread you're basically "dipping your toes in the water" it's probably not a great choice.

If you need to migrate an existing FoxPro/DOS system to something else, there are lots of choices - almost too many.

VFP is an obvious choice, but you have two main options, neither ideal:

- Run your DOS app as-is in VFP in "compatibility" mode. This works and requires minimal code changes, but forms and controls look poor, don't behave 100% as expected and there are quirks with menus, hotkeys etc.

- Do a complete rewrite in native VFP. This creates an app that looks and works like a true Windows app (albeit circa 2005)

Going to native VFP from FPDOS is almost like learning a completely new language. A lot of the Fox stuff you may already know will be a hindrance. For example, SET RELATION/SET KEY etc. are rarely used, the SQL commands are used instead. If you don't know SQL you will have to learn it, and learn to work with set based logic rather than FP ISAM processing. This is partly because best practice these days is to store data in an RDBMS backend such as SQL Server or MySQL rather than to use native VFP "databases"/tables.

If you end up doing a complete rewrite, and effectively needing to learn a new language/environment, this begs the question - should you stick with VFP or use something else? VFP is past end-of-life and existing code is getting harder to maintain as fewer people are using it. By default you're limited to desktop applications, which can be a significant in a mobile/web world. Although there are add-on services available such as West Wind Web Connect and FoxInCloud which can "webify" a desktop app.

Alternates to VFP have been extensively discussed here. Some are:

- .Net
- Lianja
- Java (especially for Android)
- JavaScript (various frameworks)
- Python
- Ruby on Rails
- WinDev

However, if after all is said you want to stick with VFP, there are several commercial frameworks which can help a lot as long as you're willing to learn VFP, then learn how the framework works with and enhances VFP.