Closing an editor with a PDF ActiveX control [message #453441] |
Tue, 05 April 2005 16:03 |
Adriaan Thomas Messages: 5 Registered: July 2009 |
Junior Member |
|
|
Hello,
When I use an Adobe Acrobat Reader ActiveX in an editor in an RCP
application, closing the editor takes a long time (at the very least least
10 seconds on my machine) and the CPU goes to 100% for javaw.exe.
The strange thing is that when I use equivalent code in a non-RCP
application, everything works fine; the tab closes instantly.
I tried this on Eclipse 3.0.2 and 3.1M6. My OS is Windows XP.
Has anyone seen this before? Am I doing something wrong?
Here is the main code from the editor.
public class PdfViewer extends EditorPart {
private OleControlSite site;
private OleAutomation automation;
public PdfViewer() {
}
public void init(IEditorSite site, IEditorInput input)
throws PartInitException {
setSite(site);
if (!(input instanceof PdfEditorInput)) {
throw new PartInitException("Input is not a PdfEditorInput.");
}
setInput(input);
setPartName(input.getName());
}
public void createPartControl(Composite parent) {
OleFrame frame = new OleFrame(parent, SWT.NULL);
// use Shell.Explorer because since Acrobat Reader 7 this seems to
be the only way...
site = new OleControlSite(frame, SWT.NULL, "Shell.Explorer");
automation = new OleAutomation(site);
int res = site.doVerb(OLE.OLEIVERB_INPLACEACTIVATE);
if (res != OLE.S_OK) {
System.err.println("Error showing pdf control: " + res);
OLE.error(OLE.ERROR_APPLICATION_NOT_FOUND);
}
loadFile(((PdfEditorInput) getEditorInput()).getFile()
.getAbsolutePath());
}
private void loadFile(String fileName) {
int[] rgdispid = automation.getIDsOfNames(new String[] { "Navigate",
"URL" });
if ((rgdispid == null) || (rgdispid.length < 1)) {
OLE.error(OLE.ERROR_ACTION_NOT_PERFORMED);
}
int dispIdMember = rgdispid[0];
Variant[] rgvarg = new Variant[1];
rgvarg[0] = new Variant(fileName);
automation.invoke(dispIdMember, rgvarg);
}
public void dispose() {
automation.dispose();
automation = null;
super.dispose();
}
// other methods omitted here
}
Note that I am using "Shell.Explorer" as the ProgID, as since Acrobat Reader
7, SWT's call to OleCreate returns REGDB_E_CLASSNOTREG (0x80040154) (for
ProgID "AcroPDF.PDF"). This seems strange since the CLSID is correct.
However, this does not seem to impact performance; closing a viewer with an
Acrobat Reader 6 (without using IE) is just as slow.
I think it might be a threading problem, because when I put a breakpoint on
org.eclipse.ui.internal.PartPane.dispose() (the line with control.dispose())
and wait a short while, everything works fine too.
|
|
|
Re: Closing an editor with a PDF ActiveX control [message #453442 is a reply to message #453441] |
Tue, 05 April 2005 17:31 |
Veronika Irvine Messages: 1272 Registered: July 2009 |
Senior Member |
|
|
Sounds similar to bug 56184. You should add your comments there.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=56184
"Adriaan Thomas" <Aad7144@hotmail.com> wrote in message
news:d2ud3c$fdu$1@news.eclipse.org...
> Hello,
>
> When I use an Adobe Acrobat Reader ActiveX in an editor in an RCP
> application, closing the editor takes a long time (at the very least least
> 10 seconds on my machine) and the CPU goes to 100% for javaw.exe.
>
> The strange thing is that when I use equivalent code in a non-RCP
> application, everything works fine; the tab closes instantly.
>
> I tried this on Eclipse 3.0.2 and 3.1M6. My OS is Windows XP.
>
> Has anyone seen this before? Am I doing something wrong?
>
> Here is the main code from the editor.
>
> public class PdfViewer extends EditorPart {
> private OleControlSite site;
> private OleAutomation automation;
>
> public PdfViewer() {
> }
>
> public void init(IEditorSite site, IEditorInput input)
> throws PartInitException {
> setSite(site);
> if (!(input instanceof PdfEditorInput)) {
> throw new PartInitException("Input is not a PdfEditorInput.");
> }
> setInput(input);
> setPartName(input.getName());
> }
>
> public void createPartControl(Composite parent) {
> OleFrame frame = new OleFrame(parent, SWT.NULL);
>
> // use Shell.Explorer because since Acrobat Reader 7 this seems to
> be the only way...
> site = new OleControlSite(frame, SWT.NULL, "Shell.Explorer");
>
> automation = new OleAutomation(site);
>
> int res = site.doVerb(OLE.OLEIVERB_INPLACEACTIVATE);
> if (res != OLE.S_OK) {
> System.err.println("Error showing pdf control: " + res);
> OLE.error(OLE.ERROR_APPLICATION_NOT_FOUND);
> }
>
> loadFile(((PdfEditorInput) getEditorInput()).getFile()
> .getAbsolutePath());
> }
>
> private void loadFile(String fileName) {
> int[] rgdispid = automation.getIDsOfNames(new String[] {
> "Navigate",
> "URL" });
> if ((rgdispid == null) || (rgdispid.length < 1)) {
> OLE.error(OLE.ERROR_ACTION_NOT_PERFORMED);
> }
> int dispIdMember = rgdispid[0];
> Variant[] rgvarg = new Variant[1];
> rgvarg[0] = new Variant(fileName);
> automation.invoke(dispIdMember, rgvarg);
> }
>
> public void dispose() {
> automation.dispose();
> automation = null;
> super.dispose();
> }
>
> // other methods omitted here
> }
>
> Note that I am using "Shell.Explorer" as the ProgID, as since Acrobat
> Reader
> 7, SWT's call to OleCreate returns REGDB_E_CLASSNOTREG (0x80040154) (for
> ProgID "AcroPDF.PDF"). This seems strange since the CLSID is correct.
> However, this does not seem to impact performance; closing a viewer with
> an
> Acrobat Reader 6 (without using IE) is just as slow.
>
> I think it might be a threading problem, because when I put a breakpoint
> on
> org.eclipse.ui.internal.PartPane.dispose() (the line with
> control.dispose())
> and wait a short while, everything works fine too.
>
>
|
|
|
Re: Closing an editor with a PDF ActiveX control [message #453518 is a reply to message #453441] |
Wed, 06 April 2005 22:20 |
Eclipse User |
|
|
|
Originally posted by: kghuynh.gmail.com
I found a work around for this is to first set your IE browser to
"about:blank". Add an ProgressListener and close the browser in the
completed event. You must wait after the "about:blank" has been loaded
before closing the browser...
|
|
|
Powered by
FUDForum. Page generated in 0.03252 seconds