Hi,

I have a public object, DefaultsObject, which is created during startup and holds stuff that can change for different users.
This is listed in sficServer.cPublicVariablesObjectSave.
The wcPropSave property of DefaultsObject is set to all of its' property names during its Init().

After login I perform these steps :

1. thisForm.wUserLogIn(EnteredUserID)
2. populate the properties of DefaultsObject with values related to the user, including a property named UserObject which contains an object holding more information

• everything is fine and set properly when the login sequence ends.

sficServer.wuserGet() contains :
Return Iif(Type("DefaultsObject.UserObject") = "O", DefaultsObject.UserObject.ID, this.wUserAnonymous)

sficserver.wuserSet() simply contains the default RETURN DoDefault(m.twUser, m.tlTemp)

• I don't really see a need to do anything in this method in my case if the user details are held in a public variable which should be restored prior to each request anyway. Am I right?

When I navigate to a new form I find that none of the properties are populated on DefaultsObject and things don't work 😦

What am I doing wrong?

Thanks
Paul

Hi Paul,

1. is defaultsObject created in xxxSets.Init()?
2. what do you have in sficServer.cPublicVariablesObjectSave? sficServer.cPublicVariablesObjectSave = 'defaultsObject …'?
3. can you see a record for defaultsObject in Temp\__sfic_appenv.dbf?
4. you don't need any code in .wUserSet() and .wUserGet(): FoxInCloud holds the user ID internally

1. yes, it is created via a call to another procedure from within xxxsets.init()
2. cPublicVariablesObjectSave = 'DefaultsObject'
3. yes, there is a record, it lists the names of then properties that I specified in wcPropSave

When I examine DefaultsObject after another form is called I see that some of its properties are populated and some are not!!!
For example, there is an array property that contains the correct values but the UserObject property (which should be an object) is null.

Paul

To let us test, could you send your class definition to support at foxincloud dot com?

do you store a reference to DefaultsObject in a form property?

then there would be a conflict: public variable restored first, then overwritten by form's property initial value (sequence of FoxinCloud server operations is shown here: http://foxincloud.com/tutotest/bs/foxincloud-status.tuto?tab=forms).

if so, just add the form property name to .wcPropSaveNot:

procedure yourFormClass.load
…
wcPropSaveNotEdit(thisForm, 'DefaultsObject') && modify command awPublic.prg
…
```
`

No, it is only a public variable.
The mysterious thing I have found is that all of the properties are returned to their default values, except one property which is an array!

We might have an issue with array properties: should restore to class value.

Otherwise you need to explicitly declare the user-dependent properties (to be saved and restored for user) in .wcPropSave

update: this feature requires some improvements; I'll tell you more in a couple of days; in between please test whether using .wcPropSave improves the result.

After much trial and error I think I have found the problem : I am setting wcPropSave to a string which is too long for FiC to handle.

I am now setting wcPropSave at design-time in the code (instead of programmatically at runtime like I had before).

