New class: property options

[mpgalvin]

I've created a new class based on a form, and added, amongst other things, some properties. One of these properties is .ShowHelp, which is either .T. or .F., .F. by default.

When I use the class, I know that it can be either .T. or .F. but I'd like to give the other programmers a chance by giving them options. Whether it appears in the properties dialog with a dropdown, or just double clicking toggles it from .F. to .T. and back again.

Is there any way of doing this?

 

[ramani]

Hi
When you sub-class, all the properties are still available in sub-classed form. The beauty of sub-classing is that all the properties of the parent class are inherited, but any one can change any of the properties for that form alone.

SO the question is what is in it, then ? The thing is that you can set the property like the one you are talking and globaly change the property for all the forms from a single parent form propety change. The specific properties applicable for a circumstance alone can be changed in the child classes. So leave the property in child forms as default unless you want to specificaly set it to something.

Note.. even if you key in .t. in the child form as you specified above, which may be default behaviour... but the child wont get that acquired if you change it in the parent, if that property is specificaly entered in the child form.

Hope this information helps you ramani :-9
(Subramanian.G),FoxAcc, ramani_g@yahoo.com

 

[rgbean]

About the best you can do is add the information you want to share in the Description field for the property. This will show up in the Proprty Description window at the bottom of the Property sheet.

Rick

 

[mpgalvin]

ramani, the question may not have been clear. The property is a new property, not an existing property of one of the child controls. From what Rick is saying, it seems pretty clear that I can't actually give the developer options for my new property (this can be .T. or .F.) and the best I can do is add them to description so that he knows.

Kinda sucks, but I guess I was asking for a lot. I'm gonna have to write an email to explain it to them.

 

[rgbean]

You may want to post this idea on the UT VFP Wish List (

http://www.universalthread.com/wconnect/wc.dll?FournierTransformation~?2,57,3,1).

You'll need to sign in to the UT to get to this address, but registration and most services are free.

There are a lot of MS people from the VFP team that hang out here, and many of the ideas on the last list were put into VFP 7.0.

Rick

 

[DEDMOD]

I wonder why this capability isn't available? It's obviously possible since the properties of the base classes have it. I'd think it'd be pretty easy to have a separator character in the memo fields of the tables that objects are created from to indicate individual property possibilities.

Dave Dardinger

 

[rgbean]

Dave,
Base class peroperties normally have a predefined type and sometimes only specific valid values. Since historically FP variables and user defined properties are untyped (type is based on current stored value), this wouldn't be easily implemented. First you'd have to introduce the concept of strong (permanent?) variable typing, then add an enumeration capability - this would greatly change the nature of VFP variables. (Many people still haven't got variable scoping figured out - especially the "new" LOCAL vs. PRIVATE.)

One way of partially implementing this, would be to add an ASSIGN() method to your properties, and check the type (and value?) before allowing it. You could use a Messagebox to warn/prevent the developer from putting in a wrong type/value.

Rick

 

[DEDMOD]

Well, what we're dealing with, AFAIK is simply the properties window. This contains a representation of the properties, not the properties themselves. What would be needed would be a change to the new property and new method windows which would allow you to enter a series of values which would then be the choices presented in the properties window. If necessary there could be a set of radio buttons to choose which type the data is to be intrepreted as. I don't know how difficult it would be internally to the FVP code to implement, but my guess is not very.

Dave Dardinger

 

[jmcswain]

You are looking for a simple enumeration, which is a very common and easy to implement feature in any language. Simply assign a name to the enumeration, add a list of valid values along with the labels associated with each value, and set the property type of your new custom property to the enumeration.

Sadly, the lazy slackers at Microsoft decided to put this feature in Visual Basic, but not in Visual FoxPro.

As far as VFP's weak typing, that wouldn't matter. VB can have variants as well, and it doesn't prevent enumerations.

 

[rgbean]

While I don't particularly like the role of defending MS, my point was that adding these particular features may not be so "easy" - especially without breaking all the backward compatibility that is required in any new feature. I've written non-trival interpreters (although obviously not as complex as VFP 7.0 is), and this is certainly not an easy excercise. MS BASIC started with variable typing so it awsn't something they needed to "add-on". VB, like Access, has always taken a much more free-wheeling approach to backward compatibility - "if it doesn't work in the newest version, you probably didn't need it - just re-write it". Just take a look at what VB.Net is going to do to many of the "old" VB 6.0 programs!

As far as "lazy slackers", you've obviously never met or spend time with any of the MS VFP developers. You might want to visit the UT (

http://www.universalthread.com/)

and make that suggestion over there. There are a number of them that regularly participate in the discussions and answer questions (on their own time). In fact one of our local user group members, just spend 6 months as a "consultant" to MS so they could get the testing of VFP 7.0 done and out the door. She indicated she has never worked harder or felt there were a more dedicated bunch of programmers that those she had the priviledge to work with. (MS offered her full time work, but her family roots are back here in Michigan, so she had to decline.)

Rick

 

[DEDMOD]

Sigh! I'd just typed a long response in and somehow just as I was prepraring to sign it, managed to hit a combination of keys which erased it all. Let me try again.

I don't see that the implementation of the suggested enhancement would involve the interpreter at all. As I said earlier, it should involve merely the Properties Window. This window would appear to go back through the hierarchy of classes for a given object and gather the properties and their values. It has to have some method of deciding where the default value is (except for the base class itself it's in one of the memo fields of the subclass where it's defined, I assume). But even in the base classes, I assume the code controlling the properties window does a library call and is returned a value or an array of values. Why shouldn't it be able to do the same thing for user properties?

Nor do I see why this would be a problem with legacy code. Can't a new version of VFP tell what version of VFP a give project was written in before it tries modifing it? I suppose you wouldn't be able to modify a project in VFP 8.0 and then go back and compile it in VFP 3.0 without problems, but that's always been the case, AFAIK.

Finally, I took 'lazy slackers' as a sardonic remark; a commiseration about the underapprecieated MS programmers, not a complaint about their work ethics. I'm sure we'd all like to see MS hire twice the number of programmers to implement all our wishes. And then seem them charge less for the resulting product.

Dave Dardinger