What's the difference between explicitly setting and explicitly calling?


THISFORM.SetMode("add")

seems jst as easy as

THISFORM.Mode = "add"


>But why not use them? Heck, they're an addition to the language that nobody is twisting your arm to use. I think they're a lot more flexible than Get and Set. An Assign event is raised automatically without explicit calling and that makes it powerful stuff for good event driven design. With Set you have to explicitly call.
>
>
>>>
>>>>Everybody disagreed with me on my (apparently unpopular) stance.
>>>
>>>Well, let my voice join those who disagree with you [g].
>>>
>>>Here's one thing you can't do without Access and Assign methods: create a collection class that exposes its Item array and allows specifying the element index as either a number or name. Yes, you can do that with an Item method, but then you can't use code like:
>>>
>>>oCollection.Item["my item"].SomeProperty
>>>
>>>which means your collection doesn't behave like other common collections (ActiveX and VB, for example) do.
>>
>>
>>Yeah, I've done this a couple of times, and will step back and add this to the legitimate uses list. But, even with this little trick, the collections still aren't perfect. You can't use FOR EACH on them, which is almost ALWAYS the way I access all the items in a colleciton, unless I need to know the index at some other point in the loop. So implementing a collection like this in a COM server and calling it a collection would be a really bad idea, because a programmer using the server from another language would assume it IS a collection and might want to access it with his language's FOR EACH construct. (FOR EACH seems to be the most popular way in VB as well)
>>
>>
>>>Also, I fail to see why you distinguish native from custom properties. If you're creating a class that other people would use, isn't it nicer to be able to hide implementation details (like custom vs. native) than making them extremely obvious by the fact some some properties can be accessed and set directly but others have to go through Set and Get methods?
>>
>>I can think of only a few instances where a calling procedure would set the native proprties of any of my custom classes, and none in non-visual classes. The only reason I distinguish them, is there is no other way except Access and Assign. with all custom properties, you can hide the property name behind Get/Set pairs.