wcpropsave = ;
		"ALLOCSHIPSCHEDULESETTINGS,AREALEVELSUSED,AREATITLE,AUTOBOMHEADERREVISION,AUTOPROJECTREVISION,AUTOQUOTATIONREVISION,AUTOREFRESHOWF,AUTORENAMEBOMID,AUTOSALESORDERREVISION," + ;
		"AVEAFTERMRPRUN,BOMQUANTITYPERDP,BOMTREEVIEWORDER,BRANCHTITLE,BUILDCOSTSSTOCKINGLEVELCOSTSNAPSHOTS,BUILDCOSTSSTOCKINGLEVELITEMS,BUILDCOSTSSTOCKINGLEVELOTHERACTIVITIES," + ;
		"BUILDCOSTSSTOCKINGLEVELSO,CACHEPASSWORD,CACHESERVER,CACHEUSERID,COLOURS,COLUMNHEADERBACKCOLOUR,CONFIGFILE,CONFIGURATORMENUBARFIELD,CONSTRUCTERDEFAULTSUPPLYPAGE," + ;
		"CONSTRUCTERENABLEEDITOTHERITEMBOMS,COSTDESCRIPTIONBUDGET,COSTTYPEBUY,COSTTYPEMAKE,DEFAULTAREAID,DEFAULTBINAISLE,DEFAULTBINBAY,DEFAULTBINBIN,DEFAULTBINDELIMITER," + ;
		"DEFAULTBINDIMENSION,DEFAULTBRANCHID,DEFAULTDRAWINGFOLDER,DEFAULTENTITYID,DEFAULTLOCATIONID,DEFAULTSTOWSDETAILONCONSTRUCTER,DETAILEDVALUEDP,DISPLAYSTYLE," + ;
		"DRILLSUPPLYLISTTOSTOCKLEVEL,ENFORCESTOCKSTATUS,ENTITYTITLE,EXTAVERAGECOSTISROLLEDUP,EXTENSIONSDIRECTORY,EXTERNALBUTTONLOGO,EXTERNALDATABASE,EXTERNALDATABASE2," + ;
		"EXTERNALDATABASE3,EXTERNALDATABASE4,EXTERNALKEY,EXTERNALKEY2,EXTERNALKEY3,EXTERNALKEY4,EXTERNALLOGO,EXTERNALPASSWORD,EXTERNALPASSWORD2,EXTERNALPASSWORD3," + ;
		"EXTERNALPASSWORD4,EXTERNALSERVER,EXTERNALSERVER2,EXTERNALSERVER3,EXTERNALSERVER4,EXTERNALSYSTEMID,EXTERNALSYSTEMID2,EXTERNALSYSTEMID3,EXTERNALSYSTEMID4," + ;
		"EXTERNALUSERID,EXTERNALUSERID2,EXTERNALUSERID3,EXTERNALUSERID4,EXTERNALVIEWSUFFIX,EXTERNALVIEWSUSEEXTERNALDATA,FOLDERPERACCOUNT,FORECASTFILE,FORECASTMONTHCOLUMN," + ;
		"FORECASTNUMBEROFMONTHS,FORECASTPRICECOLUMN,FORECASTWORKSHEET,IMPORTPRICEFROMSPREADSHEET,INDUSTRYTYPEOBJECT,INVOICEEXPORTSUMMARY,INVOICEPREVIEW,INVOICEPRINT," + ;
		"INVOICEPRINTSUMMARY,INVOICINGTAXFROMROUNDEDLINES,ITEMVERSIONBUYITEMS,ITEMVERSIONCHANGEMAJORONANCESTORS,ITEMVERSIONFREEFORMTEXT,ITEMVERSIONMAKEITEMS," + ;
		"ITEMVERSIONSEGMENTLENGTH,ITEMVERSIONSNAPSHOTONMAJORCHANGE,LASTLOGGEDINUSERNAME,LASTUSEDTIMEENTRYEMPLOYEE,LASTUSEDTIMEENTRYMODE,LICENSEID,LICENSEOBJECT," + ;
		"LOCATIONLEVELSUSED,LOCATIONTITLE,LOOKUPEXT_CUSTOMER_LOOKUPORDER,LOOKUPMFGBOMHEADERLOOKUPORDER,LOOKUPMFGOPERATIONORDER,LOOKUPMFGQUOTEHEADERORDER," + ;
		"LOOKUPMFGWORKORDERHEADERORDER,LOOKUP_REMEMBERPREVIOUSCODE,LOOKUP_WO_BOM_AUTOSHOWAGAIN,MAINTENANCEMFGBOMHEADERLOOKUPORDER,MAINTENANCEMFGOPERATIONORDER," + ;
		"MAINTENANCEMFGQUOTEHEADERORDER,MAINTENANCEMFGWORKORDERHEADERORDER,MARKUP2COMPOUNDS,MASTERDATABASE,MASTERPASSWORD,MASTERSERVER,MASTERSYSTEMATTRIBUTES," + ;
		"MASTERSYSTEMID,MASTERUSERID,MAXIMISECONSTRUCTERWINDOW,MAXIMISEONSTARTUP,MAXIMISEQUOTATIONWINDOW,MAXIMISEWORKORDERWINDOW,MFGDATABASE,MFGPASSWORD,MFGSERVER," + ;
		"MFGUSERID,MODULESDIRECTORY,MPSACTIVITYDATETYPE,MPSLOCATIONID,MPSNUMBEROFBUCKETS,MPSRESOURCEFILTER,MPSTIMEINTERVAL,MRPBUCKETINTERVAL,MRPNUMBEROFBUCKETS," + ;
		"MRPSDGRIDLINKEDTOOVERVIEW,MRPSOFROMSTATUS,MULTIPLEUM,NET4TURL,NOCHANGESYSTEM,ONCOSTALLOCATIONMETHOD,OPERATIONTIMEMEASUREMENT,OWFWOSHOWISKITTED," + ;
		"PICKAREASTOCKBEFOREPRIORITY,PICKERSCHEDULESETTINGS,PICKFROMALLAREAS,PICKFROMALLLOCATIONS,PICKINGMETHOD,PICKLISTUSESOID,PICKONLYCOMPONENTSWITHONLYPICKTHIS," + ;
		"PRICESCHEMECONSOLIDATEDSOOTHERID1FIELD,PRICESCHEMECUSTOMEROTHERID1FIELD,PRICESCHEMESUPPLIEROTHERID1FIELD,PROGRAMHIVE,PURCHASEKITRECOMMENDATIONMODE,QUANTITYDP," + ;
		"QUANTITYPERDP,QUANTITYPERLENGTH,QUANTITYPICKKITDP,QUOTEDOCUMENTPATH,REPORTOPTIONSMFGBOMHEADERLOOKUPORDER,REPORTOPTIONSMFGOPERATIONORDER," + ;
		"REPORTOPTIONSMFGQUOTEHEADERORDER,REPORTOPTIONSMFGWORKORDERHEADERORDER,REPORTSDIRECTORY,RIBBONUI,SALESHISTORYFILE,SALESHISTORYMONTHCOLUMN," + ;
		"SALESHISTORYNUMBEROFMONTHS,SALESHISTORYWORKSHEET,SALESORDERDOCUMENTPATH,SALESUNITNOTSTOCKUNIT,SAVEPNASQUOTE,SCHEDULEDTASKSFREQUENCY,SCHEDULERAUTORUNSCHEDULE," + ;
		"SCHEDULERBACKWARDSCHEDULE,SCHEDULERCAPACITYACCURACY,SCHEDULERCONSIDERAVAILABLEDATE,SCHEDULERINCLUDEIN,SCHEDULERINCLUDEPJ,SCHEDULERINCLUDEPR,SCHEDULERINCLUDESO," + ;
		"SCHEDULERINCLUDEWO,SCHEDULERINFROMSTATUS,SCHEDULERINSTANCES,SCHEDULERINTOSTATUS,SCHEDULERLOWPRIORITYTREATMENT,SCHEDULERMAXIMISETHROUGHPUT," + ;
		"SCHEDULERMINRESOURCEHEIGHT,SCHEDULERONLYIMMEDIATEOPERATIONS,SCHEDULERPJFROMSTATUS,SCHEDULERPJTOSTATUS,SCHEDULERPRFROMSTATUS,SCHEDULERPRTOSTATUS," + ;
		"SCHEDULERRESEQUENCEWHENDRAG,SCHEDULERSOFROMSTATUS,SCHEDULERSOTOSTATUS,SCHEDULERUNSCHEDULEDTREATMENT,SCHEDULERUPDATESUPPLYDUEDATE,SCHEDULERWOFROMSTATUS," + ;
		"SCHEDULERWOTOSTATUS,SCHEDULERZOOMLEVEL,SHIPIDUSESOID,SHIPMENTMANAGEMENT,SHOPFLOORUI,SHOPFLOORUISETTINGSOBJECT,SHOWITEMROUTINGORDER,SHOWLINEDESCINSOGRID," + ;
		"SHOWMENU,SHOWRECIPROCALSECUOMWEIGHT,SHOWSOINWOGRID,SOHARDALLOCATIONSONENTRY,SOKITSOLINES,SOKITTOTOPLEVEL,SOMUSTUSESHIP,SOPICKSOLINES,SOPRINTDISPATCHDOCKET," + ;
		"SOPRINTINVOICECUSTCOMMERCIAL,SOPRINTINVOICECUSTOMER,SOPRINTINVOICEOFFICE,SOPRINTPICKINGSCHEDULE,SOPRINTSALESORDER,SOPRINTSHIPPINGLABEL,SQLUPDATEPATH," + ;
		"STATUSFLAGARRAY,STMUSTUSESHIP,STOCKALLOCATIONS,STOCKLABELSERIALTRACKINGLEVEL,STOCKLABELUSENEXTSERIAL,STOCKMOVEMENTBARCODELENGTH,STOCKMOVEMENTBARCODESCANMODE," + ;
		"STOCKONLYFROMMYLOCATION,SUMMARISEDQUANTITYDP,SUMMARISEDVALUEDP,SUPPLYDEMANDINCLUDECOMPONENTS,SYNCHBATCHSIZE,SYNCHFREQUENCY,SYNCHSYSTEMS,SYNCWITHEXTERNALSTOCK," + ;
		"SYSTEMATTRIBUTES,TASKLEVEL,TEMPLATEDIRECTORY,TESTINGMODE,TIMERECORDINGAUTOACTIVITYTYPES,TIMERECORDINGSHOWMINUTES,TRACKINGUNIT1TITLE,TRACKINGUNIT2TITLE," + ;
		"TRACKINGUNIT3LIFETIME,TRACKINGUNIT3TITLE,TRACKINGUNIT4TITLE,TRACKINGUNITSUSED,UPLOADTXTFILELOCATION,USE4OPSPO,USE4OPSSTOCK,USEREMOTEDATASOURCE,USERGROUPOBJECT," + ;
		"USEROBJECT,WEIGHTDP,WOCHECKSTOCKREPORTS,WOCOMPONENTCOSTFROMSUPPLYWO,WODOCUMENTPATH,WOFORM,WOHTMLGEN," + ;
		"WOIDCREATEFROMWO,WOKITTOTOPLEVEL,WORECEIPTAUTOALLOCATETODEMAND,WORECEIPTEXPIRYUSECONFIRMED,WORECEIPTMANUALTRACKINGENTRYATTRIBUTES,WORKALLOCATORNUMBEROFDAYS," + ;
		"WORKALLOCATORSHOWUNALLOCATED,WSDATAMANAGERURL"

