We use one global variable, ThisApp, for our application object. Just because there is a app class, doesn't mean that it does all the work. Just like a form there are lots of classes that contribute to the behaviors.
GetProperty(PropertyName, oRequester) returns various values, but the objects that do the work may vary. We may have a Properties collection or otherwise.
GetConnection(ObjectThatNeedsAConnection) sets the connection based on a Connections collection, but it might be otherwise.
WriteToErrorLog(oError) Pass in an Error object. If it can't be written to the central place, write it locally.
DataSourceType - Property tells us if we are Native or ODBC.
We have quite a lot of methods and properties, but again, it doesn't mean some giant object whose behavior if fixed.
I just added EnableEmail = .F.
Now other objects can know if this project should do send for activities that normally trigger an email.



>Sorry, but no way... that's too broad of an application of this principal.
>
>You can't tell me that goApp.oCurrentUser is not a reasonable thing to have in an app while still maintaining good code structure and design principals.
>
>And so forth...
>
>As a minimum the various features, properties, and general functionality that I was seeking suggestions about could live in separate objects as appropriate and then references to the individual objects could be hosted on goApp.
>
>For instance, goApp,oConfig
>
>
>
>
>
>>Seems to me it violates Single Responsibility Principle https://en.wikipedia.org/wiki/Single_responsibility_principle
>>
>>>I'm wanting to get some ideas of properties, methods, features, etc. that would go into making a generic, reusable Application Object. One that would be a good basic App Object that could be used universally in creating common business apps in FoxPro. Ideally, this global App object would have basic properties, and methods that we'd all likely find useful if we were using it in one of our apps.
>>>
>>>I assume almost everyone has such an object in their apps, or at least a bunch of hodge-podge functions that simulate such a thing.
>>>
>>>So, please share you comments and ideas with me...
>>>
>>>For instance, here is what I've started out with as I began to abstract my specific goApp class to a generic one:
>>>
>>>

>>>Define Class AppObjectBase As Custom
>>>
>>>	lExe = .f.
>>>	lDevMode = .f.
>>>	cAppName = ""
>>>	cCurrentModule = ""
>>>	cActiveForm = ""
>>>	cCurrentVersion = ""
>>>	cTempFilesPath = "C:\Temp\"
>>>	
>>>	oConfig = .null.
>>>	oUser   = .null.
>>>	oSql = .null.
>>>	oTracker = .null.
>>>	oBO = .null.
>>>
>>>	*---------------------------------------------------------------------------------------
>>>	Procedure Init
>>>
>>>		*-- In your override of this method, you'd wire up all the objects and properties
>>>		*-- that are hosted in this class. 
>>>		
>>>		*-- Example setup work displayed below. Every app is different, so do whatever you need to 
>>>		*-- get this global goApp ready for use by your application
>>>		*---------------------------------------------------------------------------------------
>>>		
>>>		* This.oConfig = NewObject("LmConfig", "LmConfig.prg")
>>>		* This.oValues = NewObject("Values", "Values.prg")
>>>		
>>>		* lcRunningFilename = JustFname(_vfp.ServerName)
>>>		* This.cCurrentVersion = lcRunningFilename
>>>		
>>>		* If This.lDevMode and This.lUseTestData
>>>		*	This.oConfig.Connstring = Strtran(This.oConfig.Connstring, "LMDB", "LMDB_TEST",1,99,1)
>>>		* Endif
>>>		
>>>	EndProc
>>>	
>>>	*---------------------------------------------------------------------------------------
>>>	Procedure LogError(tcErrorMessage)
>>>	
>>>		*-- Again, in your override, handle any calls to LogError() however you neede to.
>>>		*-- If you assign This.oBO in the Init() method, then you can use the wwBusinessPro.LogError() method
>>>		*-- as shown below. If not, then override and do whatever magic you need or want to do to handle these calls.
>>>		
>>>		This.oBO.LogError(tcErrorMessage)
>>>	
>>>	Endproc
>>>
>>>	*---------------------------------------------------------------------------------------
>>>	Procedure lExe_Access
>>>		
>>>		Local lcApp, llExe
>>>
>>>		lcApp = Sys(16,1)
>>>		llExe = '.EXE' $ Upper(lcApp)
>>>		
>>>		Return llExe
>>>	
>>>	Endproc
>>>	
>>>	*---------------------------------------------------------------------------------------
>>>	Procedure lDevMode_Access
>>>	
>>>		Return !This.lExe		
>>>	
>>>	Endproc
>>>
>>>
>>>	*---------------------------------------------------------------------------------------
>>>	*- This handy method gives you a simple and common way to setup Classlibs and Procedure files
>>>	*-- into your app setup calls.
>>>	Procedure Require(tcAsset)
>>>	
>>>		DO CASE
>>>			CASE ".vcx" $ Lower(tcAsset)	
>>>				Set Classlib To (tcAsset) Additive
>>>				
>>>			Case ".fll" $ Lower(tcAsset)
>>>				Set Library To (tcAsset) Additive
>>>			*-- Assumes .prg or no extension
>>>			Otherwise 
>>>				Set Procedure To (tcAsset) Additive
>>>		ENDCASE
>>>
>>>	EndProc
>>>		
>>>	
>>>EndDefine
>>>
>>>