Where are the default properties of a form stored?

Some default values of non-object elements like default Report font are stored in Windows Registry (if you decide so). You may find these settings in the Tools - Options - IDE tab.

Form and other objects default properties are hardcoded in the FoxPro itself. Each VFP object is derived from its BaseClass and all BaseClass properties are hardcoded inside VFP.

You may find default hardcoded values in VFP help - Form.FontName = "Arial", FontSize = 9 etc.

This approach was designed for one simple reason - you may easily create a set of your own "super classes" derived from the VFP base classes, assign your own default values to these super classes, and use them in place of original VFP base classes.  This is not possible for non-object elements so you may set the BROWSE font in VFP Options but the default Grid font must be set in your class.

The latest VFP help and other community add-ons are available here: http://vfpx.codeplex.com/

The set of base classes Pavel talked of are defined in VFP9.exe and of course also in the VFP runtime DLLs, hardcoded in them, there always is an original of which all objects are blueprints, the same applies to subclasses, though you don't create an instance but a new master. So the original default simply are some bytes of the vfp9.exe or vfp9r.dll
As a side not: What is not copied into object instances allocated memory is code, the methods are instead referenced.

The defaults of the base classes are simply copied into any new object and then it's independant of these and the properties can be set to any possible value like variables can. A form object reserves as much RAM as is needed to copy in all form properties with their default value from the class you instanciate, not just the properties with non default values.

The concept of "looking back at defaults" is true for the ResetToDefault() method. It has to look back into the parent, parents parent or finally the base class, true.

Also there is no way to define a class not basing on any base class so there always is a inheritance chain ending in some class definition. The simplest class you can inherit from is custom and it's meant as root class for any multi purpose custom class.

One interesting thing is, if you define own properties their default value is not what you enter into the property window at design time of your class, it's always .F., like the default value for any variable. ResetToDefault will always set user defined properties back to .F.

Bye, Olaf.

Interesting,  I guess I wont get them from there.

I am working with the .scx file and looking directly at the records.

The record with platform="COMMENT" and uniqueid="RESERVED" properties field contains some information about the form font values.  I have been able to identify the font name, attributes and size as the first 3 values in the string.  Any idea what the balance translate to?

Thanks for your help

Alan

I am looking for a way to document all the objects and the code you provided seems to give me everything I need.

Thanks Olaf

Alan

It seems you are trying to reinvent the wheel...

http://gorila.netlab.cz/pdm.html

http://msdn.microsoft.com/en-US/library/2w31zx31(v=vs.80).aspx

I have to correct Olaf's ResetToDefault bahaviour description:
ResetToDefault() resets the property to its original INHERITED state not to .F.

If you create a new property in some custom form class and set its value to .T. then ResetToDefault() call in any instance of this class changes the value to .T.

Arial, 0, 9, 5, 15, 12, 32, 3, 0 means:
name, attribs, size
4. Average character width
5. Character height
6. Character ascent (units above baseline)
7. Maximum character width
8. Character descent (units below baseline)
9. Extra leading (probably)

Pavel, I tried before writing that, but just with nonvisual classes, so let's correct this once more. What I said is true for nonvisual classes:

o = CreateObject("myclass")
? o.myproperty && 0
o.ResetToDefault("myproperty")
? o.myproperty && .F.

Define Class myclass as Custom
   myproperty = 0
EndDefine

Select allOpen in new window

I have made the shortcut assumption, this would also be true for visual classes or SCX. I haven't tested pavels statement, but I trust him. If the behaviour of ResetToDefault() should be consistent we have found a bug here, at least a difference between visual and non visual classes that perhaps is by design.

Edit:
One more thing about reinventing the wheel. First forget about the documenting wizard. I tried it and especially looked at the aspect of finding property default values. You can forget about that. It's quite useless and the output rather puzzles me than gives an insight about the project structure.

PDM is what I haven't found. It could also be improved and you can find a lot of info with several array creating functions I mentioned quite easy. Actually I'd go for reinventing the wheel, if you want the informations you want in your way, because you don't reinvent much. To be more precise: If you want an answerto a certain aspect it's easier to write the needed code to get at the information needed than to dig into PDM, especially if it's output is not answering your question or only partly does.

Also look at _vfp.activeproject.Files collection for iterating all project files. The definition of an item and the meaning of it's propeties and possible values also is documented in the VFP help.

Bye, Olaf.

LOL, new VFP bug one day after the support end... :-)

This seems to be PRG classes bug not visual/non-visual.

I've added Custom class to my form. Both classes stored in VCX and ResetToDefault works as expected on my form. OTOH, Form subclass created in PRG resets properties incorrectly.

OK, we have to define ResetToDefault method in the subclass.

Cool, I'm the first finding a bug after no way exists to fix it.

Well, it wouldn't be in the category of bugs MS would have fixed yesterday.

Bye, Olaf.

Thanks guys, I really appreciate your help

Actually I used the term non-visual for PRG. I know the usual definiton is classes literally not visible at runtime, but eg timer and custom are visible at designtime. There is no visualisation of PRG classes at design time. I find the term PRG class unexact, as the classes are defined by the DEFINE CLASS function, it's secondary this is only possible in PRGs.

Anyway, I could have used the normal nomenclature, sorry.

Bye, Olaf.

I'll post this bug to VFP 9 help authors. To mention it in the next help release is the minimum we can do here.