>It's all relative - you have transmitted the idea faster than the Web could do it. Sort of telepathy :). Or was it the effect of the "Calendar Control 8.0 - How do you return value?" that you sent just a few minutes before, that actually solved this one.
Well this (with ActiveXs) is a common problem so that i think it should be moved in FAQ, but how many of the newbees in UT, know to search the FAQ?

>Just the other day, messing with some scrollbar Activex, I had to solve the exactly same thing myself. Along the way, I found an explanation why do these ActiveXes need the .object. While VB help says just "Provides access to the Automation server properties and methods for an OLE object. Not available at design time." (which doesn't explain nor help much), the Outlook VBA help says "If you add a new control to the Microsoft Forms Toolbox, it is possible that the added control will have a property or method with the same name as a standard Microsoft Forms property or method. The Object property lets you use the property or method from the added control, rather than the standard property or method."
This is true, I will say it again - when you use ActiveX, they, in all programming languages are placed within standard container. How it will be named - OLEControl, Extender or something else, depends on the language. This standard container has its standard properties - e.g. height, width, left, top, value and some other. Also it has some standard methods - Refresh, MouseMove, etc. The ActiveX control itself may have some of that "standard" (only for that language, maybe not standard for other one) properties and methods.
Note that ActiveX as technology is language independand. When you develop ActiveX there are common rules to follow. So when you develop an ActiveX you can not know some restrictions or "standard" features of the language in which your control will be used.

>Why would anyone care about two controls having the same property or method names as one of the standard ones?
Should care, especially if you have different meaning - suppose that ActiveX has a ControlSource property that bounds it to ADODB (standard ActiveX) data provider. In VFP this property will have some other meaning - the cursor field or memory variable or object property to which the control is bounded. But this properties will be different - The ActiveX one will be set with .object.ControlSource and the "standard" VFP one will be property of the OLEControl. In this case it will be better to avoid using the language dependand property of the OLEControl object - should leave it blank.


>It's VB, and one more reason for me to not even try to learn it (not that I didn't - I even got a few things to work, just didn't like its lack of proper OOP).

What is VB? ActiveX is language independand technology. Do you aware that there are many ActiveX written in VC++, Delphi and some other true OOP languages (this includes VB), that are not specialized.
VB lacks of proper OOP? Not sure. Have you seen the object model of VB.NET? Even VB6 has good object model.
I am a VFP fan, but I know that VFP is not the only language in this universe.
If I have to write a database application - I will write it in VFP!
If I have to write an ActiveX - I will not write it with VFP, because it is inpossible with the most recent version of VFP (VFP7 SP1).

Kind Regards