OutlookEX UDF - Help & Support (IV)

[iso23270]

5 minutes ago, water said:

Which version of Outlook do you run?
Which version of AutoIt do you rin?
Which version of the OutlookEX UDF do you use?

Sorry, I should have included that information:

OutlookEX UDF version = 1.3.5
@AutoItVersion = 3.3.14.5
@AutoItX64 = 0
@Compiled = 0
@OSArch = X64
@OSVersion = WIN_10

Outlook version: 2016

[water]

Starting today I will be on vacation for some time. So please don't hold your breath for a solution

[iso23270]

1 minute ago, water said:

Starting today I will be on vacation for some time. So please don't hold your breath for a solution

No problem, take your time. As I said, I can get items if I correctly specify the ReturnProperties (which I need anyway). It just took me a while to sort this out as I expected to get some "good" defaults if I don't specify anything. Maybe the solution is to just add another line for correct properties in Func _OL_ItemFind :

 

; Set default return properties depending on the class of items
    If StringStripWS($sReturnProperties, 3) = "" Then
        Switch $iObjectClass
            Case $olContact
                $sReturnProperties = "FirstName,LastName,Email1Address,Email2Address,MobileTelephoneNumber"
            Case $olDistributionList
                $sReturnProperties = "Subject,Body,MemberCount"
            Case $olNote, $olMail
                $sReturnProperties = "Subject,Body,CreationTime,LastModificationTime,Size"
            Case Else
        EndSwitch
    EndIf

But I'm no expert in outlook items, so this is just a wild guess 🙂

[water]

Seems appointment has no default values and no error handling as well
So it seems sensible to add

• meaningful defaults
• error handling if there are no defaults for a item type

Which defaults would you like to see for appointments?

[water]

How about: Subject,Body,Start,End,Duration,AllDayEvent,BusyStatus?

[iso23270]

It seems sensible to have the same defaults that are returned when using _OL_AppointmentGet, that is:

EntryID,Start,End,Subject,IsRecurring

 

[water]

Done.

[Skysnake]

apropos winmail.dat attachments

I have been testing scenarios where this occur.  I do not have explanations, but I can offer the following. Specifically I use @water's OutlookEX UDF and @mLipok's ADO UDF and QuikcPDF UDF.

Script makes a PDF, from data on an ADO connection, and sends it to Outlook.  The PDF file is created and SAVED to disk, specifically in the @my documents folder.  It is attached from there. Email sent as HTML.

 

Case A

Sent by Outlook to Outlook.  PDF attachment arrives as normal. Opens as PDF on recipient system.

 

Case B

Sent by Outlook to GMAIL.  PDF attachment arrives as winmail.dat.

(Forwarded from gmail to Outlook, the PDF attachment opens normally).

==> in LiveMail the attachment is simply truncated.

Case C

Sent by Outlook to Outlook.  PDF attachment arrives as normal. Sent on to an Apple iOS installation with MS Outlook for Apple.  PDF attachment shows as winmail.dat.

Similar where mail is received on Horde for Android.  Once forwarded to Outlook attachment shows up as PDF.

 

Case D

Sent by Outlook to Outlook.  PDF attachment arrives as normal. Saved to Desktop.  New message created manually and attachment added from Desktop.  Sent on to an Apple iOS installation with MS Outlook for Apple.  PDF attachment opens as PDF on recipient system.

 

Case E

Sent by Outlook to Outlook.  PDF attachment arrives as normal. Saved to Desktop. PDF zipped with 7Zip.  New message created manually and ZIP attachment added from Desktop.  Sent on to an Apple iOS installation with MS Outlook for Apple.  ZIP file shown as such, unzipped content to reveal PDF which opens as PDF on recipient system.

The issue specifically is to automate the creation and attachment of files.

 

I do not want to say that there is a problem with any of the UDFs.  In fact, I think the problem is NOT with the UDFs.  Rather, I guess that the way the various (not Outlook clients) decode the email message may be problematic.  Which does pose the question if there is an issue in Outlook (not the UDF) itself concerning the coding of email messages and their attachments.

 

A possible solution

What I have not tested is creating and saving the PDF somewhere else (ie not My Documents before sending) or auto-zipping the PDF to ZIP before sending, and then sending the ZIP.

 

Any ideas or thoughts are welcome.

Edited April 17, 2019 by Skysnake

[water]

This is described in the wiki where you are pointed to this thread. The post written by @tourism123 seems to have solved the problem.

[water]

Version 1.3.6.0 of the UDF has been released.

Please test before using in production!

For download please see my signature.

[Skysnake]

I have a question about the missing attachments problem (winmail.dat).

The UDF default is set to PlainText. This is not changed.

However, the actual body is HTML. 

Question: Is it possible that format <> body can cause this kind of problem?

 

I have forced my Include to now make the format HTML and body HTML and will be testing shortly. 

Edited August 2, 2019 by Skysnake

[Skysnake]

Another question.

When my script ends, I close the OL object. But, then it also closes by Outlook?

I don't want this to happen and I do not think that is the intention. How do I close the script object, without affecting the MS application? 

Thanks

[water]

In the wiki I have described the winmail.dat problem - does this describe the problem you see?
This problem does not seem to be caused by the OutlookEX UDF.

Edited August 2, 2019 by water

[water]

_OL_Close ends Outlook if it wasn't up and running at _OL_Open time.
You could set

$__bOL_AlreadyRunning = True
_OL_Close($oOL)

to simulate that Outlook hasn't been started by your script.

[Skysnake]

31 minutes ago, water said:

In the wiki I have described the winmail.dat problem - does this describe the problem you see?
This problem does not seem to be caused by the OutlookEX UDF.

All my scripts use HTML body.

I have a script that explicitly sets the format to HTML and it appears that PDF attachments are being delivered correctly.*

I have a another script that uses UDF defaults, assumed to be PlainText and an HTML body.  This script consistently gives problems with PDF attachments.

 

Please see this:

https://support.microsoft.com/en-us/help/290809/how-e-mail-message-formats-affect-internet-e-mail-messages-in-outlook

Microsoft seems to indicate that Outlook defaults to RTF format?  And they acknowledge that this may be the root of the problem? Or am I reading too much here?

 

* Footnote - it is difficult to test all the different delivery destinations as I have to ask friends/clients to report on what they receive. And it is a lot like trying to hit a moving target.

[water]

I suggest to always set the format property to the correct format:

BodyFormat=$olFormatHTML
HTMLBody="... HTML mail ..."

So Outlook doesn't use a default for BodyFormat or has to guess which format to use.

[Lo-Pan]

Hello All,

 

I have a need for a migration project to use this tool but when I download the latest version 1.3.6.0 every program I use to extract it says its an invalid zip file.  I have tried it from 3 different computers and tried to use built in zip in windows and winrar,winzip to extract.  

Can you please look and repost a good zip for me?  

 

Thank You!

[Jos]

Try using 7-zip as the build in version doesn't support all compression methods.

Jos 

[Lo-Pan]

That was it 7zip can do it.  if that is the ONLY one that can unzip maybe a note on the D/L page might be useful I can't be the only person with that has had this problem.  Appreciate the help.  Thank You!

[water]

I create those ZIP files by simply moving the content to a ZIP-compressed folder. So it should all be Windows compatible.
No idea why it doesn't always work