Hello,
> 毛勇岗 wrote:
>> Thank you for your suggestions.
>> As you said I analyzed the call stack. And in the SfxMedium*
>> SfxApplication::InsertDocumentDialog(sfx2\source\appl\appopen.cxx),
>> sal_uInt32 nError = pMatcher->DetectFilter( *pMedium, &pFilter, FALSE );
>> if ( nError == ERRCODE_NONE && pFilter )
>> pMedium->SetFilter( pFilter );
>> else
>> DELETEZ( pMedium );
>> when insert a *.mpeg, the "nError == ERRCODE_NONE && pFilter " always is
>> true.Then the program crash.
>> If I change
>> sRealType = ::rtl::OUString::createFromAscii("calc_Text_txt_csv_StarCalc");
>> To:
>> sRealType = ::rtl::OUString::createFromAscii("writer_Text_encoded");
>> in TypeDetection::impl_checkResultsAndAddBestFilter(...)
>> (filter\source\config\cache\typedetection.cxx), The bug will be fixed.
>> I'm looking forward to your advice！
This fix not the real problem .
see below ...
> So Calc tries to load the the MPEG file as CSV (text) file. As far as I
> can see, the problems are from the display of the resulting strings in
> the filter options dialog.
>
> Your change would probably break the use of valid CSV files with unknown
> extensions in the same situation again (issue 60158).
Right. This patch will break normal CSV handling.
> Calc's filter detection service already contains logic to reject CSV
> files that have null bytes in unexpected positions, but in this
> "workaround" case, the filter is selected without calling its detection
> service. Maybe that can be changed, but generally, the filter detection
> code can be quite fragile. I'm cc'ing the framework list.
The problem is the writer detection here. MPEG isnt supported by the
office in general. So we find no suitable type if we look for the
extension. At least we ask every registered deep detection service ..
and sometimes the writer returns "writer_Text" even its not text.
The problem: nobody can write a deep detection service for pure text.
(Dont forget that such detection has to check ALL encodings of these
world too !)
The "workaround" for bug 60158 was introduced to handle all those
situations where users wish to load "everyfile.blu" or "anotherfile.xls"
or "furtherfiles.schnablibu.any" as CSV .-) The real fix would be to
have 2 text filters for calc module (one for CSV and one for plain
text). But these decision was not made ... so I had to implement the
workaround .-(
Even if we change that; TEXT wont be detected any longer; it will be
used as fallback only ... it wouldnt help. In case you do the same
(Insert a MPEG file into the writer) it will crash also.
On the other side its a bug of the CSV filter (might be of all our
current implemented filter). In case a detection was provided - the
filter does not make same checks on loading time ! The idea was: a
filter will be called only if the right detection was called before.
But thats not true. It can happen everytime a filter will be called with
an unsupported format. The filter has to deal with these situation.
A filter can reject the given content by returning an error.
Currently I dont see any other solution then fixing the crash inside the
CSV filter.
> Niklas
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
