• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 259
  • Last Modified:

Where are the default properties of a form stored?

When you create a form, all the properties (and methods) contain a default value.  (For example, FontName might be Arial.).  If you change the value, the new value will appear in the .scx properties for the object, but only if you change it.  

If it is unchanged and not in the object properties, Vfox "knows" to look at the default value.

Where do the original values come from? Are they stored separately for each form or is it system related.

Thanks for you help
0
AlanArons
Asked:
AlanArons
  • 6
  • 4
  • 3
2 Solutions
 
pcelbaCommented:
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/
0
 
Olaf DoschkeSoftware DeveloperCommented:
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.
0
 
AlanAronsAuthor Commented:
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
0
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

 
Olaf DoschkeSoftware DeveloperCommented:
What do you want to do?
Default values can be seen easiest way in the property window at design time. Copy value, right click, set to default, then put back the value or don't save your changes when exiting the form designer.

Getting at default values of course also is easy by starting the SCX, but you can also programmatically modify the form and get at defaults:

Modify Form yourform.scx Nowait
=ASelObj(laObjects,1)
o=laObjects[1]

Open in new window

Now inspect any property of interest.

Bye, Olaf.
0
 
AlanAronsAuthor Commented:
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
0
 
Olaf DoschkeSoftware DeveloperCommented:
Look out for BuilderB or BuilderD. Writing a Builder you need about the same things as documenting a form, class or any project file, you need to be able to read properties and code.

Also look at AMEMBERS, AVCXCLASSES, ACLASS, ADBOBJECTS, AFIELDS...

Bye, Olaf.
0
 
pcelbaCommented:
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)
0
 
Olaf DoschkeSoftware DeveloperCommented:
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

Open 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.
0
 
pcelbaCommented:
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.
0
 
Olaf DoschkeSoftware DeveloperCommented:
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.
0
 
AlanAronsAuthor Commented:
Thanks guys, I really appreciate your help
0
 
Olaf DoschkeSoftware DeveloperCommented:
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.
0
 
pcelbaCommented:
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.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

  • 6
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now