Comment 1 Krzysztof Kazmierczyk 2010-04-29 08:54:30 EDT

Created attachment 166470 [details]
error_screen

I am attaching error window.

Comment 2 Krzysztof Kazmierczyk 2010-05-04 11:09:30 EDT

The error is caused by line
Variant varResult = invoke(activeDocument, "SaveAs", workingCopy); //$NON-NLS-1$
in WordComparision.createWorkingCopy(baseDocument, revisedDocument, workingCopy)

Comment 3 Krzysztof Kazmierczyk 2010-05-06 11:08:39 EDT

Created attachment 167317 [details]
compare with return

I discovered, that the reason of the issue is that method getActiveDocument returns object which probably is not a document. You get always an error you try e.g. get any property from the document (Invalid property name: "ReadOnly"). 

I am also a little surprised how Word API works. After reading Compare method API: http://msdn.microsoft.com/en-us/library/bb221489.aspx. The method Document.Compare should return the document containing differences between documents. I tried to replace the method compareDocument in the class WordComparison (see the patch), but now I get always the error in WordComparison:209: org.eclipse.swt.SWTException: Failed to change Variant type result = -1.

Do I make something wrong or it seems to be Word API issue?

Comment 4 Krzysztof Kazmierczyk 2010-06-01 04:46:02 EDT

Created attachment 170617 [details]
variables values

The cause of this error is that OleAutomation#getIDsOfNames method results in error number -2146771167 (0x800adf21) which stands for VBA_E_CANTEXITDESIGNMODE (see  http://www.lifeasbob.com/Code/ErrorCodes.aspx)

Comment 5 Krzysztof Kazmierczyk 2010-06-01 04:47:19 EDT

Created attachment 170618 [details]
stacktrace

Stacktrace when the the error mentioned in previous comment happens

Comment 6 Krzysztof Kazmierczyk 2010-06-01 09:52:06 EDT

Created attachment 170636 [details]
testing project

for "Can't Exit Design Mode..." error
http://support.microsoft.com/kb/212559 finds following method:
Open your Normal.dot template, access the control, and then save and close the Normal.dot template.

and it exactly works. When I open normal.dot file (using OLE methods) I am able to save compared document. The problem is that we must know exactly the path to normal.dot file (for me is is e.g. C:\Documents and Settings\Administrator\Application Data\Microsoft\Templates\Normal.dot).

Instead of that I found the workaround which search ole method by id not using method auto.getIDsOfNames but iterating over ids to find id of method with given name (see findMethodId in the project).

Is this workaround acceptable or I should use the method from microsoft page with "guessing" where Normal.dot file is located?

Comment 7 Krzysztof Kazmierczyk 2010-06-01 11:19:00 EDT

Created attachment 170644 [details]
patch with my workaround

Here is the patch with the workaround mentioned in the previous comment. 
Szymon, what do you think about this patch? Is it OK or I should try to use the method from Microsoft web page?

Comment 8 Szymon Brandys 2010-06-09 12:08:20 EDT

The fix is a hack, however I can't see any other way to handle this problem. Krzysztof, since this issue seems to be a Microsoft product problem, maybe we should just mark it as NOT_ECLIPSE?

Comment 9 Krzysztof Kazmierczyk 2010-06-15 03:46:49 EDT

