This statement of your makes my point:

"How do I decipher the information exposed by the object browser and determine if an object supports automation, and what the general syntax for scripting it if it dŒs."

Any object in the Object browser is there because it supports automation. It would not be in the object browser if it didn€™t support automation

This is why I suggested you learn the basics.  Objects in the "object browser" are all 'COM' objects.  'COM' is 'automation'.

Scripting is not automation and it is NOT 'COM'.  Scripting and all other languages in Windows usually include support for COM but don't necessarily have to.

COM is about COM.  Interfaces are how we access COM objects in Windows.

I think you need to work a bit on the fundamentals of Windows technologies.  I don't say that to abuse you but to try and get you to accept that you are missing some of the basics.

You say you have experience with scripting and yet you don't understand the basic definitions of COM and do not understand how and where to find answers to your questions.

You ask about McAfee private interfaces yet get angry when you discover that there are no easy answers to your question.

COM and scripting do not guarantee that you will get easy answers.  Most of us who have used scripting and COM along with the many different object browsers understand that the question/complaint that you pose is simplistic.  You ask it because you do not understand what COM is.

No reasonably sophisticated technology can be explained in a trivial or simple fashion.

Like so many young people today you expect the answers to be dished out easily.  You want everything to be just so.  An object browser should give you all of the answers.  If I or anyone else should point to the facts about 'object browser' you become incensed.  How dare we suggest that you do not know what you are complaining about!

Stop and listen.  Assume for a minute that you are wrong and that that can be remedied by just learning one or two simple things.

The object browser was built to support COM when it was first created.  COM initially only worked with C and C++.  It was nt designed for use with shell scripting languages.  The object browser was designed to allow a programmer to browse the interfaces, methods and properties of COM classes. It was never intended to be a method for documenting COM classes.

The Windows Platform SDK (originally Windows SDK) was where we would find the documentation for most COM classes.  The original COM was simply called OLE which grew out of DDE.  It was designed as an extension to CORBA (IBM).

http://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture

COM is described here in a nutshell.

http://en.wikipedia.org/wiki/Component_Object_Model

If, as you have stated, you have years of experience scripting you would know this.  You would also know that the object browser - which one - is not what you want it to be because scripting dŒs not have an object browser. 

An object browser is included with Office VBA and a different one is included with the Platform SDK and another one is included with Visual Studio. Some object browsers display the comments and help embedded in the objects and some don't.

You would also understand that some objects are callable from late bound languages and some are not and that there is no easy way to determine this from any object browser.  It is mostly a function the design of the object.

So a little basic programming will help you to understand some of my argument.  Sit back and be prepared to learn something real:

http://support.microsoft.com/kb/245115

Now do you understand why some of your issues are nebulous?

Most object browsers do not display this information directly.  The object browser from the SDK displays this in a roundabout way and requires that you understand COM and the difference between early bound and late bound languages. There is NO little flag that says "this is how to use this in VBScript".  You need to know what scripting requires.

For some documentation like WMI there is documentation of the iDispatch interfaces under the heading of WMI scripting technologies.  This is a result of the WMI team€™s desire to publish this capability.  Some products are documented and others are not. 

Scripting is not intended as a programming language, per se. It is intended as simple access to the OS and programs for maintenance purposes.  It derives from other OS implementations. It is intended to be used by maintenance professionals who understand the areas of the OS or programs that they need to script to. 

There is nothing wrong with the 'Object Browser' because there is not just one object browser.  NO object browser dŒs exactly what you want but a complete understanding of scripting would help you to better use any object browser and the OB in the SDK could help you to determine the readiness of an object for scripting.  (No object browser will be perfect as only the designer of the object can easily tell you how it works.  An object can be very complex. No object browser can describe how to use it.  Excel is a great example.)

Microsoft has addressed some of these issues in two major ways. 

!. The 'Net Framework' which is a major rethink of COM.DCOM/COM+. 

2. Placing all fundamental documentation on the Internet and linking it directly to the API ( as of PowerShell 1.0 which has 'help -online')

The other major fortune here is that MS is trying to reduce the technical requirements for using a scripting language. PowerShell can be used in place of the old DOS-like command prompt.  It is a replacement for CMD.EXE.  PowerShell requires almost no new knowledge to use it 'at the prompt'.

PowerShell is discoverable?  It has an advanced help system and it can browse objects and Net framework classes 'at the prompt'. It allows us to 'read' the methods and properties of the classes to a much deeper level than traditional COM and is a better object browser than most object browsers included in other products.  It still dŒs not include all you would like.  There is still a requirement that you "look things up" and learn a product from its vendor.

In PowerShell we can "browse" Excel.

$xl New-Object -com Excel;.Application

$xl|get-member|select name,membertype

This will return a list of all properties and methods.

We can inspect a method"

04:21 PS>$xl.Workbooks.Add

MemberType          : Method
OverloadDefinitions : {Workbook Add (Variant)}
TypeNameOfValue     : System.Management.Automation.PSMethod
Value               : Workbook Add (Variant)
Name                : Add
IsInstance          : True

But it is still COM so the information is limited.

So put on your hat and start learning scripting technologies.  Once you master the basics you can do wonders and not feel confused anymore.

It is not too late to learn and you are never too old or too young. 

Stop complaining and join into the fun.  The new scripting is much better than that old DOS stuff we used to do.

If you want a better COM browser try the Platform SDK or the PrimalScript object browser. You might even like using the PowerShell implementation of Intellisense and 'object reflection'.

There are also a number of good books on COM that might help you to understand what it is and how to use it in most environments.  You can even get it on your Kindle.

http://www.amazon.com/gp/product/B005011IR8/ref=pd_lpo_k2_dp_sr_2?pf_rd_p=486539851&pf_rd_s=lpo-top-stripe-1&pf_rd_t=201&pf_rd_i=186100060X&pf_rd_m=ATVPDKIKX0DER&pf_rd_r=0QZEFZMJWE6YQKMBWWG8

Good Luck.  I hope you can find some new information here.