Hi
I found out that (on the S60 3rd edition beta SDK)
RApaLsSession::SetAcceptedConfidence() needs the unconditional
WriteDeviceData capability.
To my mind, this is a bit weird as it would mean that it is not possible to
list the contents of a public folder using a recognizer. So I would like
some clarification on this.
--
Sander van der Wal
www.mBrainSoftware.com
Hi Sander
RApaLsSession::SetAcceptedConfidence sets the system-wide "confidence"
threshold for data recognizers. By altering this value, rogue software could
either cause data-types to be (incorrectly) recognized when they are not
actually supported by the phone, or alternatively, it could prevent
data-types from being recognized when they are actually supported by the
phone.
Thats why it is protected.
> To my mind, this is a bit weird as it would mean that it is not possible
> to list the contents of a public folder using a recognizer. So I would
> like some clarification on this.
I don't really understand the problem here. A recogniser is passed some data
and determines its type, with some level of confidence - what has that got
to do with this function call, or the WriteDeviceData capability? If you
have a legitimate use case for WriteDeviceData then you can always request
this through SymbianSigned.
Regards
H
"Sander van der Wal" <[email protected]> wrote in message
news:qS0tdQEGGHA.1040@extapps30...
> Hi
>
> I found out that (on the S60 3rd edition beta SDK)
> RApaLsSession::SetAcceptedConfidence() needs the unconditional
> WriteDeviceData capability.
>
> To my mind, this is a bit weird as it would mean that it is not possible
> to list the contents of a public folder using a recognizer. So I would
> like some clarification on this.
>
> --
> Sander van der Wal
> www.mBrainSoftware.com
>
"Hamish Willee" <[email protected]> wrote in message
news:gC8I3X8GGHA.1636@extapps30...
> Hi Sander
>
> RApaLsSession::SetAcceptedConfidence sets the system-wide "confidence"
> threshold for data recognizers. By altering this value, rogue software
> could either cause data-types to be (incorrectly) recognized when they are
> not actually supported by the phone, or alternatively, it could prevent
> data-types from being recognized when they are actually supported by the
> phone.
> Thats why it is protected.
[color=green]
>> To my mind, this is a bit weird as it would mean that it is not possible
>> to list the contents of a public folder using a recognizer. So I would
>> like some clarification on this.
> I don't really understand the problem here. A recogniser is passed some
> data and determines its type, with some level of confidence - what has
> that got to do with this function call, or the WriteDeviceData capability?
> If you have a legitimate use case for WriteDeviceData then you can always
> request this through SymbianSigned.[/color]
My code looks like this:
// connect to the apparc server
User::LeaveIfError(apaLsSession.Connect());
// Adobe Acrobat Reader recognizes PDF file sbased on the first 1000 bytes.
// To be able to recognize the same files, this must be our buffer size.
User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
// recognizers on certain S60 editions are quite broken.
// EPossible is a reconition on the .pdf extension, which works on all S60
editions.
User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));// read the contents of the current dir User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported, ESortByName | EDirsFirst, iDirList));So if I read you correctly, there is no need to set the confidence, providedthe recognizer system works as expected.--Sander van der Walwww.mBrainSoftware.com
Hi Sander
[color=green]
>> So if I read you correctly, there is no need to set the confidence,
>> provided the recognizer system works as expected.[/color]
1. There is no need to set the confidence in order to list the files in a
directory. The file listing does not run any recognition.
2. Mmmmm
I would try not to use this call to sort out your problem.
Each recogniser returns a level of confidence - I'd argue that if the
confidence in something being a pdf file is only EPossible, then thats
actually how confident the author is that the file is properly recognised.
If you lower the system wide acceptable confidence then you can make your
app more resistant to an inaccurate file being selected, but what about
every other thing in the system that may now pick up files with a lower
level of confidence.
There are two obvious solutions to this
- add a recogniser that you trust to get better recognition on this file
type
- or first use RecognizeData to determine the type - look at aResult to get
the confidence and determine whether this is acceptable for your app. Then
use the file based on that call.
Hope that makes sense.
Cheerio
H
"Sander van der Wal" <[email protected]> wrote in message
news:HR%23V%23EDHGHA.1964@extapps30...
>
> "Hamish Willee" <[email protected]> wrote in message
> news:gC8I3X8GGHA.1636@extapps30...[color=green]
>> Hi Sander
>>
>> RApaLsSession::SetAcceptedConfidence sets the system-wide "confidence"
>> threshold for data recognizers. By altering this value, rogue software
>> could either cause data-types to be (incorrectly) recognized when they
>> are
>> not actually supported by the phone, or alternatively, it could prevent
>> data-types from being recognized when they are actually supported by the
>> phone.
>> Thats why it is protected.
>[color=darkred]
>>> To my mind, this is a bit weird as it would mean that it is not possible
>>> to list the contents of a public folder using a recognizer. So I would
>>> like some clarification on this.
>> I don't really understand the problem here. A recogniser is passed some
>> data and determines its type, with some level of confidence - what has
>> that got to do with this function call, or the WriteDeviceData
>> capability?
>> If you have a legitimate use case for WriteDeviceData then you can always
>> request this through SymbianSigned.[/color]
>
> My code looks like this:
>
> // connect to the apparc server
> User::LeaveIfError(apaLsSession.Connect());
>
> // Adobe Acrobat Reader recognizes PDF file sbased on the first 1000
> bytes.
> // To be able to recognize the same files, this must be our buffer size.
> User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
>
> // recognizers on certain S60 editions are quite broken.
> // EPossible is a reconition on the .pdf extension, which works on all S60
> editions.
> User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));//
> read the contents of the current dir
> User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported,
> ESortByName | EDirsFirst, iDirList));So if I read you correctly, there is
> no need to set the confidence, providedthe recognizer system works as
> expected.--Sander van der Walwww.mBrainSoftware.com
>[/color]
"Hamish Willee" <[email protected]> wrote in message
news:KYg4C5IHGHA.3028@extapps30...
> Hi Sander
>[color=green][color=darkred]
>>> So if I read you correctly, there is no need to set the confidence,
>>> provided the recognizer system works as expected.[/color]
> 1. There is no need to set the confidence in order to list the files in a
> directory. The file listing does not run any recognition.
>
> 2. Mmmmm
> I would try not to use this call to sort out your problem.
>
> Each recogniser returns a level of confidence - I'd argue that if the
> confidence in something being a pdf file is only EPossible, then thats
> actually how confident the author is that the file is properly recognised.
> If you lower the system wide acceptable confidence then you can make your
> app more resistant to an inaccurate file being selected, but what about
> every other thing in the system that may now pick up files with a lower
> level of confidence.
>
> There are two obvious solutions to this
> - add a recogniser that you trust to get better recognition on this file
> type
> - or first use RecognizeData to determine the type - look at aResult to
> get the confidence and determine whether this is acceptable for your app.
> Then use the file based on that call.
>
> Hope that makes sense.[/color]
I did write the PDF recognizer myself so I know why it was behaving like
that. The problem was that the recognizer framework on older S60 versions
didn't work properly. The recognizer itself had been used for the Psion and
the 9200 communicator and it worked fine.
Setting a lower confidence level did the trick, let's find out/hope it works
on S60 3rd edition so the trick isn't needed.
--
Sander van der Wal
www.mBrainSoftware.com
> Cheerio
> H
>
>
>
>
> "Sander van der Wal" <[email protected]> wrote in message
> news:HR%23V%23EDHGHA.1964@extapps30...[color=green]
>>
>> "Hamish Willee" <[email protected]> wrote in message
>> news:gC8I3X8GGHA.1636@extapps30...[color=darkred]
>>> Hi Sander
>>>
>>> RApaLsSession::SetAcceptedConfidence sets the system-wide "confidence"
>>> threshold for data recognizers. By altering this value, rogue software
>>> could either cause data-types to be (incorrectly) recognized when they
>>> are
>>> not actually supported by the phone, or alternatively, it could prevent
>>> data-types from being recognized when they are actually supported by the
>>> phone.
>>> Thats why it is protected.
>>
>>>> To my mind, this is a bit weird as it would mean that it is not
>>>> possible
>>>> to list the contents of a public folder using a recognizer. So I would
>>>> like some clarification on this.
>>> I don't really understand the problem here. A recogniser is passed some
>>> data and determines its type, with some level of confidence - what has
>>> that got to do with this function call, or the WriteDeviceData
>>> capability?
>>> If you have a legitimate use case for WriteDeviceData then you can
>>> always
>>> request this through SymbianSigned.
>>
>> My code looks like this:
>>
>> // connect to the apparc server
>> User::LeaveIfError(apaLsSession.Connect());
>>
>> // Adobe Acrobat Reader recognizes PDF file sbased on the first 1000
>> bytes.
>> // To be able to recognize the same files, this must be our buffer size.
>> User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
>>
>> // recognizers on certain S60 editions are quite broken.
>> // EPossible is a reconition on the .pdf extension, which works on all
>> S60 editions.
>> User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));//
>> read the contents of the current dir
>> User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported,
>> ESortByName | EDirsFirst, iDirList));So if I read you correctly, there is
>> no need to set the confidence, providedthe recognizer system works as
>> expected.--Sander van der Walwww.mBrainSoftware.com
>>[/color]
>
>[/color]
Hi Sander
Sure it works, but it may well break other applications.
Perhaps try another trick i.e.
> - or first use RecognizeData to determine the type - look at aResult to
> get the confidence and determine whether this is acceptable for your app.
> Then use the file based on that call.
Unless you believe that this approach is broken also?
Cheers
H
"Sander van der Wal" <[email protected]> wrote in message
news:rjPSEoMHGHA.1636@extapps30...
>
> "Hamish Willee" <[email protected]> wrote in message
> news:KYg4C5IHGHA.3028@extapps30...[color=green]
>> Hi Sander
>>[color=darkred]
>>>> So if I read you correctly, there is no need to set the confidence,
>>>> provided the recognizer system works as expected.
>> 1. There is no need to set the confidence in order to list the files in a
>> directory. The file listing does not run any recognition.
>>
>> 2. Mmmmm
>> I would try not to use this call to sort out your problem.
>>
>> Each recogniser returns a level of confidence - I'd argue that if the
>> confidence in something being a pdf file is only EPossible, then thats
>> actually how confident the author is that the file is properly
>> recognised. If you lower the system wide acceptable confidence then you
>> can make your app more resistant to an inaccurate file being selected,
>> but what about every other thing in the system that may now pick up files
>> with a lower level of confidence.
>>
>> There are two obvious solutions to this
>> - add a recogniser that you trust to get better recognition on this file
>> type
>> - or first use RecognizeData to determine the type - look at aResult to
>> get the confidence and determine whether this is acceptable for your app.
>> Then use the file based on that call.
>>
>> Hope that makes sense.[/color]
>
> I did write the PDF recognizer myself so I know why it was behaving like
> that. The problem was that the recognizer framework on older S60 versions
> didn't work properly. The recognizer itself had been used for the Psion
> and the 9200 communicator and it worked fine.
>
> Setting a lower confidence level did the trick, let's find out/hope it
> works on S60 3rd edition so the trick isn't needed.
>
> --
> Sander van der Wal
> www.mBrainSoftware.com
>
>> Cheerio
>> H
>>
>>
>>
>>
>> "Sander van der Wal" <[email protected]> wrote in message
>> news:HR%23V%23EDHGHA.1964@extapps30...[color=darkred]
>>>
>>> "Hamish Willee" <[email protected]> wrote in message
>>> news:gC8I3X8GGHA.1636@extapps30...
>>>> Hi Sander
>>>>
>>>> RApaLsSession::SetAcceptedConfidence sets the system-wide "confidence"
>>>> threshold for data recognizers. By altering this value, rogue software
>>>> could either cause data-types to be (incorrectly) recognized when they
>>>> are
>>>> not actually supported by the phone, or alternatively, it could prevent
>>>> data-types from being recognized when they are actually supported by
>>>> the
>>>> phone.
>>>> Thats why it is protected.
>>>
>>>>> To my mind, this is a bit weird as it would mean that it is not
>>>>> possible
>>>>> to list the contents of a public folder using a recognizer. So I would
>>>>> like some clarification on this.
>>>> I don't really understand the problem here. A recogniser is passed some
>>>> data and determines its type, with some level of confidence - what has
>>>> that got to do with this function call, or the WriteDeviceData
>>>> capability?
>>>> If you have a legitimate use case for WriteDeviceData then you can
>>>> always
>>>> request this through SymbianSigned.
>>>
>>> My code looks like this:
>>>
>>> // connect to the apparc server
>>> User::LeaveIfError(apaLsSession.Connect());
>>>
>>> // Adobe Acrobat Reader recognizes PDF file sbased on the first 1000
>>> bytes.
>>> // To be able to recognize the same files, this must be our buffer size.
>>> User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
>>>
>>> // recognizers on certain S60 editions are quite broken.
>>> // EPossible is a reconition on the .pdf extension, which works on all
>>> S60 editions.
>>> User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));//
>>> read the contents of the current dir
>>> User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported,
>>> ESortByName | EDirsFirst, iDirList));So if I read you correctly, there
>>> is no need to set the confidence, providedthe recognizer system works as
>>> expected.--Sander van der Walwww.mBrainSoftware.com
>>>
>>
>>[/color]
>
>[/color]
"Hamish Willee" <[email protected]> wrote in message
news:P7keZwVHGHA.1944@extapps30...
> Hi Sander
>
> Sure it works, but it may well break other applications.
Probably. But is the confidence level is so important, why doesn't it's
entry in the SDK docs state you are setting the global confidence level? I
would assume (no news is good news) that you would set the confidence level
for the current apalssession.
> Perhaps try another trick i.e.[color=green]
>> - or first use RecognizeData to determine the type - look at aResult to
>> get the confidence and determine whether this is acceptable for your app.
>> Then use the file based on that call.
>
> Unless you believe that this approach is broken also?[/color]
I would prefer a recognizer system that works as advertised. There were lots
of people at the time having problems with it in Series 60. Using a
confidence level of EProbably was a hack, to have a shippable product that
would make money.
--
Sander van der Wal
www.mBrainSoftware.com
> Cheers
> H
>
>
> "Sander van der Wal" <[email protected]> wrote in message
> news:rjPSEoMHGHA.1636@extapps30...[color=green]
>>
>> "Hamish Willee" <[email protected]> wrote in message
>> news:KYg4C5IHGHA.3028@extapps30...[color=darkred]
>>> Hi Sander
>>>
>>>>> So if I read you correctly, there is no need to set the confidence,
>>>>> provided the recognizer system works as expected.
>>> 1. There is no need to set the confidence in order to list the files in
>>> a directory. The file listing does not run any recognition.
>>>
>>> 2. Mmmmm
>>> I would try not to use this call to sort out your problem.
>>>
>>> Each recogniser returns a level of confidence - I'd argue that if the
>>> confidence in something being a pdf file is only EPossible, then thats
>>> actually how confident the author is that the file is properly
>>> recognised. If you lower the system wide acceptable confidence then you
>>> can make your app more resistant to an inaccurate file being selected,
>>> but what about every other thing in the system that may now pick up
>>> files with a lower level of confidence.
>>>
>>> There are two obvious solutions to this
>>> - add a recogniser that you trust to get better recognition on this file
>>> type
>>> - or first use RecognizeData to determine the type - look at aResult to
>>> get the confidence and determine whether this is acceptable for your
>>> app. Then use the file based on that call.
>>>
>>> Hope that makes sense.
>>
>> I did write the PDF recognizer myself so I know why it was behaving like
>> that. The problem was that the recognizer framework on older S60 versions
>> didn't work properly. The recognizer itself had been used for the Psion
>> and the 9200 communicator and it worked fine.
>>
>> Setting a lower confidence level did the trick, let's find out/hope it
>> works on S60 3rd edition so the trick isn't needed.
>>
>> --
>> Sander van der Wal
>> www.mBrainSoftware.com
>>
>>> Cheerio
>>> H
>>>
>>>
>>>
>>>
>>> "Sander van der Wal" <[email protected]> wrote in message
>>> news:HR%23V%23EDHGHA.1964@extapps30...
>>>>
>>>> "Hamish Willee" <[email protected]> wrote in message
>>>> news:gC8I3X8GGHA.1636@extapps30...
>>>>> Hi Sander
>>>>>
>>>>> RApaLsSession::SetAcceptedConfidence sets the system-wide "confidence"
>>>>> threshold for data recognizers. By altering this value, rogue software
>>>>> could either cause data-types to be (incorrectly) recognized when they
>>>>> are
>>>>> not actually supported by the phone, or alternatively, it could
>>>>> prevent
>>>>> data-types from being recognized when they are actually supported by
>>>>> the
>>>>> phone.
>>>>> Thats why it is protected.
>>>>
>>>>>> To my mind, this is a bit weird as it would mean that it is not
>>>>>> possible
>>>>>> to list the contents of a public folder using a recognizer. So I
>>>>>> would
>>>>>> like some clarification on this.
>>>>> I don't really understand the problem here. A recogniser is passed
>>>>> some
>>>>> data and determines its type, with some level of confidence - what has
>>>>> that got to do with this function call, or the WriteDeviceData
>>>>> capability?
>>>>> If you have a legitimate use case for WriteDeviceData then you can
>>>>> always
>>>>> request this through SymbianSigned.
>>>>
>>>> My code looks like this:
>>>>
>>>> // connect to the apparc server
>>>> User::LeaveIfError(apaLsSession.Connect());
>>>>
>>>> // Adobe Acrobat Reader recognizes PDF file sbased on the first 1000
>>>> bytes.
>>>> // To be able to recognize the same files, this must be our buffer
>>>> size.
>>>> User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
>>>>
>>>> // recognizers on certain S60 editions are quite broken.
>>>> // EPossible is a reconition on the .pdf extension, which works on all
>>>> S60 editions.
>>>> User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));//
>>>> read the contents of the current dir
>>>> User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported,
>>>> ESortByName | EDirsFirst, iDirList));So if I read you correctly, there
>>>> is no need to set the confidence, providedthe recognizer system works
>>>> as expected.--Sander van der Walwww.mBrainSoftware.com
>>>>
>>>
>>>
>>
>>[/color]
>
>[/color]
G'day Sander
Cursed pragmatism. Well, I've given you another option now - so you can "do
the right thing".
- Re developer library not saying you are setting the global confidence
level - its a defect - I've put in a report.
- I don't care to comment on the general stability of the framework, not
having investigated - but EProbably is a valid return value for a recogniser
that can't recognise a MIME type reliably.
Cheerio
H
"Sander van der Wal" <[email protected]> wrote in message
news:QFXDmTaHGHA.3124@extapps30...
>
> "Hamish Willee" <[email protected]> wrote in message
> news:P7keZwVHGHA.1944@extapps30...[color=green]
>> Hi Sander
>>
>> Sure it works, but it may well break other applications.
>
> Probably. But is the confidence level is so important, why doesn't it's
> entry in the SDK docs state you are setting the global confidence level? I
> would assume (no news is good news) that you would set the confidence
> level for the current apalssession.
>
>> Perhaps try another trick i.e.[color=darkred]
>>> - or first use RecognizeData to determine the type - look at aResult to
>>> get the confidence and determine whether this is acceptable for your
>>> app. Then use the file based on that call.
>>
>> Unless you believe that this approach is broken also?[/color]
>
> I would prefer a recognizer system that works as advertised. There were
> lots of people at the time having problems with it in Series 60. Using a
> confidence level of EProbably was a hack, to have a shippable product that
> would make money.
>
> --
> Sander van der Wal
> www.mBrainSoftware.com
>
>> Cheers
>> H
>>
>>
>> "Sander van der Wal" <[email protected]> wrote in message
>> news:rjPSEoMHGHA.1636@extapps30...[color=darkred]
>>>
>>> "Hamish Willee" <[email protected]> wrote in message
>>> news:KYg4C5IHGHA.3028@extapps30...
>>>> Hi Sander
>>>>
>>>>>> So if I read you correctly, there is no need to set the confidence,
>>>>>> provided the recognizer system works as expected.
>>>> 1. There is no need to set the confidence in order to list the files in
>>>> a directory. The file listing does not run any recognition.
>>>>
>>>> 2. Mmmmm
>>>> I would try not to use this call to sort out your problem.
>>>>
>>>> Each recogniser returns a level of confidence - I'd argue that if the
>>>> confidence in something being a pdf file is only EPossible, then thats
>>>> actually how confident the author is that the file is properly
>>>> recognised. If you lower the system wide acceptable confidence then you
>>>> can make your app more resistant to an inaccurate file being selected,
>>>> but what about every other thing in the system that may now pick up
>>>> files with a lower level of confidence.
>>>>
>>>> There are two obvious solutions to this
>>>> - add a recogniser that you trust to get better recognition on this
>>>> file type
>>>> - or first use RecognizeData to determine the type - look at aResult to
>>>> get the confidence and determine whether this is acceptable for your
>>>> app. Then use the file based on that call.
>>>>
>>>> Hope that makes sense.
>>>
>>> I did write the PDF recognizer myself so I know why it was behaving like
>>> that. The problem was that the recognizer framework on older S60
>>> versions didn't work properly. The recognizer itself had been used for
>>> the Psion and the 9200 communicator and it worked fine.
>>>
>>> Setting a lower confidence level did the trick, let's find out/hope it
>>> works on S60 3rd edition so the trick isn't needed.
>>>
>>> --
>>> Sander van der Wal
>>> www.mBrainSoftware.com
>>>
>>>> Cheerio
>>>> H
>>>>
>>>>
>>>>
>>>>
>>>> "Sander van der Wal" <[email protected]> wrote in message
>>>> news:HR%23V%23EDHGHA.1964@extapps30...
>>>>>
>>>>> "Hamish Willee" <[email protected]> wrote in message
>>>>> news:gC8I3X8GGHA.1636@extapps30...
>>>>>> Hi Sander
>>>>>>
>>>>>> RApaLsSession::SetAcceptedConfidence sets the system-wide
>>>>>> "confidence"
>>>>>> threshold for data recognizers. By altering this value, rogue
>>>>>> software
>>>>>> could either cause data-types to be (incorrectly) recognized when
>>>>>> they are
>>>>>> not actually supported by the phone, or alternatively, it could
>>>>>> prevent
>>>>>> data-types from being recognized when they are actually supported by
>>>>>> the
>>>>>> phone.
>>>>>> Thats why it is protected.
>>>>>
>>>>>>> To my mind, this is a bit weird as it would mean that it is not
>>>>>>> possible
>>>>>>> to list the contents of a public folder using a recognizer. So I
>>>>>>> would
>>>>>>> like some clarification on this.
>>>>>> I don't really understand the problem here. A recogniser is passed
>>>>>> some
>>>>>> data and determines its type, with some level of confidence - what
>>>>>> has
>>>>>> that got to do with this function call, or the WriteDeviceData
>>>>>> capability?
>>>>>> If you have a legitimate use case for WriteDeviceData then you can
>>>>>> always
>>>>>> request this through SymbianSigned.
>>>>>
>>>>> My code looks like this:
>>>>>
>>>>> // connect to the apparc server
>>>>> User::LeaveIfError(apaLsSession.Connect());
>>>>>
>>>>> // Adobe Acrobat Reader recognizes PDF file sbased on the first 1000
>>>>> bytes.
>>>>> // To be able to recognize the same files, this must be our buffer
>>>>> size.
>>>>> User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
>>>>>
>>>>> // recognizers on certain S60 editions are quite broken.
>>>>> // EPossible is a reconition on the .pdf extension, which works on all
>>>>> S60 editions.
>>>>> User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));//
>>>>> read the contents of the current dir
>>>>> User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported,
>>>>> ESortByName | EDirsFirst, iDirList));So if I read you correctly, there
>>>>> is no need to set the confidence, providedthe recognizer system works
>>>>> as expected.--Sander van der Walwww.mBrainSoftware.com
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>[/color]
>
>[/color]
"Hamish Willee" <[email protected]> wrote in message
news:GOjOgILIGHA.2212@extapps30...
> G'day Sander
>
> Cursed pragmatism. Well, I've given you another option now - so you can
> "do the right thing".
>
> - Re developer library not saying you are setting the global confidence
> level - its a defect - I've put in a report.
> - I don't care to comment on the general stability of the framework, not
> having investigated - but EProbably is a valid return value for a
> recogniser that can't recognise a MIME type reliably.
It works on S60 3rd edition without changing the global confidence level. So
the call will be removed and I can run without capabilities (for the time
being, who knows what the undocumented document handler framework will need
!@#$%^&*()
--
Sander van der Wal
www.mBrainSoftware.com
> Cheerio
> H
>
> "Sander van der Wal" <[email protected]> wrote in message
> news:QFXDmTaHGHA.3124@extapps30...[color=green]
>>
>> "Hamish Willee" <[email protected]> wrote in message
>> news:P7keZwVHGHA.1944@extapps30...[color=darkred]
>>> Hi Sander
>>>
>>> Sure it works, but it may well break other applications.
>>
>> Probably. But is the confidence level is so important, why doesn't it's
>> entry in the SDK docs state you are setting the global confidence level?
>> I would assume (no news is good news) that you would set the confidence
>> level for the current apalssession.
>>
>>> Perhaps try another trick i.e.
>>>> - or first use RecognizeData to determine the type - look at aResult to
>>>> get the confidence and determine whether this is acceptable for your
>>>> app. Then use the file based on that call.
>>>
>>> Unless you believe that this approach is broken also?
>>
>> I would prefer a recognizer system that works as advertised. There were
>> lots of people at the time having problems with it in Series 60. Using a
>> confidence level of EProbably was a hack, to have a shippable product
>> that would make money.
>>
>> --
>> Sander van der Wal
>> www.mBrainSoftware.com
>>
>>> Cheers
>>> H
>>>
>>>
>>> "Sander van der Wal" <[email protected]> wrote in message
>>> news:rjPSEoMHGHA.1636@extapps30...
>>>>
>>>> "Hamish Willee" <[email protected]> wrote in message
>>>> news:KYg4C5IHGHA.3028@extapps30...
>>>>> Hi Sander
>>>>>
>>>>>>> So if I read you correctly, there is no need to set the confidence,
>>>>>>> provided the recognizer system works as expected.
>>>>> 1. There is no need to set the confidence in order to list the files
>>>>> in a directory. The file listing does not run any recognition.
>>>>>
>>>>> 2. Mmmmm
>>>>> I would try not to use this call to sort out your problem.
>>>>>
>>>>> Each recogniser returns a level of confidence - I'd argue that if the
>>>>> confidence in something being a pdf file is only EPossible, then thats
>>>>> actually how confident the author is that the file is properly
>>>>> recognised. If you lower the system wide acceptable confidence then
>>>>> you can make your app more resistant to an inaccurate file being
>>>>> selected, but what about every other thing in the system that may now
>>>>> pick up files with a lower level of confidence.
>>>>>
>>>>> There are two obvious solutions to this
>>>>> - add a recogniser that you trust to get better recognition on this
>>>>> file type
>>>>> - or first use RecognizeData to determine the type - look at aResult
>>>>> to get the confidence and determine whether this is acceptable for
>>>>> your app. Then use the file based on that call.
>>>>>
>>>>> Hope that makes sense.
>>>>
>>>> I did write the PDF recognizer myself so I know why it was behaving
>>>> like that. The problem was that the recognizer framework on older S60
>>>> versions didn't work properly. The recognizer itself had been used for
>>>> the Psion and the 9200 communicator and it worked fine.
>>>>
>>>> Setting a lower confidence level did the trick, let's find out/hope it
>>>> works on S60 3rd edition so the trick isn't needed.
>>>>
>>>> --
>>>> Sander van der Wal
>>>> www.mBrainSoftware.com
>>>>
>>>>> Cheerio
>>>>> H
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> "Sander van der Wal" <[email protected]> wrote in message
>>>>> news:HR%23V%23EDHGHA.1964@extapps30...
>>>>>>
>>>>>> "Hamish Willee" <[email protected]> wrote in message
>>>>>> news:gC8I3X8GGHA.1636@extapps30...
>>>>>>> Hi Sander
>>>>>>>
>>>>>>> RApaLsSession::SetAcceptedConfidence sets the system-wide
>>>>>>> "confidence"
>>>>>>> threshold for data recognizers. By altering this value, rogue
>>>>>>> software
>>>>>>> could either cause data-types to be (incorrectly) recognized when
>>>>>>> they are
>>>>>>> not actually supported by the phone, or alternatively, it could
>>>>>>> prevent
>>>>>>> data-types from being recognized when they are actually supported by
>>>>>>> the
>>>>>>> phone.
>>>>>>> Thats why it is protected.
>>>>>>
>>>>>>>> To my mind, this is a bit weird as it would mean that it is not
>>>>>>>> possible
>>>>>>>> to list the contents of a public folder using a recognizer. So I
>>>>>>>> would
>>>>>>>> like some clarification on this.
>>>>>>> I don't really understand the problem here. A recogniser is passed
>>>>>>> some
>>>>>>> data and determines its type, with some level of confidence - what
>>>>>>> has
>>>>>>> that got to do with this function call, or the WriteDeviceData
>>>>>>> capability?
>>>>>>> If you have a legitimate use case for WriteDeviceData then you can
>>>>>>> always
>>>>>>> request this through SymbianSigned.
>>>>>>
>>>>>> My code looks like this:
>>>>>>
>>>>>> // connect to the apparc server
>>>>>> User::LeaveIfError(apaLsSession.Connect());
>>>>>>
>>>>>> // Adobe Acrobat Reader recognizes PDF file sbased on the first 1000
>>>>>> bytes.
>>>>>> // To be able to recognize the same files, this must be our buffer
>>>>>> size.
>>>>>> User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
>>>>>>
>>>>>> // recognizers on certain S60 editions are quite broken.
>>>>>> // EPossible is a reconition on the .pdf extension, which works on
>>>>>> all S60 editions.
>>>>>> User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));//
>>>>>> read the contents of the current dir
>>>>>> User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported,
>>>>>> ESortByName | EDirsFirst, iDirList));So if I read you correctly,
>>>>>> there is no need to set the confidence, providedthe recognizer system
>>>>>> works as expected.--Sander van der Walwww.mBrainSoftware.com
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>[/color]
>
>[/color]
😊
"Sander van der Wal" <[email protected]> wrote in message
news:H5iA8uLIGHA.2712@extapps30...
>
> "Hamish Willee" <[email protected]> wrote in message
> news:GOjOgILIGHA.2212@extapps30...[color=green]
>> G'day Sander
>>
>> Cursed pragmatism. Well, I've given you another option now - so you can
>> "do the right thing".
>>
>> - Re developer library not saying you are setting the global confidence
>> level - its a defect - I've put in a report.
>> - I don't care to comment on the general stability of the framework, not
>> having investigated - but EProbably is a valid return value for a
>> recogniser that can't recognise a MIME type reliably.
>
> It works on S60 3rd edition without changing the global confidence level.
> So the call will be removed and I can run without capabilities (for the
> time being, who knows what the undocumented document handler framework
> will need !@#$%^&*()
>
> --
> Sander van der Wal
> www.mBrainSoftware.com
>
>> Cheerio
>> H
>>
>> "Sander van der Wal" <[email protected]> wrote in message
>> news:QFXDmTaHGHA.3124@extapps30...[color=darkred]
>>>
>>> "Hamish Willee" <[email protected]> wrote in message
>>> news:P7keZwVHGHA.1944@extapps30...
>>>> Hi Sander
>>>>
>>>> Sure it works, but it may well break other applications.
>>>
>>> Probably. But is the confidence level is so important, why doesn't it's
>>> entry in the SDK docs state you are setting the global confidence level?
>>> I would assume (no news is good news) that you would set the confidence
>>> level for the current apalssession.
>>>
>>>> Perhaps try another trick i.e.
>>>>> - or first use RecognizeData to determine the type - look at aResult
>>>>> to get the confidence and determine whether this is acceptable for
>>>>> your app. Then use the file based on that call.
>>>>
>>>> Unless you believe that this approach is broken also?
>>>
>>> I would prefer a recognizer system that works as advertised. There were
>>> lots of people at the time having problems with it in Series 60. Using a
>>> confidence level of EProbably was a hack, to have a shippable product
>>> that would make money.
>>>
>>> --
>>> Sander van der Wal
>>> www.mBrainSoftware.com
>>>
>>>> Cheers
>>>> H
>>>>
>>>>
>>>> "Sander van der Wal" <[email protected]> wrote in message
>>>> news:rjPSEoMHGHA.1636@extapps30...
>>>>>
>>>>> "Hamish Willee" <[email protected]> wrote in message
>>>>> news:KYg4C5IHGHA.3028@extapps30...
>>>>>> Hi Sander
>>>>>>
>>>>>>>> So if I read you correctly, there is no need to set the confidence,
>>>>>>>> provided the recognizer system works as expected.
>>>>>> 1. There is no need to set the confidence in order to list the files
>>>>>> in a directory. The file listing does not run any recognition.
>>>>>>
>>>>>> 2. Mmmmm
>>>>>> I would try not to use this call to sort out your problem.
>>>>>>
>>>>>> Each recogniser returns a level of confidence - I'd argue that if the
>>>>>> confidence in something being a pdf file is only EPossible, then
>>>>>> thats actually how confident the author is that the file is properly
>>>>>> recognised. If you lower the system wide acceptable confidence then
>>>>>> you can make your app more resistant to an inaccurate file being
>>>>>> selected, but what about every other thing in the system that may now
>>>>>> pick up files with a lower level of confidence.
>>>>>>
>>>>>> There are two obvious solutions to this
>>>>>> - add a recogniser that you trust to get better recognition on this
>>>>>> file type
>>>>>> - or first use RecognizeData to determine the type - look at aResult
>>>>>> to get the confidence and determine whether this is acceptable for
>>>>>> your app. Then use the file based on that call.
>>>>>>
>>>>>> Hope that makes sense.
>>>>>
>>>>> I did write the PDF recognizer myself so I know why it was behaving
>>>>> like that. The problem was that the recognizer framework on older S60
>>>>> versions didn't work properly. The recognizer itself had been used for
>>>>> the Psion and the 9200 communicator and it worked fine.
>>>>>
>>>>> Setting a lower confidence level did the trick, let's find out/hope it
>>>>> works on S60 3rd edition so the trick isn't needed.
>>>>>
>>>>> --
>>>>> Sander van der Wal
>>>>> www.mBrainSoftware.com
>>>>>
>>>>>> Cheerio
>>>>>> H
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> "Sander van der Wal" <[email protected]> wrote in message
>>>>>> news:HR%23V%23EDHGHA.1964@extapps30...
>>>>>>>
>>>>>>> "Hamish Willee" <[email protected]> wrote in message
>>>>>>> news:gC8I3X8GGHA.1636@extapps30...
>>>>>>>> Hi Sander
>>>>>>>>
>>>>>>>> RApaLsSession::SetAcceptedConfidence sets the system-wide
>>>>>>>> "confidence"
>>>>>>>> threshold for data recognizers. By altering this value, rogue
>>>>>>>> software
>>>>>>>> could either cause data-types to be (incorrectly) recognized when
>>>>>>>> they are
>>>>>>>> not actually supported by the phone, or alternatively, it could
>>>>>>>> prevent
>>>>>>>> data-types from being recognized when they are actually supported
>>>>>>>> by the
>>>>>>>> phone.
>>>>>>>> Thats why it is protected.
>>>>>>>
>>>>>>>>> To my mind, this is a bit weird as it would mean that it is not
>>>>>>>>> possible
>>>>>>>>> to list the contents of a public folder using a recognizer. So I
>>>>>>>>> would
>>>>>>>>> like some clarification on this.
>>>>>>>> I don't really understand the problem here. A recogniser is passed
>>>>>>>> some
>>>>>>>> data and determines its type, with some level of confidence - what
>>>>>>>> has
>>>>>>>> that got to do with this function call, or the WriteDeviceData
>>>>>>>> capability?
>>>>>>>> If you have a legitimate use case for WriteDeviceData then you can
>>>>>>>> always
>>>>>>>> request this through SymbianSigned.
>>>>>>>
>>>>>>> My code looks like this:
>>>>>>>
>>>>>>> // connect to the apparc server
>>>>>>> User::LeaveIfError(apaLsSession.Connect());
>>>>>>>
>>>>>>> // Adobe Acrobat Reader recognizes PDF file sbased on the first 1000
>>>>>>> bytes.
>>>>>>> // To be able to recognize the same files, this must be our buffer
>>>>>>> size.
>>>>>>> User::LeaveIfError(apaLsSession.SetMaxDataBufSize(1000));
>>>>>>>
>>>>>>> // recognizers on certain S60 editions are quite broken.
>>>>>>> // EPossible is a reconition on the .pdf extension, which works on
>>>>>>> all S60 editions.
>>>>>>> User::LeaveIfError(apaLsSession.SetAcceptedConfidence(CApaDataRecognizerType::EPossible));//
>>>>>>> read the contents of the current dir
>>>>>>> User::LeaveIfError(iEnv->FsSession().GetDir(iCurrentDir.FullName(),KEntryAttMaskSupported,
>>>>>>> ESortByName | EDirsFirst, iDirList));So if I read you correctly,
>>>>>>> there is no need to set the confidence, providedthe recognizer
>>>>>>> system works as expected.--Sander van der Walwww.mBrainSoftware.com
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>[/color]
>
>[/color]