Forum,

I've been programming in Eiffel since 1994, and I'm just now coming back to FoxPro (I purchased VFP 9.0 SP1). I used FoxPro up to 1994, having started with FoxBase (on the Mac). While there are many, many improvements in VFP, I'm having trouble reconciling formal OOP concepts to the implementation of OOP in VFP.

It would seem that there has been a divergence between the concept of object "properties" and class "fields". I'm having trouble reconciling the two. Specifically (my description of the problem might be Eiffel-like, so I apologize):

I have created a class called NEWSPAPER_SECTION, a visual class that will wind up functioning very much like a Microsoft Money-like expander control. The class contains a title_bar_region, column_header_bar_region, content_region, and footer_region, all of which I'm led to believe should be CONTAINER classes. The latter three regions are actually contained in another region called minimizable_region, also of type CONTAINER. The creational (Init) for this class takes a single argument called ui_context, which must, by assertion, conform to type CONTAINER.

I would like to expose the various regions to descendants, but not necessarily all of the "properties" of the CONTAINER base class. Here's the code snippet that should explain:

define class NEWSPAPER_SECTION as CUSTOM

hidden ui_context
ui_context = .null.

protected title_bar_region
title_bar_region = .null.

procedure init
lparameters p_ui_context

this.ui_context = p_ui_context
this.ui_context.addobject('title_bar_region', 'CONTAINER')

endproc

enddefine &&NEWSPAPER_SECTION

This is where I have a problem. I'm trying to connect a reference to the visual element to a protected member (in this case, the title_bar_region CONTAINER to the title_bar_region field), but VFP says I can't do this because a member already exists with that name. Also, I don't necessarily want all the baggage of the CONTAINER base class that comes with VFP. How are you guys handling this situation? In general, how do reconcile properties to fields? Are you simply allowing the properties of a particular visual element to be exposed (so that the consumer could change the font of a label when you don't necessarily want him to be able to)?

It seems to me that fields should be reserved for elements of a class that do not come _directly_ from a visual element, and that properties should just stand as they are.

Thank you.

Eric