Get MSG property by property's hex name

We are now working on the fully parser for RTF. It goes fine.

The bug for embedded images and Ole icon will be supported after we finished the RTF parser.

I will keep you update on this thread.

Thanks,

Thanks Iret for updating us, we are looking forward to the new version!

Becky

When should we expect the next release? We are on a crunch and are need the items very soon.

Thanks

According to the development status and plans, we will release a new version in late Augest. We will provide beta along with our development, if you would like to give us feedbacks.

Thanks,

Hi Iret,

Can we possibly have the following items available in an early beta or interim release? Our system is scheduled to release in two weeks and these items are important to have.

  1. Attachment list not abbreviated

  2. Consistent placeholder (for any extractable embedded object; for attachment in RTF formatted email)

  3. Image within RTF email extractable (at this time not necessarily renderable in mht)

Thanks, and please let us know.

Becky

iret:

Hello,

We have finished the beta2 development for the product. Please check it out.

[http://www.aspose.com/Community/Blogs/aspose.network/archive/2007/05/13/aspose_network_parse_microsoft_outlook_message_files.aspx](https://forum.aspose.com/Community/Blogs/aspose.network/archive/2007/05/13/aspose_network_parse_microsoft_outlook_message_files.aspx)

It is great it you can provide some feedbacks.

Thanks

Sorry for the late reply,and thanks to your good job,i will check it out and have a look!thank you,[dvd to iphone](http://www.dvdtoiphone.us/)

Hi Iret,

The previous post is a spam, right? It links to an old version of Aspose.Network.

Just to make sure with you that you haven't dropped a new beta for your comming release.

Thanks!

What is the status of some of our needed items? We havenet heard anything in 18 days and need to start getting the functionality for our release. Last time you mentioned you would provide Betas, but we havenet heard anything.

Thanks

Thanks for considering Aspose.

I am very sorry for not getting back to you in time. In the past weeks, we were engaged in some high priority bugs fixing for Aspose.Network. As you seen, we released a hotfix for Aspose.Network v3.5.3.0.

In v3.5.3.0, several serious bugs have been fixed, which will also impact the Outlook features for the sharing MIME parser code.

We are now turning back to continue the improvement for Aspose.Network.Outlook. Hopefully, we will provide you a beta build shortly.

We will definitely push the progress of the development. Thank you very much.

Hello,

We have completed the feature that extracts the OLE document name. Could you like to try to use the beta dll? In this beta hotfix, we have extracted the file name from OLE document, and use it in the message body and attachment in mht format messages.

Here is the link:

http://www.aspose.com/products/aspose.network/releases/aspose.networkV3.5.3b.zip

Hi Iret,

I have tried your beta, looks like the OLE file names of MS office types are extracted, but for pdf and "package" types (e.g. zip), they still carry the generic application name, correct? I did notice that the attachment list is no longer abbreviated, thanks for this fix!

Listed below are what's high on our list, could you let us know when we can expect to get them?

1. Placeholders:

a. insert in place of attachments in RTF messages. (right now, no placeholder of this type is inserted in mht). Please see attached in folder \RtfPlaceholder

b. for all extractable ole objects, a placeholder should be inserted. (right now, sometimes embedded ole object gets extracted but don't have placeholder in the mht). Please see the attached in folder \OlePlaceholder.

2. Unicode message headers: currently if unicode, e.g. Chinese characters, appear in subject line, the characters are not rendered correctly in the mht. Please see attached in folder \Unicode

3. Bug: embedded picture not extractable (I found this occurs if message is in RTF format), please see attached \PictureNotExtracted

4. Bug: some html tables are not rendered correctly in mht. Please see attached in folder \HtmlTable

5. Bug: If attachment is empty, it can't be extracted and not rendered in the attachment list. Please see in folder \EmptyAttachment

Thanks,

Becky

Thanks for your reply.

We have fixed the PDF attachments bug. I will get back to you soon.

Thanks again.

All,

The unicode issue has become a much higher priority. We now have an issue with a client and need a fix to this asap. I wouldnt think this should not be that huge of a fix and arent able to wait weeks.

Issue:

2. Unicode message
headers: currently if unicode, e.g. Chinese characters, appear in
subject line, the characters are not rendered correctly in the mht.
Please see attached in folder \Unicode

Let me know your estimate.

Thanks,

Nathan


Do you guys have a response to this? Like I mentioned we have deadlines on our end and need to know when you can have this to us.

Thanks,
Nathan

Hello,

We have fixed the Unicode subject bug and the empty attachment bug, pdf Ole attachment name

Please get the hotfix build for your verify,

http://www.aspose.com/products/aspose.network/releases/3.5.3/aspose.networkv3.5.3.4.zip

Other bugs and issues are still under investigation and development,

Thanks,

Hi Iret,

Thanks for the fixes! The unicode subject and pdf ole placeholder passed my testing cases.

But the empty attachment bug, I get the following exception when trying to extract the attachment:

System.InvalidOperationException: The data of the attachment is empty.

at Aspose.Network.Outlook.MapiAttachment.Save(String filename)

Another thing is: in the mht output, the header lines (to, from, subject,attachment...) all have extra line breaks between them, is there a way take them out?

Thanks!

Becky

Dear Becky,

We have released a new version of Aspose.Network. The empty attachment bug you mentioned has been fixed. Please check it out.

http://www.aspose.com/Community/Files/54/aspose.network/entry95314.aspx

For the extra line breaks, it is the rendering issue in IE itself, not caused by our mht file.

Thanks,

Hi Iret,

I still get the exception (System.InvalidOperationException: The data of the attachment is empty.)

when trying to save a zero byte attachment.

About the mht output, the following is the source code of a mht generated by Aspose.Network. (it was a real simply email just contain “Hello World!” in the email body)

Message-ID: <D250AB02656B3F42ACDDA335D0F9F60C6CE69E@ANNMX27.na.fti.local>
Date: Thu, 20 Sep 2007 16:24:14 -0400
Subject: Mht output
From: “Bai, Becky”
To: “Bai, Becky”
Content-Type: multipart/alternative;
boundary="------_=_NextPart_001_DEEFAE18.19237C4C"
MIME-Version: 1.0

This is a multi-part message in MIME format.

--------_=_NextPart_001_DEEFAE18.19237C4C
Content-Type: text/plain;
charset=us-ascii

Hello World!

--------_=_NextPart_001_DEEFAE18.19237C4C
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable

<= head>

From: &nbsp=
; &n=
bsp; &nbsp=
; Bai, Be=
cky

Sent: &nbs=
p; &=
nbsp; &nbs=
p; =
Thursday, September 20, 2007 4:24 PM

To: &n=
bsp; &nbsp=
; &n=
bsp; &nbsp=
; Bai, Becky

Subject:<sp=
an> =
&nb=
sp; </sp=
an>Mht output

Hel=
lo World!<span=20
style=3D"font-size:12pt">

<span style=3D"font-siz=
e:12pt">

&#1=
60;<span=20
style=3D"font-size:12pt">

<span style=3D"font-siz=
e:12pt">

<span style=
=3D"font-size:12pt"> <font=20
face=3D"Arial" size=3D"3">

--------_=_NextPart_001_DEEFAE18.19237C4C–

Looks like whatever between gets rendered in browser. Notice the is all over the places? I think these are causing the unnecessary empty spaces.

Thanks!

Yes, for the mht converting, we try to render the same with the MS Outlook's converting msg to mht. So we add extra space into it the html.

Do you think it is not good? Or phaps, what format you want while converting to mht format?

For the empty attachment exception, I am working on it. I will release a hotfix for this issue soon.

Thanks,

Hi Iret,

please see the attached image, I get this from using Outlook to save my email to html. This is the format we would prefer, there is no extra spaces and line breaks.

Thanks!