Open a Word document word.doc in Writer and everything is fine.
Open Calc (perhaps having another .ods loaded) and seeing word.doc in Last Document List (inside Calc File menu), now open this .doc here and it is opend in Calc, not in Writer. The format is looking wrong because of Table style (but was right in Writer).
In Windows Explorer double-clicking the .doc opens Writer (as it should be),
but open from inside Calc is strange.
This would be fine:
So either dont show .doc in Calc menu, or if shown open it with Writer.
Hmm.. I cannot confirm this.
Do you pls have :
- two files involved
- a screen print of the false result?
Then I can try to reproduce.
thanks & regards,
It is not wrong with each of the files, only with the Software-2012.doc not the other logins-ak.doc! (sorry i cannot attach these private files)
Beside a possible mistake in file, it is opened fine by doubleclicking it.
$ head -n 1 Software-2012.doc
$ file Software-2012.doc
Software-2012.doc: Rich Text Format data, version 1, ANSI
$ file logins-ak.doc
logins-ak.doc: Composite Document File V2 Document, Little Endian, Os: Windows, Version 1.0, Code page: -535, Author: aleks, Template: Normal.dot, Last Saved By: SEC, Revision Number: 19, Total Editing Time: 23d+22:11:08, Create Time/Date: Tue Jan 2 11:07:00 2007, Last Saved Time/Date: Thu Jun 21 00:16:00 2007
now i try to attach the 2 screenshots.
Created attachment 79865 [details]
Calc having DOC opened
Created attachment 79866 [details]
screenshot of Calc
Recent/Last Document List showing many files.
(In reply to comment #1)
> Hi Alexander,
> Hmm.. I cannot confirm this.
> Do you pls have :
> - two files involved
> - a screen print of the false result?
> Then I can try to reproduce.
> thanks & regards,
now you can find more information.
thanks for the screenshots..
(In reply to comment #3)
> Created attachment 79865 [details]
> screenshots (2x)
> Calc having DOC opened
What happens if you rename this (in the Explorer) to Software-2012.xls ?
mv test.doc test.xls
double-click in explorer open it in Calc (again with bad format table style).
open test.xls from inside Calc - shows it in Calc,
open test.xls from inside Writer open it in Writer.
Filename-extension has no influence.
LastDocumentList and NormalOpenFile in Menu behave the same,
it is important for this file where you are, not whats inside the file.
As file <filename> shows:
Software-2012.doc: Rich Text Format data, version 1, ANSI
it is propably a RTF with wrong name.
I update the file content every month (since one year) using Writer (opened by double-click in explorer) and everything is fine (nice in Writer, no error or warning). The file content has been written (since one year) only by using LibreOffice-Writer, nothing else!
Created attachment 79922 [details]
this new created RTF shows the bug
Created attachment 79923 [details]
this new created RTF renamed to DOC shows the bug too
2 files attached that show the bug (extension in filename does not matter),
the content is not allowed to be RTF (RichTextFormat).
OK, that makes sense.. It's about rft.
- open an rtf document foo.rtf
- close the document
- open a spreadsheet
- now open foo.rtf from File > Recent used documents
> foo.rtf is opened in a spreadsheet 'container'
looks funny, but definitely not what is desired ;)
needs to be sorted out when this one came up, in which version
(In reply to comment #12)
> needs to be sorted out when this one came up, in which version
The bug is not there in LibreOffice 18.104.22.168 (Ubuntu 12.04, 64bit).
But is there in 22.214.171.124 (Windows7, 64bit).
Can not reproduce using Linux Mint 15 x64 with LibreOffice 126.96.36.199. So, looks a windows only bug to me.
(In reply to comment #14)
> Can not reproduce using Linux Mint 15 x64 with LibreOffice 188.8.131.52. So,
> looks a windows only bug to me.
a. Did you follow the steps from comment #11 ?
b. Since when do you think that I test on Windows :p
Sorry: ALexander = Windows, me = Linux >> All
Just tested in 360alpha1 - problem exist there too.
and in 3.5.7 - works without problem there.
still there in 184.108.40.206
pls do not touch the version field, when the bug is present in a later version!
The version field should reflect the oldest know version with the issue.
thanks a lot :)
(In reply to comment #11)
> > foo.rtf is opened in a spreadsheet 'container'
> looks funny, but definitely not what is desired ;)
This is the desired result, since Calc has its own rtf filter . And the type detection framework honors the DocumentService by design .
(In reply to comment #19)
> This is the desired result
Thinking of it again, when it comes to the recent documents list it does make sense to open in the same component the user used to create that file. Surely we could find a way to store the last used document service for each document in the recent list. So I'll reopen this, and set as enhancement.
Given that this is working as (currently) designed,
I do not reproduce the behavior described in comment #11. The attached RTF files open always in Writer with LibreOffice 220.127.116.11.0+ built at home under Ubuntu 14.10 x86-64.
Best regards. JBF
*** Bug 120378 has been marked as a duplicate of this bug. ***
*** Bug 121128 has been marked as a duplicate of this bug. ***
*** Bug 119478 has been marked as a duplicate of this bug. ***
*** Bug 151553 has been marked as a duplicate of this bug. ***
Alexander, Maxim: May I rephrase the title of this bug so that it can cover both the original problem described, and the case of ignoring the user's last choice of module to open a document? i.e. what Maxim suggested as the solution in comment #20?
At the moment, as phrased, my bug 151553 is not a dupe, but the Comment 20 solution would resolve both this bug and bug 151553.
(In reply to Eyal Rozenberg from comment #27)
> the Comment 20
> solution would resolve both this bug and bug 151553.
It will resolve Bug 151553 only after Bug 141732 is also fixed, as otherwise the pdf code will just ignore our app preference. (Much like is happening now - the recent files list prefers a filter from the current app, but the pdf code just ignores it.)
(There is also an alternative approach suggested in Bug 131926, to use the exact filter name, not just the app. But it comes with its own set of problems which will need to be resolved, as I commented there.)
(In reply to Maxim Monastirsky from comment #28)
> (In reply to Eyal Rozenberg from comment #27)
> > the Comment 20
> > solution would resolve both this bug and bug 151553.
> It will resolve Bug 151553 only after Bug 141732 is also fixed, as otherwise
> the pdf code will just ignore our app preference.
Oh, then I misread comment 20. I actually meant the solution you just linked to, i.e. remembering the exact filter used - bug 131926. Thanks.
*** Bug 151550 has been marked as a duplicate of this bug. ***