Hi,

I would like to suggest two things for an object's wcPropSave :

1. add "visible" to the list during adaptation, it is something that is used quite often

2. introduce a hierarchical approach to wcPropSave, where the wcPropSave of the parent classes are appended to anything explicitly listed in an object's wcPropSave.

The problem currently is that adding something to wcPropSave on an object prevents anything defined in higher classes from taking effect and you have to remember to manually add everything that would have been included if the property been left at its default value.
Adding "visible" is an example, where I have had to add it to every class in the class hierarchy of almost every object because adapation has already modified wcPropSave at some layers.
This might make restoring property values a little inefficient if not all named properties are actually being set in object instances on forms, but that would not be too bad would it?

I'm interested to know if you think that would help or hurt the current implementation.

Paul

Hi Paul,

At class level, we recommend setting .wcPropSave programmatically using wcPropSaveEdit() of awPublic.prg, in either .Init() or form.Load(); eg:

procedure init
…
wcPropSaveEdit(this, "Visible,Enabled")
…
return dodefault() && make sure to always call dodefault()!

This way, at design time, you can set .wcPropSave at instance level without caring for the class requirements.

Here is a sample form code (seek 'wcPropSaveEdit')

Hello Paul,

Why not modify your basic classes by saving enabled and visible eg for your textbox and buttons ?
Thus, the properties saved on the parent class are clearly visible on any inherited object

Vincent

Yes good idea setting it programatically, that way it won't matter if the adaptation process has overridden wcPropSave on a subclass and I want to add something new to all levels. I will programatically add all user-defined properties to wcPropSave in the Init().

Would there be a problem if I included the FiC properties (wa*, wc* etc) in the list too, or should I exclude those?

Paul

FoxInCloud adds all user-defined properties automatically to .wcPropSave so all you need to do is:

• wcPropSaveEdit(this, 'native properties that user action changes')
• wcPropSaveNotEdit(this, 'user-defined properties that you don't want to save and/or are not user dependent')

FoxInCloud takes care of its .w* properties.

FiC adds user-defined properties to wcPropSave during adaptation, but I'll still add them programatically so that I pick up all new properties and any added during runtime.

Regarding the FiC properties, I'm just wondering if I need to explicitly exclude those from the list I will generate, or if it doesn't matter if I do include them; I know that FiC will take care of its own stuff, but if I add them to wcPropSave also and this might cause problems then I will have to exclude them based on a naming skeleton like wa*, wc* etc.

I should have specified, FoxinCloud Application Server (FAS) adds user-defined properties at run time, before initial properties save.

You can check it in temp\form_ini.dbf; eg. if you addProperty() in an object.Init(), it'll show up in temp\form_ini.dbf without changing its .wcPropSave

If you follow this behavior you no longer need to care about FoxinCloud properties.

Hi,
I just want to make sure I am understanding you correctly.

From my observations it seems that, at each class level, all user-defined properties are now being added by FiC to wcpropsave automatically at runtime.
So, for a form instance or an instance of any other control the end result is a concatenation of the user-defined properties from the many parent layers and the current instance itself.
In other words, the code I have added which does this job is no longer needed and I can rely on FiC to totally take care of all user-defined properties.

Is this right?
What about native properties? Is FiC detecting code that changes these properties and only adds those changed properties into wcpropsave?
And the newer version of FiC also saves/restores all properties on public objects?

Thanks
Paul

Is this right?

yes

What about native properties? Is FiC detecting code that changes these properties and only adds those changed properties into wcpropsave?

FAA detects native properties that each class or instance changes in its own code; it does not detect properties changed by other classes or instances; we have had this improvement in the roadmap for long, but it's quite complex and for now you need to add the modified native properties to .wcPropSave either at design time or by using .wcPropSaveEdit() as explained earlier.

And the newer version of FiC also saves/restores all properties on public objects?

all user-defined properties, yes since V 2.28.1-beta.1… not native properties however you seldom need to save them on this kind of object.
also true for _Screen.customObjectProperties and _VFP.customObjectProperties