Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
HowTo Set Custom Form Property's Default Value
- Thread starter stanlyn
- Start date
Mike Lewis
Programmer
As far as I know, the only way to do this using native VFP tools is to delete the property and then create it again (which you already know).
However, there is a third-party replacement for the native property tool that can do what you want. Look for PEM Editor 7 at It's very easy to install, and once you have done so it will give you access to several other useful features.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
However, there is a third-party replacement for the native property tool that can do what you want. Look for PEM Editor 7 at It's very easy to install, and once you have done so it will give you access to several other useful features.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Not sure what your problem is. When I define a custom property for an SCX (or VCX form class), I can set it to whatever value (and data type) in the properties window. And that also becomes the default for the ResetToDefault() method.
You can also edit the description in the native "Edit Property/Method" dialog.
Chriss
You can also edit the description in the native "Edit Property/Method" dialog.
Chriss
- Thread starter
- #4
Hi,
Thanks Mike...
Glad you confirmed the issue and I wasn't missing something. Its always been trivial to deal with it and tonight, I thought I ask you guys as perhaps I'm looking in the wrong place.
As far as the Thor stuff goes, I have a hard time keeping it working and eventually go back to native.
Thanks again,
Stanley
Thanks Mike...
Glad you confirmed the issue and I wasn't missing something. Its always been trivial to deal with it and tonight, I thought I ask you guys as perhaps I'm looking in the wrong place.
As far as the Thor stuff goes, I have a hard time keeping it working and eventually go back to native.
Thanks again,
Stanley
- Thread starter
- #5
Chris Miller
Programmer
Are you after what default value a property is reset to when using the "Reset to Default" feature of the property window? Even if you change the default value when defining a property to something else than .F. that "reset to default" feature sets your property to .F. Only native properties are reset to their default.
But that changes in further subclasses. When using the reset to default of the property windo in a subclass, also the property window resets it to the parentclass value.
Nevertheless, this only is a weak point of the property window. Code using the ResetToDefault() method respects the value you have set at deign time as the default. That's simply because the first value a property has at runtime is its default value. So, actually these features are named the same, but differ in what precisely they do. If you take a form's tag property, just to pick one that has no restrictions by other rules, and set it to "this is the tag" in the design phase and use thisform.resettodefault("tag") in code, that doesn't reset the taag value to the empty string, because that's it's default by class definition. In a property window at design time, the feaature does reset the tag to the empty string though. But in subclasses the string "this is the tag" you set in the parent class is the new default.
So in short you coudl say there are design time and runtime default values of properties. On top of default values that exist per data type in general.
Chriss
But that changes in further subclasses. When using the reset to default of the property windo in a subclass, also the property window resets it to the parentclass value.
Nevertheless, this only is a weak point of the property window. Code using the ResetToDefault() method respects the value you have set at deign time as the default. That's simply because the first value a property has at runtime is its default value. So, actually these features are named the same, but differ in what precisely they do. If you take a form's tag property, just to pick one that has no restrictions by other rules, and set it to "this is the tag" in the design phase and use thisform.resettodefault("tag") in code, that doesn't reset the taag value to the empty string, because that's it's default by class definition. In a property window at design time, the feaature does reset the tag to the empty string though. But in subclasses the string "this is the tag" you set in the parent class is the new default.
So in short you coudl say there are design time and runtime default values of properties. On top of default values that exist per data type in general.
Chriss
Chris Miller
Programmer
I'm not even seeing that, Stanlyn. If I first set a properties default to a string I can later also set it to a datetime, for example.
Chriss
Chriss
Chris Miller
Programmer
Maybe your experience differs from the native VFP, as you have installed Thor. That overrides these native dialogs. In native VFP no property you define is strictly typed. The only strict typing is happening, when you set the value property of a control to something at runtime that type can't be changed. So a 0 default value can not turn to a string. Otherwise only controlsources of table field cause a strict data typing, as table fields are strictly typed.
PS: I realized I have Thor installed, too, already, just not configured to start with the IDE. So just CD Thor and then DO Thor and then Check For Updates. The PEM editor in it's current version is included in Thor and allows you to specify the default value not only when defining. Anyway, setting the value of a user-defined property in the property window does still do the same. Besides, I still don't see a strict data typing feature and whatever you set as a default value can be overridden with other data types too.
No worries, if you're fine with being able to set the default in this PEM editor, that's okay. But strict typing is a separate topic than default value anyway.
Chriss
PS: I realized I have Thor installed, too, already, just not configured to start with the IDE. So just CD Thor and then DO Thor and then Check For Updates. The PEM editor in it's current version is included in Thor and allows you to specify the default value not only when defining. Anyway, setting the value of a user-defined property in the property window does still do the same. Besides, I still don't see a strict data typing feature and whatever you set as a default value can be overridden with other data types too.
No worries, if you're fine with being able to set the default in this PEM editor, that's okay. But strict typing is a separate topic than default value anyway.
Chriss
Mike Lewis
Programmer
Stanley, I agree with you. If I faced this problem, I would also simply delete and re-create the property. It would ohly take a moment, especially as you can copy and paste the name and comment rather than having to type them again.
That said, I don't recall ever having the need to change the default value of a property. I would prefer not to have to rely on a default, but rather to explicitly set the value each time. But your needs might well be different.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
That said, I don't recall ever having the need to change the default value of a property. I would prefer not to have to rely on a default, but rather to explicitly set the value each time. But your needs might well be different.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Mike, Stanlyn.
There really is no need to do that, as you can simply change the value of your property in the property Window. If you do so, it also changes the Default Value displayed in the new PEM Editor. If you not use the Default Value field of the PEM editor but simply change the property value in the property window and go back to the PEM editor, the default value reflects your change.
Chriss
There really is no need to do that, as you can simply change the value of your property in the property Window. If you do so, it also changes the Default Value displayed in the new PEM Editor. If you not use the Default Value field of the PEM editor but simply change the property value in the property window and go back to the PEM editor, the default value reflects your change.
Chriss
Mike Lewis
Programmer
Chris, good point about changing the value in the property window. I should have thought of that. It's obvious, now that you mention it.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
The point is, that a property is not having a default value like a table field has a default value.
Whatever you store in a class is the default value and similarly to a field default, you can set a property to =expression which makes VFP evaluate that at the instantiation/initialization or when you DO a form, as we talked of form properties here.
But unlike a field that can have a default value of 0 and then change to any other integer in a record, which still keeps the default at 0, if you set a property to something that is the new default. Don't get me wrong, I''m not saying when you start a form and change a property that's the new default, I'm only talking about changing the value in the form designer.
You can simply do that and check it with the new PEM editor that shows you nothing else but what you set in the properties window. Therefore this lack of a form control to change the default value in the native VFP PEM editor is not important. You never needed to remove a property and redefine it again with another default. The new PEM editor just makes that change available in two places, both in the PEM editor and in the property window.
So if you have the idea the default differs from the actual value, then define a user-defined property, and set it to 42, for example. Set it to 21 in the property window and go back to the new PEM editor, the default value will then not be 42 anymore, it's now 21. Whatever value or expression you last set at design time is stored with the form (or class in case you design a class with a user-defined property) and that is the value when you create an instance or do the form - the default value. So the new property dialog always only gave you the option of entering the initial default value. It didn't fix it, as you can always change it simply in the property window.
The only place the value is more special is when subclassing. The value stored with the class then becomes the default for the subclass, too. Subclassing is just referring back to the parent class with all its PEMs including their (default) values. And then also the "reset to default" feature of the property window and the new PEM editor reset to the value stored in the parent class.
On the same level. In the form or in a class in which you created a new property the "reset to default" always sets a user-defined property back to .F., which also shows that there is no separately stored default value like that of a field. The features of the default value you enter when you create a property is unimportant, it's simply the property value, and it's nothing separate from that.
So all this dialog field allows you to do is set the initial value. If you then later change it, you overwrite this. So in short it's simply like that: The last value you set a property to in the form or class designer is the default that a starting form will have or that a created object will have.
So all the PEM editor gives you is one more way to change a property value. The new PEM editor is like a combination of a PEM editor and the property window. And that's comfortable, but nothing more.
Chriss
Whatever you store in a class is the default value and similarly to a field default, you can set a property to =expression which makes VFP evaluate that at the instantiation/initialization or when you DO a form, as we talked of form properties here.
But unlike a field that can have a default value of 0 and then change to any other integer in a record, which still keeps the default at 0, if you set a property to something that is the new default. Don't get me wrong, I''m not saying when you start a form and change a property that's the new default, I'm only talking about changing the value in the form designer.
You can simply do that and check it with the new PEM editor that shows you nothing else but what you set in the properties window. Therefore this lack of a form control to change the default value in the native VFP PEM editor is not important. You never needed to remove a property and redefine it again with another default. The new PEM editor just makes that change available in two places, both in the PEM editor and in the property window.
So if you have the idea the default differs from the actual value, then define a user-defined property, and set it to 42, for example. Set it to 21 in the property window and go back to the new PEM editor, the default value will then not be 42 anymore, it's now 21. Whatever value or expression you last set at design time is stored with the form (or class in case you design a class with a user-defined property) and that is the value when you create an instance or do the form - the default value. So the new property dialog always only gave you the option of entering the initial default value. It didn't fix it, as you can always change it simply in the property window.
The only place the value is more special is when subclassing. The value stored with the class then becomes the default for the subclass, too. Subclassing is just referring back to the parent class with all its PEMs including their (default) values. And then also the "reset to default" feature of the property window and the new PEM editor reset to the value stored in the parent class.
On the same level. In the form or in a class in which you created a new property the "reset to default" always sets a user-defined property back to .F., which also shows that there is no separately stored default value like that of a field. The features of the default value you enter when you create a property is unimportant, it's simply the property value, and it's nothing separate from that.
So all this dialog field allows you to do is set the initial value. If you then later change it, you overwrite this. So in short it's simply like that: The last value you set a property to in the form or class designer is the default that a starting form will have or that a created object will have.
So all the PEM editor gives you is one more way to change a property value. The new PEM editor is like a combination of a PEM editor and the property window. And that's comfortable, but nothing more.
Chriss
- Thread starter
- #13
Hi,
A long time ago I adopted a naming convention where lc=local char, ln=local numeric, gc=global char and so on. Because of this habit, I never do reassignments Changing a type from char to numeric or vice versa always has been a no-no and creates chaos. This style has served me well. When adding a memory variable within a form, I declare public and private vars and assign a value to them. I almost never declare a local as local as an undefined var is local by nature, however I do an assignment that sets its type.
I always set the type on custom form variables like "thisform.fvcColor" when created. The 'fvc' tells me it is a 'form variable of type character' while a 'fmJump' is a form method. I use these only at the form level, avoiding public vars.
Mistakenly, I have assigned the wrong type to one of these form variables and my original question was how do I easily change it's definition. I know I can in the form's init do a "Thisform.Color = ''" that sets its type and initializes it to an empty string. That is 20 characters to many, as opposed to 2 when set at creation time. I'm a fan of "set-it-and-forget-it".
I am aware of and agree with most everything Chris wrote about. I almost never have issues with reassignments, simply because I don't do reassignments. And I certainly see how this could quickly become chaotic without adhering to a convention.
Thanks,
Stanley
A long time ago I adopted a naming convention where lc=local char, ln=local numeric, gc=global char and so on. Because of this habit, I never do reassignments Changing a type from char to numeric or vice versa always has been a no-no and creates chaos. This style has served me well. When adding a memory variable within a form, I declare public and private vars and assign a value to them. I almost never declare a local as local as an undefined var is local by nature, however I do an assignment that sets its type.
I always set the type on custom form variables like "thisform.fvcColor" when created. The 'fvc' tells me it is a 'form variable of type character' while a 'fmJump' is a form method. I use these only at the form level, avoiding public vars.
Mistakenly, I have assigned the wrong type to one of these form variables and my original question was how do I easily change it's definition. I know I can in the form's init do a "Thisform.Color = ''" that sets its type and initializes it to an empty string. That is 20 characters to many, as opposed to 2 when set at creation time. I'm a fan of "set-it-and-forget-it".
I am aware of and agree with most everything Chris wrote about. I almost never have issues with reassignments, simply because I don't do reassignments. And I certainly see how this could quickly become chaotic without adhering to a convention.
Thanks,
Stanley
Chris Miller
Programmer
Stanlyn,
that's a fine habit, but that's still beside the point. You don't need the "Default Value" of the new PEM editor to change it. You have a wrong concept of what the default value is and I think it won't help to try to explain it for a third time. Have fun with this new feature and use it, if you feel better that way.
What you did compares to this analogy in code, though:
Oops, that set a sting variable to a numeric default value in the code. But we're still in the design of all this, it's not yet running.
So, if you actually wanted lcZero to be the string '0', you don't need to remove the LOCAL declaration of the variable, you just need to put the quotes around the zero in the code. Likewise, you can just change the wrong default value you entered at first in the property window. There is no need to use the Default Value box only available in the New Property dialog.
And the new PEM editor even proves it by having the Default value shown. When you don't use that to change it to the right default but go into the property window and change the property there, that will be shown as the new default value in the new PEM editor dialog, too. Because there is no separate default value. You still have a wrong idea about what the default value is.
You must imagine the first value you set defines the type of the property. But no property you create user defined or with the AddProperty() function or method can have a strict type. That's reserved for the native properties. You never can set the caption of a form or a label to a date, for example, only the string representation of a date. You can set the rowsourcetype only to certain numbers, even jsut a small range. Such things are never available to us.
Recreating a property just because you first entered the wrong type is unnecessary, though. That's just over the top of adhereing to that good habit.
Chriss
that's a fine habit, but that's still beside the point. You don't need the "Default Value" of the new PEM editor to change it. You have a wrong concept of what the default value is and I think it won't help to try to explain it for a third time. Have fun with this new feature and use it, if you feel better that way.
What you did compares to this analogy in code, though:
Code:
LOCAL lcZero
lcZero = 0Oops, that set a sting variable to a numeric default value in the code. But we're still in the design of all this, it's not yet running.
So, if you actually wanted lcZero to be the string '0', you don't need to remove the LOCAL declaration of the variable, you just need to put the quotes around the zero in the code. Likewise, you can just change the wrong default value you entered at first in the property window. There is no need to use the Default Value box only available in the New Property dialog.
And the new PEM editor even proves it by having the Default value shown. When you don't use that to change it to the right default but go into the property window and change the property there, that will be shown as the new default value in the new PEM editor dialog, too. Because there is no separate default value. You still have a wrong idea about what the default value is.
You must imagine the first value you set defines the type of the property. But no property you create user defined or with the AddProperty() function or method can have a strict type. That's reserved for the native properties. You never can set the caption of a form or a label to a date, for example, only the string representation of a date. You can set the rowsourcetype only to certain numbers, even jsut a small range. Such things are never available to us.
Recreating a property just because you first entered the wrong type is unnecessary, though. That's just over the top of adhereing to that good habit.
Chriss
- Status