I am looking for "typical" way one navigates MSDN to get a COM class to do what they want.
Example problem: I am looking for an API way to unblock a local file (remove internet zone/mark of the web from a file programmatically).
I found one post on stackoverflow.com that talked about clsid_persistentzoneidentifier. so i searched in MSDN and got to http://msdn.microsoft.com/en-us/library/ms537029(VS.85).aspx. What I am looking for,is what one does after they get to this url. From this location, I am not able to figure what the sequence of operations should be. How do I connect this IZoneIdentifier to IPersistFile? etc. There must be something basic that I am missing wrt COM related documentation. MSDN has interfaces and objects, but nothing that helps me visualize a "sequence" diagram of sorts. Nothing that will get me to understand which COM objects are from same class. hence can/or should be QueryInterfaced, adn which should be CoCreated.
The documentation for that indicates a few things.
The first is that you can call CoCreateInstance, passing CLSID_PersistentZoneIdentifier to get an implementation of these two interfaces:
IPersistFile
IZoneIdentifier
It also says:
Use IPersistFile to attach the object
to the target file and IZoneIdentifier
to examine or to manipulate the zone
ID.
That being said, you can look at the documentation for IPersistFile here:
http://msdn.microsoft.com/en-us/library/ms687223(VS.85).aspx
It shows that there is a Load method, which is what you want to call with the filename to load the implementation with details about the file.
From there, you can call QueryInterface on the IUnknown interface implementation to get the IZoneIdentifier interface and then call the Remove method on it to set the zone to the local machine.
For that purpose, if it's not obvious from the documentation, I like to find sample programs in which relevent APIs are used: either using Google, or perhaps from whichever of the Microsoft SDKs is relevent.
Microsoft SDKs, for example this one, include sample programs.
Related
Two simple COM IDL file questions I can't seem to find answers for, even with searching MSDN and the general internet:
Is there an interface attribute which lets me specify my interface is to be implemented by STA objects only, or is this a detail for my documentation alone? I already have [object, local] which I think is correct for non-remoting (in-process) COM objects.
Do I need void in the parentheses of my method declarations (like in C) to specify no arguments? MSDN is inconsistent about this; so are header files. My own personal implementations of this interface will be in C.
Thanks.
You are talking about the threading model you want to specify for your COM component. No, you cannot put that in the IDL, it is far too important. A client doesn't have to use your IDL, a scripting language like Javascript never will for example. It must go in the registry, in the CLSID key for your component. You want ThreadingModel = "Apartment" to request the client to provide an STA thread. If it is missing then COM assumes that by default.
Do keep in mind that this does not force the client programmer to provide one. If he favors MTA for some reason then COM will provide the STA thread to give your component as safe home. If your proxy makes it too slow to be usable then you do have a documentation requirement.
No HRESULT Method(void) in the IDL is not necessary, using HRESULT Method() is sufficient. Midl.exe doesn't care what language you use.
I wanted to create a few macros for LibreOffice using BASIC. However I cannot find the API description. It is absent in help as well as in interet. When I try to google it I get masses of examples in C++, Java, Python, but not a single www with BASIC.
For example where from can I get the hierarchy of objects and their methods?
LibreOffice Basic uses essentially the same API as PyUNO and Java. That is, they all use the UNO API. To get started, the OpenOffice development guide helpfully describes the two main ways to step into the object hierarchy, the Global variables ThisComponent and, less commonly, StarDesktop. There also is a specialty variant in LO Base, ThisDatabaseDocument. To get the properties and methods of these objects, execute MsgBox oObject.DBG_properties or .DBG_methods. It often is easier to copy the longer lists that are returned by this method into a text editor for searching. You will find that all, or nearly all, of the methods and properties you reveal will be described in the LibreOffice UNO IDL API. The documentation for the API is not that descriptive, but you will be able to fill in some essential details using that resource Every Object has properties that can be reviewed by .DBG_properties.
The key properties for navigating the object hierarchy are .Parent, .Model, .CurrentController and occasionally .Source. The key methods are getByName() and getByIndex(). It also is helpful that events which trigger macros typically return an event object whose source or parent is the object that initiated the macro, for example, a command button. This object can be accessed by referring to it along with the Sub, i.e., Sub SubName (oEventObject As Variant)....
I was convinced that there is no way to find COM dependencies of an ActiveX but to my surprise OLEVIEW shows some comments Like:
// TLib : // TLib : OLE Automation : {00020430-0000-0000-C000-000000000046}
importlib("stdole2.tlb");
// TLib : Visual Basic runtime objects and procedures : {EA544A21-C82D-11D1-A3E4-00A0C90AEA82}
importlib("3");
I tried to extract the same information using TypeLibInfoFromFile but based on what I find in MSDN, there is no Api that provides this information. Are you aware of a method to extract this information from OCX or it's Tlb file? Knowing that all my ocxes are compiled with vb6 can I trust this informaion for Imported(Explicitly not in code) interfaces?
Well, I've found the answer to this question. I'll write it here just in case someone would search for the same question. It's possible to find some of dependencies but you can never be sure if you have found them all. Basically you must enumerate every type and interface, and every member of each type to find all types in the module and for every type you find you should check to see if it's in an external TypeLib. in the end you have a List of Typelibs referenced.
The problem with this method lays in the fact you find only the types that are used in the public interface (fields, return values and parameters) and you miss every local object or dynamically created ones. That said you can check this link for an implementation or better yet this one.
I want to call an ActiveX DLL or OLE2 object from ABAP.
I already know the syntax of how to instantiate the object & execute the methods:
data: my_object type ole2_object.
create object my_object <ole2object>.
call method of my_object <objectmethod>.
But given a particular application, how do I know if this is supported, what the values/names of ole2object and objectmethod is?
Transaction SOLE supplies a table of OLE Applications, among this is Excel.Application which I know can be instantiated as an OLE object, so it looks like you have to add the OLE2 app to this table first, but once again where can I read the data like CLSID & LibType from - is it published as part of the application?
Objects are coming from the table TOLE. Their methods and propeties are stored into table OLELOAD.
I found some time ago somes documents (this one and this one) that contained indications of how you can find the properties and methods.
Indication on the CLSID are succint, but it seems to be the value in the register with HKEY_CLASS_ROOt/CLSID that goes with the application indicated (ie VISIO.APPLICATION for exemple). If you search this application value with regedit, you'll find the corresponding CLSID.
Hope it's helping
Guillaume
In this case, you're simply using OLE2 to access a COM interface. If you're into accessing Office applications, you might want to take a look at KB222101. For other applications and libraries, you'll need the API documentation, some suitable examples (not necessarily in ABAP, VB will do just fine). a pointed stick to poke the developer with or all three of them...
Oh, and there's a tool called OLE/COM Object Explorer by MiTeC that can be downloaded for free from their website. Haven't used it myself, but it looks like it might be helpful.
To implement "method-missing"-semantics and such in C# 4.0, you have to implement IDynamicObject:
public interface IDynamicObject
{
MetaObject GetMetaObject(Expression parameter);
}
As far as I can figure out IDynamicObject is actually part of the DLR, so it is not new. But I have not been able to find much documentation on it.
There are some very simple example implementations out there (f.x. here and here), but could anyone point me to more complete implementations or some real documentation?
Especially, how exactly are you supposed to handle the "parameter"-parameter?
The short answer is that the MetaObject is what's responsible for actually generating the code that will be run at the call site. The mechanism that it uses for this is LINQ expression trees, which have been enhanced in the DLR. So instead of starting with an object, it starts with an expression that represents the object, and ultimately it's going to need to return an expression tree that describes the action to be taken.
When playing with this, please remember that the version of System.Core in the CTP was taken from a snapshot at the end of August. It doesn't correspond very cleanly to any particular beta of IronPython. A number of changes have been made to the DLR since then.
Also, for compatibility with the CLR v2 System.Core, releases of IronPython starting with either beta 4 or beta 5 now rename everything in that's in the System namespace to be in the Microsoft namespace instead.
If you want an end to end sample including source code, resulting in a dynamic object that stores value for arbitrary properties in a Dictionary then my post "A first look at Duck Typing in C# 4.0" could be right for you. I wrote that post to show how dynamic object can be cast to statically typed interfaces. It has a complete working implementation of a Duck that is a IDynamicObject and may acts like a IQuack.
If you need more information contact me on my blog and I will help you along, as good as I can.
I just blogged about how to do this here:
http://mikehadlow.blogspot.com/2008/10/dynamic-dispatch-in-c-40.html
Here is what I have figured out so far:
The Dynamic Language Runtime is currently maintained as part of the IronPython project. So that is the best place to go for information.
The easiest way to implement a class supporting IDynamicObject seems to be to derive from Microsoft.Scripting.Actions.Dynamic and override the relevant methods, for instance the Call-method to implement function call semantics. It looks like Microsoft.Scripting.Actions.Dynamic hasn't been included in the CTP, but the one from IronPython 2.0 looks like it will work.
I am still unclear on the exact meaning of the "parameter"-parameter, but it seems to provide context for the binding of the dynamic-object.
This presentation also provides a lot of information about the DLR:
Deep Dive: Dynamic Languages in Microsoft .NET by Jim Hugunin.