Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Naming conventions for custom methods?
Message
From
20/11/2008 13:43:07
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
01362229
Message ID:
01363264
Views:
39
>>>If it's a bad idea, go tell the Fox team that they screwed up :).
>>
>>In VFP I would do a check for a form property and if it didn't exist, create it on the fly. I did that mostly because I had to share code with other developers and merge it. In most cases eventually the check never failed and the property existed when code got merged. It wasn't a longterm solution.
>>
>>You can programmatically add controls to a form at runtime:
>>
>>http://support.microsoft.com/kb/319266
>>
>>Properties though I don't know about. I know you can create types at runtime and types can have properties, but I don't think you can add a property to a type at runtime. Maybe you could inherit from it and add a property or something. Still, wouldn't it require reflection since the property wasn't known at compile time? How else could you access it?
>>
>>This would be a good discussion in the net c# section where the net gurus would see it....
>
>I think Dragan was just being a contrarian ;-)
>
>Was thinking about this more in the car yesterday and still can't figure out why I would want to add a property to an object on the fly. Maybe that is something that is in VFP for tool builders, not tool users like me.

Software is a tool, most of the time. Computers would be bricks without it; with it, they become useful. It enables the user to do something. The difference is in the user - is he another programmer or is he doing something else.

Back to the subject, .addproperty() and AddProperty() (method and function) are actually a more of JavaScript-like way of building objects instead of rubberstamping them off a class.

Again, as in the example I gave, I find it very useful in situations when I'm nor sure whether the object on which I'm operating has the property or not, and it's far less code to just slap it on and then read it when needed, regardless of what the object is. Even in such simple situations as

loObjectRef.addproperty("lDidWeMeetAlready","Yes") && because now we did, i.e. this will be true next time I access the property

This way I don't have to know whether the object has this property, and I also have near zero chance that I will be stepping over an existing property of the same name (if that's the case, I can create a sys(2015) name for the property), and this will work regardless of whether everyone forgot(*) to write code for that property.

Specially handy for Scatter Name objects when you scatter from one table then want to insert into another, having a few fields more, or such objects simulated, when you start with createobject("empty"), then add properties at will and then use that to insert.

Again, I don't want to be specific on any cases, uses and situations, and I don't want to answer any of "what do you need that for", because those inevitably lead to discussion over the specifics and individual cases, and the general issue remains unaddressed, like a blank envelope.

----------
(*) The only correct answer to "who forgot to turn off the light" is "everybody", because if at least one person had remembered, the light would have been turned off.

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform