>So write it. :-) The FRX format isn't so obscure you can't translate the above -- hey, if Koziol can do it...

Give me collections, and maybe I will. :-)

Seriously, the inability to create collections in custom VFP objects makes doing stuff like this kinda painful. I know from experience.

I have laying in my toolbox a 95% completed set of "VFP Distributed Management Objects" (VFPDMO) that give an object wrapper to VFP's databases, views, tables, fields, relations, connections, etc:

oDatabase= CREATEOBJECT("VFPDMO.Database")
oDAtabase.Connect("c:\data\mydatabase")
FOR EACH oView IN oDatabase.Views
oView.Redefine()
ENDFOR

or

oField = CREATEOBJECT("VFPDMO.TableField")
oField.Name = "LName"
oField.DataType = "C"
oField.Width = 10
oDatabase.tables("Customer").AddField(oField)

The reason that it's not 100% completed lies in the fact that the "collections" that I have kludged up using _Access methods and THIS_Access have quirks that I don't know how to get around. I would hit the same brick wall with object reports.

Similar tricks have been done with VFP menus.

The point is, we have OO capability for forms, controls, and even the project manager, it's silly not to have it in our menus and reports. Sure, half-assed facsimiles can be custom built, but that's no excuse for the VFP team not to complete the job.

When I was new to VFP, the menu and report syntax was the most difficult for me to grasp, and was the biggest turnoff. I have gotten used to them now- but I suspect that other newbies find these dinosaurs as wierd and difficult to use as I did.