|
4m
楼主 |
发表于 2011-1-6 04:29:30
|
只看该作者
本帖最后由 panhao1 于 2011-1-6 04:30 编辑
那么 还有其他方法链接上excel么 ?
官网上说有9个
PIA Interop
Using the Office PIAs is the most RAD approach, with the greatest level of design-time and compile-time support. This has to be the preferred approach for almost all scenarios. A variation of this is the use of embedded PIA types using ComImport, as described here and here.
Process.Start (百试不爽的方法)
The simplest fire-and-forget approach, useful if you want to launch any executable but don’t need to interact with the app’s OM afterwards.
Activator.CreateInstance
Internally, this uses reflection to find and execute an appropriate constructor for the specified object. This can be slow, but useful if you intend to continue using reflection to work with the app – which you might do if you want to eliminate use of the PIAs altogether.
Marshal.BindToMoniker
Internally, this p/invokes to the Win32 BindToMoniker API. Useful if you have a narrow interest in the app’s exposed object that deals with a particular file type. In other words, if you want to work with a particular doc/workbook/presentation/etc using only a limited subset of the OM.
Marshal.GetActiveObject
Internally, p/invokes to the Win32 GetActiveObject. This will throw an exception if the object’s server is not already running, as it looks up the target ProgID in the ROT. One of the classic uses of this API is to determine whether or not the target app is already running.
VisualBasic.CreateObject
A compatibility API, which internally calls Activator.CreateInstance.
VisualBasic.GetObject
A compatibility API, which internally calls either Activator.CreateInstance or Marshal.BindToMoniker. In other words, it will connect to an already-running instance of the app if it finds one, otherwise it will create a new instance.
ActivateMicrosoftApp
This is a method exposed from the Excel Application object (and only the Excel Application object), used for activating or starting other Office apps (specifically, Access, FoxPro, Outlook, PowerPoint, Project, or Word). This approach does not give you access to the target app’s OM, so its effect is very similar to Process.Start.
AccessibleObjectFromWindow
Given the HWND for the target app (which you can find using FindWindowEx), this gets you access to the app’s OM. This is useful if your starting point is an HWND, or if you’re specifically focused on the app’s IAccessible implementation, and only minimally interested in the rest of the OM. |
|