If I remove some of the lines above and run the code, I see that the properties are being saved/restored correctly.

Paul

OK, thanks for the feedback!

Whether you assign a property at design time or run time does not change the maximum size (255 for native properties, up to 2^23 [8,388,608] for custom properties); should also makes no difference for FoxInCloud.

You found a solution and that's the essentials.

However, as filling a long list of properties as you did is rather tedious (I guess you used a programmatic _cliptext =), we'll align this behavior as form members' behavior: unless specified in .wcPropSaveNot, all custom properties will be added to .wcPropSave.

For optimization, you may want to move to .wcPropSaveNot the properties having the same value for all users, and keep only the user-dependent properties (the value of which may change during user events) in .wcPropSave.

I actually haven't found a solution.
I cut down the list of properties being saved as an experiment, just to continue development, but I will need the full list once I'm past the prototype phase.
The length of the string is just over 5000 characters and I have confirmed that this is being stored correctly in wcPropSave after later user requests.
It seems that something in FiC does not handle that many properties though when it comes time to save/restore their values.

The object with the problem is not a form, it is derived from the custom class; for forms I guess it would be very unusual to have so many custom properties, but for an object used to hold application settings it would be very possible.

Programmatically putting all custom properties into wcPropSave would be a good idea I think.

I can possibly work around the current problem by developing a hierarchy of object properties on DefaultsObject, to reduce the number of properties at each level, but it would be a lot of work.
Hopefully you can find what might be happening in FiC and I can wait until your next release.

