This content has been marked as final. Show 3 replies
While I'm not sure how member.size relates to member.media, try sending
Sean Wilson wrote:
> While I'm not sure how member.size relates to member.media, try sending
> member.compressedMedia instead
Thanks, I did try compressedMedia and it didn't seem to change anything.
Whether using the media, compressedMedia or picture property I need to
be able to determine the size of the data being sent, to ensure that it
will fit in the buffer. If it's too big, the program can provide some
feedback to the users, because right now it just fails without any error
being generated. Does anyone know how to do this?
Try setting the limit to 2mb -1 byte = 2*1024*1024-1 = 2097151
Using a larger value than that will leave the limit to the default 16K.
As for the 400K image, it's the RLE compressed media of the member that is
being sent. Therefore, if it's a computer generated image that contains
large solid color areas, it could be compressed to 16K.
As for the compressedmedia property, this should be used for imported images
like gif and jpg (from what i can recall there was a problem with pngs) that
have not been modified.
What compressedmedia does is access and send the member's original
compressed data, long as they exist. If compressed data do not exist, the
member's .media is silently used.
"Dave C" <firstname.lastname@example.org> wrote in message
>I am setting up an instance of the MUS xtra with a 2000K buffer (max
>message size), but I can't seem to send an image that large.
> Using the size property of a bitmap cast member, it seems to fail
> somewhere around 400K. Does the size property really match the size of the
> media property (it is the media of a member that gets sent)>