I assume the bug here is that the toString() method was supposed to be
implemented the same way in Base64Decoder as it is in Base64Encoder,
which would then make the docs at least make sense. But it looks like
that method simply got left out of the decoder class. Add it in just
like in the encoder and things aren't as confusing (although I'd argue
that using the toString() method to retrieve the result is an
inherently confusing way to use the classes).
Doug
On Thu, Sep 25, 2008 at 10:26 AM, Doug McCune <[EMAIL PROTECTED]> wrote:
> woops, that was in Base64Encoder, not Decoder. My mistake.
>
> On Thu, Sep 25, 2008 at 10:25 AM, Doug McCune <[EMAIL PROTECTED]> wrote:
>> In my version of the SDK source the toString method is defined and
>> looks like this:
>>
>> public function toString():String
>> {
>> return flush();
>> }
>>
>> On Thu, Sep 25, 2008 at 10:15 AM, Joao Coelho <[EMAIL PROTECTED]> wrote:
>>> --- In [email protected], Peter Farland <[EMAIL PROTECTED]> wrote:
>>>>
>>>> What do you want to do with Base64? I might be able to point you at
>>> an example. I've also logged a bug for documentation to ask them to
>>> provide examples in these classes (note this, and commenting on the
>>> live docs, is a better way to get the doc team's attention).
>>> https://bugs.adobe.com/jira/browse/FLEXDOCS-509
>>>>
>>>
>>> The problem was with the toString() method in Base64Decoder(which does
>>> not exist), according to the docs "Returns the string representation
>>> of the specified object.".
>>> The application threw a compile time error because the method did not
>>> exist.
>>> I ended up using the flush() method, after checking source code for
>>> the class, hence my comment on the previous post about the source.
>>> But thanks anyway.
>>>
>>>
>>
>
