I feel compelled to contribute 2 cents...

I think with the nefarious application object that it is important to consider that it is exactly what it's name implies: an object scoped to the Application, or the session which with the user is interacting. It's generally bad practice (in my opinion) to develop other classes that provide services that depend on the existence of oApp - all of those classes become useless outside of any session that doesn't conform to the behavior of the designed Application object. But it is OK to store session - level variables and make session level methods that deal with environment available, as long as the perspective is outside in. For example, say a SQL pass-through wrapper has a property, nHandle referring to to SQL connection handle, and a method, setHandle, which takes either a handle or a connection string (overload!). Then you could say, for example,

oConn=CREATEOBJECT("SQLWrapper")
oConn.setHandle(1)

If 1 was a valid connection handle.

If you had an object scoped to the level of the session, it would be perfectly valid to have something like the following (in Application Object):

FUNCTION setConnection
nHandle=SQLCONNECT()
this.oConn.setHandle(nHandle)
ENDFUNCTION

FUNCTION oConn_Access
IF VARTYPE(this.oConn)#"O"
this.oConn=CREATEOBJECT("SQLWrapper")
ENDIF
RETURN this.oConn

But the following would be bad:

(In SQL Wrapper Class)

FUNCTION setHandle
this.nHandle=oApp.getConnection()
ENDFUNCTION

(in Application Object)

FUNCTION getConnection
nHandle=SQLCONNECT()
RETURN nHandle
ENDFUNCTION

Which always assumes the existence of oApp, with a method getConnection, even though there's no real dependency on the Application object from the point of view of the SQLWrapper class.

All languages have some construct for the session that violates pure OOP. Java, for example, a highly OOP language, still has main. I don't think there's anything wrong with this inherently as long as you don't just replace your old procedure files with a big Application class - you end up defeating the point of OOP and end up with an Object-based architecure (see VB).

Regarding the array thing: I wrote a class ValueArrayHandler that deals with named value pairs abstractly. Two methods: setarrayvalue and getarrayvalue. You pass array, name, and (if set) value. Then I can use this mechanism anywhere, not just in the Application object.

In VFP6 I have started to replace this with named collections, using Access/Assign, but it still has it's place.

Hope I haven't worn out my welcome in this thread...

>Hiya Rox, Mike ----
>
>On a related note, has any of you ever tried _Assign/_Access on collections (object array properties)? Hmmmm.....Now my wheels are spinning and I was just getting ready to go home as well :-)
>
>
>>Wow Mike. Heh... I was on my way home for the night and now you just got my wheels spinning into overdrive. My first thought is I *think* like this approach, but I would have to consider visibility and debugging a little to make up my mind for sure. For example, if I'm using an oApp property who's value is giving me some grief, I can usually find the offending setter of that value and solve my problem fairly quickly. But now using a Globals Array with Set/Get methods presents me with an extra layer to dig into. No way I'm going find my problem with pausing live code. Not that that's a big deal, just a thought. I think I need to think on this awhile, but I do like it!