Paul

It seems that something in FiC does not handle that many properties though when it comes time to save/restore their values.

Strange, we have applications in production using object public variable successfully…

Here is what you could do to test the save/restore mechanism (difficult for us to reproduce):

&& DefaultsObject is populated

set step on && in your program; can be in desktop mode

* -----------------------
strtofile(cXMLofObject(m.DefaultsObject), 'DefaultsObject.xml')

modify file DefaultsObject.xml nowait

&& manually modify a property value; XML syntax for a property:
&& <#p#><#n#>NAME</#n#><#t#>TYPE</#t#><#v#>VALUE</#v#></#p#>

DefaultsObject = objectOfXML(filetostr('DefaultsObject.xml'), m.DefaultsObject)

? DefaultsObject.property && check modified property

DefaultsObject.property = newValue
strtofile(cXMLofObject(m.DefaultsObject), 'DefaultsObject.xml')
modify file DefaultsObject.xml nowait
&& check newValue in XML

cXMLofObject() and objectOfXML() (modify command abOOP.prg) are the function that the public object variable save/restore mechanism uses.

You can play with several properties and report if you find something abnormal.

Thanks

Hi,

If I run that code in isolation then it appears to work correctly. But something doesn't seem right when I debug them at normal runtime, I think the saved XML doesn't contain the latest values.
I will continue to debug...

