>>>Just a thought.. have you tryed using shorter name for those?
>>
>>Thank you for the idea, Marco, but the behavior persists.
>>
>>I took the opportunity to explicitly set the 5th element of the COMATTRIB array, which is only meaningful in case of methods, but nevertheless the "debugger" (?) keeps treating the method as a property...
>
>In some COM objects I've seen little difference between properties and methods - because any property is actually two methods, a setter and a getter. So if your methods were pushed out by setting them as protected, then the COM interface could (with aid of debugger, which has its own ways of trying to extract PEMs from COM objects, and then intellisense can do a few things even debugger can't), it might have concluded that these were of that kind, so considered them properties.
>
>Not quite sure we could call this a bug, but it's surely an unintended result.

Thank you, Dragan. Since I don't understand what is going on, I won't call it a bug, also.

These methods are the public ones, they are not restricted in any form, and Intellisense has full knowledge of their nature, and how to invoke them - see the attached images for examples of plain vanilla command line instantiations of the class.

But you made me look into the Debugger behavior with other COM servers. I instantiated a MSXML2 DOMDocument object, and observed that some methods get listed as properties, while others won't. For instance, after being called for a first time, setProperty goes into the locals list, but Load won't. Incidentally, the "on" events (onreadystatechange and so on) are immediately listed as properties upon the instantiation.

Went back to my COM server, and noticed also that at least one of the public methods does not get listed.

I will keep my eyes opened on this, and trying to figure out what may explain the Debugger behavior. Any ideas on where to look, or on what to try, will be much appreciated.