After talk with Szymon we decided not to mark it as NOT_ECLIPSE, because Microsoft provides workaround for this bug (http://support.microsoft.com/kb/212559) which we can try to use.

Now I am going to prepare patch which uses workaround provided by Microsoft.

Comment 10 Krzysztof Kazmierczyk 2010-06-15 08:11:35 EDT

Created attachment 171915 [details]
not working patch

I have tried to deliver the patch based on workaround from http://support.microsoft.com/kb/212559 The patch seems to properly implement the workaround but does not work. Attaching patch for reference.

Comment 11 Krzysztof Kazmierczyk 2010-06-18 06:14:44 EDT

Created attachment 172204 [details]
my attempts to open word application in swt

After talk with Szymon, we decided to try two workarounds:

1. Open Word application in editor Window without saving file created after comparing two files but only display it

2. Display file created after comparing two files in external MS Word window.

I have tried to implement first workaround but it seems it is technically impossible in Eclipse (see my attempt in attachement). Felipe, do you know if it is possible to open word application, not only word document in SWT composite?

Attaching file with my attempts.

Comment 12 Krzysztof Kazmierczyk 2010-06-18 06:18:02 EDT

Created attachment 172207 [details]
open in external Word editor

Attaching patch opening compared file in external MS Word window. The patch is ot final version but only working copy to present how opening files in external editor visually look.

Comment 13 Felipe Heidrich 2010-06-18 09:16:37 EDT

(In reply to comment #11)
Felipe, do you know if
> it is possible to open word application, not only word document in SWT
> composite?

See org.eclipse.swt.program.Program

Comment 14 Krzysztof Kazmierczyk 2010-06-21 10:01:41 EDT

(In reply to comment #13)
> See org.eclipse.swt.program.Program

Felipe, org.eclipse.swt.program.Program allows only us to open external application using SWT code, but it doesn't place it in any composite, am I right?


The reason that every word document opens in external window, not Eclipse window is that documents in MS Word open also in external, not modal windows.
I don't see any option to swithc to modal mode in the documentation (http://msdn.microsoft.com/en-us/library/bb257679.aspx).

Felippe do you have any idea if we could open not saved document in SWT composite?

Comment 15 Felipe Heidrich 2010-06-21 10:46:45 EDT

(In reply to comment #14)
> (In reply to comment #13)
> > See org.eclipse.swt.program.Program
> Felipe, org.eclipse.swt.program.Program allows only us to open external
> application using SWT code, but it doesn't place it in any composite, am I
> right?

Correct. You said 'external MS Word window', that is why I suggested the Program class.

> Felippe do you have any idea if we could open not saved document in SWT
> composite?

Using Ole automation you mean ?

Comment 16 Krzysztof Kazmierczyk 2010-06-21 11:08:51 EDT

(In reply to comment #15)
> Correct. You said 'external MS Word window', that is why I suggested the
> Program class.

Sorry my mistake :)

> 
> > Felipe do you have any idea if we could open not saved document in SWT
> > composite?
> 
> Using Ole automation you mean ?

Yes, I mean using Ole automation. I would like to perform exactly following steps using Ole automation:
1. OleAutomation oleapplication = new OleAutomation()
2. OleAutomation first = oleapplication.open("a.doc")
3. first.compare("b.doc")
4. OleAutomation activeDocument = oleapplication.getActiveDocument()

Is there any wat to open activeDocument in composite now?

Comment 17 Felipe Heidrich 2010-06-22 09:05:43 EDT

(In reply to comment #16)
> Is there any wat to open activeDocument in composite now?

I don't think so. Are you sure it will help ?
it seems backwards to me, usually one starts with a ole client site (which is already embed in a composite), from there it gets ole automation is executes the needed operations. 


Anywho, see OleClientSite#OleCreate, it shows a couple different way to load a file into a ole object. Note that the file doesn't have to exist in the file system, it can be in memory.

Comment 18 Szymon Brandys 2010-07-12 12:15:47 EDT

Krzysztof, please provide some estimates when the fix or a proposal may be ready.

Comment 19 Krzysztof Daniel 2010-07-13 10:57:23 EDT

I have spent some time investigating moving the active document to the existing shell. 
The workflow right now is like this:
1. Create a compare document
2. Store it to the temp file, and close the original application
3. Open it (inplace or standalone, user decides)

Expected workflow is:
1. Create a compare document
2. Display it inplace or as standalone application

We are trying to do that, because Word OLE 'SaveAs' method is not working as expected. This means that once we generate a comparison, we must find a way of passing it to inplace editor or the separate word application. Since we cannot use filesystem, we must rely on clipboard, which is in my opinion unacceptable, because no application should modify the clipboard.

Comment 16 says that we have an ActiveDocument which we want to open in the Word inside the SWT Composite. An ActiveDocument is actually a part of Word, and we cannot transfer it. A document (file) becomes an ActiveDocument after it is opened from Word. We will not get the file (because of the bug). It means that we have to compute the diff each time when the user switches inplace<->standalone mode. Word will also prompt for save on each window close (because we have actually made some modifications).

I believe that the lack of communication between standalone and inplace words (they are actually different OLE apps) is a no-go for approach described in comment 16.

It is also +1 for patch in the attachement 170644 given that 
Short.MAX_VALUE from line 108 will be replaced with something more reasonable.

Comment 20 Szymon Brandys 2010-07-13 11:23:29 EDT

(In reply to comment #19)
> It is also +1 for patch in the attachement 170644 given that
> Short.MAX_VALUE from line 108 will be replaced with something more reasonable.

There is always a chance that we won't find the 'SaveAs' method. What should we do then? With this fix we will just make the gap smaller,
but the issue still may occur.

Comment 21 Krzysztof Daniel 2010-07-13 12:10:58 EDT

(In reply to comment #20)
> (In reply to comment #19)
> > It is also +1 for patch in the attachement 170644 given that
> > Short.MAX_VALUE from line 108 will be replaced with something more reasonable.
> 
> There is always a chance that we won't find the 'SaveAs' method. What should we
> do then? With this fix we will just make the gap smaller,
> but the issue still may occur.

I would expect that instead of checking Short.MAX_VALUE properties, we will iterate over all accessible properties. Maybe there is a possibility of getting the total amount of properties present in the OLE Automation. On the other hand, SaveAs seems to have always the same id, maybe it is a part of specification.
If Short.MAX_VALUE cannot be replaced, then it is also no go for this patch.

If somehow 'SaveAs' will be still missing after that workaround, then we should throw an exception as it is right now. 

I'd not say that we try to reduce a gap, we have a concrete Microsoft bug which we are trying to workaround. If we want be prepared for the situation where the 'SaveAs' is totally missing, we should also be prepared for any other method absence.  Changing the integration approach wont help a lot here.

Comment 22 Krzysztof Daniel 2010-07-16 07:22:04 EDT

Created attachment 174480 [details]
Fix proposition

Tries to workaround missing SaveAs method. Also some additional guard to OLE creation added.

Comment 23 Szymon Brandys 2010-07-26 09:25:14 EDT

Krzysztof, while testing your patch I found another issue. Each compare starts a new WINWORD process which is not killed when the editor or Eclipse is closed. If you see the same problem, could you raise a but for that and investigate?

Comment 24 Krzysztof Daniel 2010-07-26 11:11:15 EDT

I think it is time to mark this as WONTFIX, because:
1. It is definitely MS WORD problem, as opening the doc with standalone WORD also fails
2. Fixing one issue reveals new one, like:
  * workarounding missing saveAs may cause exception during ole creation
  * catching the exception causes new WORD process to be created

Comment 25 Krzysztof Kazmierczyk 2010-07-26 13:47:28 EDT

Krzysztof, WINWORD process has been opening each time you open new document - no matter if opened successfully or with the errors. Szymon's concern is that this process is not killed when you close Eclipse. The fix does not create the issue as it exists also without it.

Comment 26 Szymon Brandys 2010-07-27 05:28:27 EDT

(In reply to comment #25)
> Krzysztof, WINWORD process has been opening each time you open new document -
> no matter if opened successfully or with the errors. Szymon's concern is that
> this process is not killed when you close Eclipse. The fix does not create the
> issue as it exists also without it.

Right, the "multiple WINWORD processes" issue is not related to the fix. It happens even without the fix. I asked Krzysztof K. to raise a separate bug for that.

Going to the fix. Tomasz Z. checked it on two Win machines and it worked fine. There is something different with my Word configuration what causes problems. One difference I could observe is that I can see the "Enable/Disable" dialog while trying to compare 1.3 and 1.4.

Comment 27 Krzysztof Kazmierczyk 2010-07-27 05:48:17 EDT

Szymon, are you going to test the fix also on different documents?

Comment 28 Krzysztof Kazmierczyk 2010-07-27 07:56:20 EDT

Szymon having the same issue. I have created bug 321000 for that.

(In reply to comment #23)
> Krzysztof, while testing your patch I found another issue. Each compare starts
> a new WINWORD process which is not killed when the editor or Eclipse is closed.
> If you see the same problem, could you raise a but for that and investigate?

Comment 29 Szymon Brandys 2010-07-27 08:01:50 EDT

(In reply to comment #27)
> Szymon, are you going to test the fix also on different documents?

I will try to play with it a bit. I'd like to hear, if you can experience
similar problems when you have full Word installed.

Comment 30 Krzysztof Kazmierczyk 2010-07-29 12:00:26 EDT

Created attachment 175513 [details]
macro seecurity option

(In reply to comment #29)
> (In reply to comment #27)
> > Szymon, are you going to test the fix also on different documents?
> 
> I will try to play with it a bit. I'd like to hear, if you can experience
> similar problems when you have full Word installed.

I observed the same issue on one computer. It was rather minor issue - I was asked for disabling/enabling macros, then I got compared document in Eclipse. The issue was only I got MS Word application opened in background.

The reason is you have set macro security level to medium (see attachment) in your Word. If you change macro security to another one value, the document will be displayed with no problems. We can set default security using OLE. 

Szymon:
q1. Do want to set it? 
q2. To which value?

Comment 31 Szymon Brandys 2010-08-02 11:55:49 EDT

(In reply to comment #30)
> Szymon:
> q1. Do want to set it?
> q2. To which value?

From the discussion on ST with Krzysztof, it looks like changing this value affects the users' security settings and can break solutions relying on the default setting. This setting should be set back to its original value after opening a file. Right, Krzysztof?

Anyway this is a separate issue from the original 'saveAs' one.

Comment 32 Krzysztof Kazmierczyk 2010-08-02 12:19:11 EDT

(In reply to comment #31)
> From the discussion on ST with Krzysztof, it looks like changing this value
> affects the users' security settings and can break solutions relying on the
> default setting. This setting should be set back to its original value after
> opening a file. Right, Krzysztof?

Exactly Szymon. It is another issue and is related with opening file, not comparing.

Comment 33 Krzysztof Kazmierczyk 2010-08-24 05:44:34 EDT

Created attachment 177293 [details]
corrected error messages

Patch with corrected error messages.

Comment 34 Szymon Brandys 2010-08-24 09:35:56 EDT

1. The code added in the finally block in WordComparison#createWorkingCopy is a fix for another bug. Please remove it from this patch.
2. We should not catch SWTException inside WordComparison#openDocument(String filePath, boolean inplace). The exception should be handled by the caller of the method.

Comment 35 Krzysztof Kazmierczyk 2010-08-24 10:35:08 EDT

Created attachment 177317 [details]
patch with hints from comment 34

Here is the patch with hints from comment 34

Comment 36 Szymon Brandys 2010-08-24 14:48:55 EDT

Thanks Krzysztof. I committed the latest version of the patch to HEAD.

Comment 37 Krzysztof Kazmierczyk 2010-08-30 06:34:50 EDT

During the tests of patch I found two new bugs:
 - bug 323722 - Compare word documents blocks eclipse
 - bug 323725 - Invalid property name: Windows when comparing big word document.

These two bugs are not the consequence of the fix - there are new bugs.

Comment 38 Krzysztof Daniel 2010-09-15 10:42:00 EDT

Created attachment 178942 [details]
Plugin for testing (Eclipse 3.5 + patch 177317)

Comment 39 Michael Valenta 2010-11-30 13:42:32 EST

Szymon, is this fix going into 3.6.2?

Comment 40 Krzysztof Kazmierczyk 2010-12-01 02:47:04 EST

Hello Michael,
We have created to bugs for backports:
Bug 326393 - for Eclipse 3.5.2+
Bug 326395 - for Eclipse 3.6.2
both backports have been commited. So the fix is going into 3.6.2

Comment 41 Szymon Brandys 2010-12-01 04:04:36 EST

(In reply to comment #39)
> Szymon, is this fix going into 3.6.2?
Yes, see Bug 326395.

Comment 42 Krzysztof Daniel 2011-04-11 08:36:50 EDT

Comment on attachment 166470 [details]
error_screen

The screenshot of an error should not be marked as 'obsolete'.