Web Connection
Server.oConfig doesn't set up the sub-configuration objects by default
Gravatar is a globally recognized avatar based on your email address. Server.oConfig doesn't set up the sub-configuration objects by default
  Mike McDonald
  All
  Jan 17, 2019 @ 03:42pm

Rick -

I created a new project using the Management Console, and it seems like the generated PRGs doesn't automatically create the MyProjectConfig object, or else I'm just not seeing things properly.

It seems that Server.oConfig is just the base config object created in wwServer::Init() as..

IF VARTYPE(THIS.oConfig) # "O"
	THIS.oConfig = CREATE("wwServerConfig")
	THIS.oConfig.cFileName = THIS.cAppIniFile
ENDIF	

In that case, Server.oConfig doesn't contain the oMyProcess config object, nor the other default config objects like owwMaint.

I put the following in MyProjectMain::OnInit(), after the cAppIniFile property is set in there..

THIS.oConfig = CREATEOBJECT("MyProjectConfig")
THIS.oConfig.cFileName = THIS.cAppIniFile
THIS.ReadConfiguration()

That set up Server.oConfig with the oMyProcess config object, and the others. This also populates the standalone (PUBLIC) Config object, when debugging from a process method. Otherwise the Config memory variable is NULL.

Maybe this should be handled in a different way than I'm suggesting, but without it, the oMyProcess config object doesn't seem to be available.

- Mike McDonald

Gravatar is a globally recognized avatar based on your email address. re: Server.oConfig doesn't set up the sub-configuration objects by default
  Rick Strahl
  Mike McDonald
  Jan 17, 2019 @ 04:46pm

Should be there in <yourApp>Main.prg.

Here's what I get with a new project:

***************************************************************
DEFINE CLASS Testproject3Config AS wwServerConfig
***************************************************************

oTestProcess = .NULL.

*** ADD CONFIG OBJECT TO CLASS ABOVE - DO NOT MOVE THIS LINE ***
owwMaint = .NULL.

FUNCTION Init

THIS.oTestProcess = CREATEOBJECT("TestProcessConfig")

*** ADD CONFIG INIT CODE ABOVE - DO NOT MOVE THIS LINE ***

THIS.owwMaint = CREATEOBJECT("wwMaintConfig")
ENDFUNC

ENDDEFINE
*EOC Testproject3Config


DEFINE CLASS wwMaintConfig as RELATION

cHTMLPagePath = "c:\WebConnectionProjects\TestProject3\Web\"
cDATAPath = ".\"
cVirtualPath = "/TestProject3/"

ENDDEFINE

Gravatar is a globally recognized avatar based on your email address. re: Server.oConfig doesn't set up the sub-configuration objects by default
  Mike McDonald
  Rick Strahl
  Jan 17, 2019 @ 05:19pm

Rick -

Yes, that configuration class code did get set up correctly, but the issue is that (in your example) the Testproject3Config class itself is never instantiated to Server.oConfig.

Server.oConfig is based on wwServerConfig, not Testproject3Config.

- Mike McDonald

Gravatar is a globally recognized avatar based on your email address. re: Server.oConfig doesn't set up the sub-configuration objects by default
  Rick Strahl
  Mike McDonald
  Jan 17, 2019 @ 06:29pm

Hmmm... I see what you're saying.

I vaguely remember making some changes to that logic to automatically pick up the configuration, but I don't see it in the code. It might have gotten rolled back due to some other changes that didn't work out.

What's missing is this:

*** Custom Server Configuration object - created at bottom of this PRG
*** Server and Process Config Settings are read from the INI above
THIS.oConfig = CREATEOBJECT("<%= pcAppName %>Config")
THIS.oConfig.cFileName = THIS.cAppIniFile 

in the pcAppMain.prg template's OnInit(). This is the code that pulls in the configuration defined below in the template.

Fixed for 7.02.

FWIW, I'm rolling out 7.02 shortly (for registered customers) - there are a few bug fixes including all of yours 😃

+++ Rick ---

Gravatar is a globally recognized avatar based on your email address. re: Server.oConfig doesn't set up the sub-configuration objects by default
  Mike McDonald
  Rick Strahl
  Jan 17, 2019 @ 07:27pm

Rick -

Yes, that works, without having to include the THIS.ReadConfiguration(), which I tried first, prior to resetting the .cFileName.

- Mike McDonald

© 1996-2019