Community
Participate
Working Groups
Neither OleControlSite nor OleClientSite give capability to create simple OLE object that doesn't have visual representation.
Created attachment 12661 [details] OleObjectSite.java Attached file (OleObjectSite.java) successfully creates those OLE components.
I would be nice to have a COM Automation class that does not require UI stuff like the 'Composite parent, int style" in the example given. Perhaps this stuff could be refactor to allow this?
What I really need is: new OleAutomation("SomeProgId")
*** Bug 75352 has been marked as a duplicate of this bug. ***
Created attachment 54838 [details] Possible solution for this problem This is a patch to allow you to do OleAutomation(progID), so you don't have to have a composite attached to your com object.
Would it be possible to have Ken's patch merged in for 3.3? It works beautifully for me.
Works great for me too. Would be great if it was in 3.3
Can someone provide me with a sample piece of code to test Ken's code to show that it works? What's a valid "ProgId" that I can specify on a default Windows install? I tried "Msxml" as someone suggested but it doesn't appear to work.
This works for me: OleAutomation auto = new OleAutomation("InternetExplorer.Application"); int[] ids = auto.getIDsOfNames(new String[] { "visible" }); auto.setProperty(ids[0], new Variant(true)); ids = auto.getIDsOfNames(new String[] { "navigate" }); auto.invoke(ids[0], new Variant[] { new Variant("http://www.eclipse.org") });
The patch works for me fine. Just curious to know when this patch will be a part of a release for org.eclipse.swt.ole.win32.OleAutomation.java. My project is dependent on this fix, so please tel me in which release of org.eclipse.swt... i can aspect these changes.
(In reply to comment #10) > The patch works for me fine. > Just curious to know when this patch will be a part of a release for > org.eclipse.swt.ole.win32.OleAutomation.java. > My project is dependent on this fix, so please tel me in which release of > org.eclipse.swt... i can aspect these changes. I was assigned all OLE problems just 2 days ago. Unfortunately, we are already past API freeze, so it will be very hard to get new APIs in for Eclipse 3.5. Also, SWT is a toolkit to build UI, writting a java wrap for ole is not our business (see Bug 256749). Once any support is in we will have to support it for ever. I suspect that is the reason we never fixed this problem. That said, I see several people are interested in this bug. I'll talk to my manager about it.
I have a dependancy on this fix and as per the response that i got from the developer I need to wait untill this fix is released. isn't there any other option that i can use. If i ask user to use this patch also , so that my project could work fine then what is the procedure to install a patch like this.
can someone guide me on how to make use of this kind of patch. My project depends on this fix, so do I need to ask user to use this patch as a fix as well.
Created attachment 143762 [details] this file have the changes which we require to get a safearray of IDispatch interface from OLE.
Created attachment 143763 [details] this file have the changes in OLEVariant.java file which we require to get a safearray of IDispatch interface from OLE. I have attached two files. variant.java OLEAutomation.java These files now have the changes that is require for the support of returning or passing a safearray of IDispatch interfaces.
see Bug 93652 for VT_ARRAY support in Variant. The best fix for this problem still is one proposed by Ken Guy in 2006.
Created attachment 144248 [details] new patch This patch adds the same constructor suggest in comment #5 fixing some problems in the original fix: 1) calls OleInitialize() / OleUninitialize 2) Doesn't leak IUnknown 3) Doesn't leak ITypeInfo (see Bug 120192)
*** Bug 38352 has been marked as a duplicate of this bug. ***
Fixed in HEAD > 20090812 I slightly changed the patch to make sure OleUninitialize() gets called in all cases.
*** Bug 120792 has been marked as a duplicate of this bug. ***
