Fridrich Strba wrote:
Thanks, Andreas, for your clarifications.
<snip>
Because any filter must deal with the situation, that a complete unknown format is provided to the filter.
WriterPerfect conversion, if you force it to open an unsupported document, will result in a blank document. No crashers.
Hm ... breaking the filter operation by returning false in cmobination with an used interaction seems to be the better way .-)
A deep detection service has to return an empty string for unknown formats and a well defined string for supported formats.
This is what we were believing doing. But, life happens.
It happens every day here too .-)
A filter has to return TRUE/FALSE only as a result of it's operation.
Throwing of exceptions is limited to RuntimeExceptions only. Errors has to be handled gracefully using the interaction concept. It's not allowed to show dialogs directly!
The exception was just our bug and in no way an intention :-).
Of course.
You problem regarding the shown error box
"Read-Error. Cannot read the file"
seems to be a problem of another deep detection module.
May be it does not use the provided input stream and try to open the file again ... which is normaly locked then and can't be opened read/write normaly then. On the other side the file is opened by the generic typedetection framework at a central place so problems regarding opening the file are handled one times only. We had several bugs before ... because every modules used by the typedetection framework tried to open the stream ...
But in case the url was wrong it was tried more then ones ... and of course the corresponding error message was shown more then once too.
This is reminding me that in the documentation, it is recommended that if a service creates InputStream from URL, it should add this stream into the MediaDescriptor. Is it something that we should do or is the stream creation handled centrally in all cases? It was not at all this case (central creation of stream) in SRX645. I am asking, because it looks like our TypeDetection is fired as a first one in the list of deep detection services.
My generic typedetection framework was changed many times. Current implementation now open the stream first before it calls any other external service (e.g. detect services, frame loader, filter etcpp.).
So I can handle errors related to opening the stream more central and supress expensive detect/filter/load operations in case e.g. the URL is wrong.
On the other side using of a detection or filter service is not bound to the generic typedetection framework. It can be used within scripts directly. And nobody can guarantee that the stream is provided by the API calli too. Then the detect or filter service itself has to handle this situation gracefully. Of course it can reject such calls within an "incomplete environment". But it can try to open the stream by itself using the UCB.
But this decision must be done by you. If your filter does not support such "3rdParty environments" ... it's OK. But then you have to communicate it, if you get a bug for that .-)
BTW: I can't reproduce this error message on a normal m83 version nor on the cws fwkfinal. But you can send me the debugger output ... if it contains more then library names only .-)
email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
If you cannot reproduce it, it could mean that my build is kind of hoarked. Although, I built it simulataneously on two machines with a clean checkout (not dmake clean). I put the file somewhere on the web and I give you the url. You will be able to see if you have time.
For me the problem seems to be fixed (at least on my current cws), so there is no need to analyze this problem. Form the past I know, that bugs inside typedetection cames in and goes out ... The only think, which is interesting, is: the next version must work correctly.
Thanks again for your work and sorry again for the regression. I am believing that after we iron these issues, the new WP typedetection will be much better than it was before (all supported WP files are detected as such and all unsupported WP files are detected as unknown format).
Great.
Regards Andreas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