Hi,

I haven't looked any further into this problem yet, I'm still having to limit the properties that I'm saving.
Have you found anything, if you were looking at enhancing this area?

Paul

Sure, if we can understand and reproduce the issue we'll fix it.
So far we miss a reproducible description of the issue:

It seems that something in FiC does not handle that many properties though when it comes time to save/restore their values.

• could you see some properties being saved/restored and not others?
• according to your observations, is it a matter of number of properties or value?

As you're using a custom class for your config object, could you possibly implement an _assign() method for one property that you see NOT restored properly and track when and why it's changed:

procedure myProp_assign
lparameter myProp

strToFile(ttoc(datetime()) + ' - ' + cCallingModules() + ' - ' + cL(m.myProp) + chr(13), 'myProp.txt', .T.) && cCallingModules(): modify command abDev.prg

* assert .F. && better than a SET STEP ON as you can SET ASSERTS OFF if it pops up too often

this.myProp = m.myProp

I was going to try your suggestion, but I upgraded to V 2.28.1-beta.1 and the public object no longer restores any properties at all in my prototype code.

I have found that calling thisform.wFormMaster(), as I did previously, no longer works with the object; whereas calling thisform.wForm() does.

Pseudo-code showing the flow :

sficsets.Init
-> public DefaultsObject  
sficserver.wformStandardPage("loginform")  
-> loginform.loginbutton.click  
--> set properties on DefaultsObject, including object properties, arrays etc  
--> thisform.wFormMaster("menuform")  
----> menuform.Init - crash, DefaultsObject does not have properties set

DefaultsObject.wcPropSave contains my reduced list of property names that used to work, hard-coded in the class definition.
If I change thisform.wFormMaster() to thisform.wForm() then it works (but I don't want a child form).

Paul

Hi Paul,

crash

Do you mean program stops?

DefaultsObject does not have properties set

Do you mean properties are reset to the class value or blanked?

Did you check in wwRequestLog for an error?

To help us debug, can you try the _assign method I suggested?

Thanks

I have finally found the answer.

There is another property on DefaultsObject, named Colours. This property is also an object and it too has a property on it which is an object (named System); but System is created in a different way :

DefaultsObject.Colours = Newobject("sficcst")  
DefaultsObject.Colours.Addobject("System", "sficcst")

objectOfXML_propSet does not handle an object being added this way.

If I change my code to :

DefaultsObject.Colours = Newobject("sficcst")  
Addproperty(DefaultsObject.Colours, "System")
DefaultsObject.Colours.System = Newobject("sficcst") 

then it works and the public object is restored correctly.
Part of the trouble is that the main loop in objectOfXML_propSet is aborted with an exit command when it encounters the Colours property and because it processes properties in alphabetical order all of the remaining properties are never restored.

otherwise

		llResult = m.luValue == [#object#] and m.llChild
		= m.llResult or varSet(@m.lcResult, textmerge(icase(;
			cLangUser() = 'fr',	[La propriété de type objet '<<m.lcProp>>' n'a pas pu être restaurée],; && copy-paste this line to add another language support
													[Object property '<<m.lcProp>>' could not be restored]; && default: English
			)))
		assert m.llResult message cAssertMsg(m.lcResult)
		if m.llResult
			liChild = m.liChild + 1
			luValue = objectOfXML(; && /!\ récursion
				  m.loChild.item(m.liChild);
				, iif(m.llObject and lProperty(m.toResult, m.lcProp) and Type('m.toResult.' + m.lcProp) == 'O';
					, evaluate('m.toResult.' + m.lcProp);
					, .F.; && {fr} createobject('Empty')
					);
				)
		else
			cResultAdd(@m.tcResult, m.lcResult)
			exit && *************** ABORTED HERE ****************  
		endif

m.luValue = "" (#v##v# in the saved XML string)
Incidentally, m.tcResult contains an error message relating to the Colours property, but I have never seen where this message is recorded. I have not seen it in a table or log file...

Paul

Hi Paul,

Great debugging, thanks for sharing.

You're perfectly right: the result travels back up the stack to xxxProcess.Process() and then discarded.

We are a little late on creating a 'dynamic grid' form in FLT, sorry for that, we'll do it next week.

Have a great weekend!

Update: given the size of your state object, just curious how long 'restoring app. state for user' takes in your case… could you share that figure?