OutlookEX UDF: Example scripts

[Confuzzled]

MsgBox shows type as blank, with modified code shows hex value 0x00000000.

Having a 'normal' mail item open shows exactly the same thing.

I slightly modified your code as follows to confirm that it was actually displaying the correct mail/RSS item - it is showing the correct subject line for the open mail item as well as RSS item respectively.

#include <OutlookEX.au3>
Global $oOL = _OL_Open()
Global $oItem = $oOL.ActiveInspector.CurrentItem
MsgBox(0, "Current item properties", "Type: " & $oItem.Type & ", Hex value " & Hex($oItem.Type) & ", Error code " & @error & ", Subject is " & $oOL.ActiveInspector.CurrentItem.Subject)

Have I overlooked something in my passed parameters in  _OL_ItemFind?

 

(Note: Bit bamboozled by some of the bitwise checking in lines 2909-2946 in the function _OL_ItemFind in OutlookEX.au3 to do some debugging)

Edited April 3, 2017 by Confuzzled

[water]

My bad. "Type" was wrong, should be "Class".

#include <h:\tools\autoit3\outlookex\OutlookEX.au3>
Global $oOL = _OL_Open()
Global $oItem = $oOL.ActiveInspector.CurrentItem
MsgBox(0, "Current item properties", "Class: " & $oItem.Class & ", Hex value " & Hex($oItem.Class) & ", Error code " & @error & ", Subject is " & $oItem.Subject)

I get 43 for a mail item. What do you get for a RSS item?

[water]

1 hour ago, Confuzzled said:

Note: Bit bamboozled by some of the bitwise checking in lines 2909-2946 in the function _OL_ItemFind in OutlookEX.au3 to do some debugging

$iFlags can be a single value (1, 2 or 4) or a combination of any  of them (3, 5 or 6). The Bit operation simply checks which of the single values was used.

[Confuzzled]

For 'normal' mail item, class is '43' or  0x0000002B, and for an RSS item, class is '45', or 0x0000002D - bingo!

Quote

; OlObjectClass Enumeration. Constants representing the different Microsoft Office Outlook object classes.
; See: http://msdn.microsoft.com/en-us/library/bb208118(v=office.12).aspx
Global Const $olMail = 43 ; Represents a MailItem object

Do we need a new  $olRSSItem object = 45 in the OlObjectClass Enumeration constants in OutlookExConstants.au3? I note the (v=office.12) in the documentation reference, whereas my version of Outlook is version 16.

 

Testing:

I added "Global Const $olRSS = 45  ; Represents a RSSItem object" to the code just after calling the includes and modified the code for the _OL_ITemFind selection

from

Global $ItemResult = _OL_ItemFind($oOutlook, StringMid($FolderResult[$FolderIndex],3), $olMail, "", "", "", "Subject","[Subject]", 1)

to

Global $ItemResult = _OL_ItemFind($oOutlook, StringMid($FolderResult[$FolderIndex],3), $olRSS, "", "", "", "Subject","[Subject]", 1)

Running it now doesn't return the mail items it did previously, but when it hits the RSS folder tree, it lists all the items found for all items in the subfolders, each sorted within each subfolder in the first pass, and then lists each subfolder items sorted within the subfolder again, sorta recursive.

viz folder structure:
 

Quote

/RSS Feeds << Main RSS folder

/RSS Feeds/FolderA, contains RSS items A4, A2, A3, A1 (out of alpha order)

/RSS Feeds/FolderB, contains RSS Items B1, B2

Output report contains
 

Quote

 

 Folder: \\-mailbox-\RSS Feeds\
  Subject:

A1

A2

A3

A4

B1

B2

 Folder: \\-mailbox-\RSS Feeds\FolderA
  Subject:

A1

A2

A3

A4

 Folder: \\-mailbox-\RSS Feeds\Folderb
  Subject:

B1

B2

 

 

 

This means the items are only sorted within each subfolder, not the entire object that is returned on the RSS tree first pass.

I note _OL_ItemFind takes an excessive amount of time to process all items in a folder, even if it doesn't find any of the relevant class. Could a test for ItemsFound.Count = 0 at the beginning of the loop bypass this?

As an aside, I also note that items found in the RSS incoming folders and moved to another folder by previously defined Outlook rules have now got the class 43, whereas items manually moved by me retain the class 45. This just compounds the deep hatred for all things Microsoft Outlook, especially Rules not working, hidden 'synchronisation error' messages in the tens of thousands, and corrupt mail items found on many systems I have had the misfortune to be asked to have a look at.

Has the RSS (also called SyndicationFeed) class type been omitted from the relevant Microsoft documentation for more recent versions of Outlook?

Edited April 3, 2017 by Confuzzled

[water]

6 minutes ago, Confuzzled said:

Has the RSS class type been omitted from the relevant Microsoft documentation for recent versions of Outlook?

If you check the OlObjectClass enumeration you will see that value 45 has always been set to olPost. I wasn't able to find a class for RSS. So I think we should stick to class "Post".

[Confuzzled]

Can we add the Outlook version actually running on the system to the _OL_VersionInfo function, or a similar subroutine?

[water]

Sorting Problem:
The function sorts on the returned collection of found items for the (sub)folder. 
To sort on folder and subfolders the sort routine would need to be rewritten.

For the time being I suggest to disable sorting when calling the function and sort the whole array yourself after having called _OL_ItemFind.

[water]

33 minutes ago, Confuzzled said:

Can we add the Outlook version actually running on the system to the _OL_VersionInfo function, or a similar subroutine?

#include <OutlookEx.au3>
Global $oOL = _OL_Open()
MsgBox(0, "Version", $oOL.Version)

This returns the needed Information.
Plus: I will add the Outlook version to the COM error handler plus function _OL_VersionInfo for the next release of the UDF (if possible).

Edited April 3, 2017 by water

[Confuzzled]

13 minutes ago, water said:

If you check the OlObjectClass enumeration you will see that value 45 has always been set to olPost. I wasn't able to find a class for RSS. So I think we should stick to class "Post".

Has someone checked that class "45" actually works for olPost? Maybe I found the wrong bug...

I'll need to re-evaluate the use of  _OL_FolderTree if it is recursively getting the same items twice. 

Many thanks for the prompt assistance. I look forward to the revised functions and documentation updates.

Edited April 3, 2017 by Confuzzled

[water]

8 minutes ago, Confuzzled said:

Has someone checked that class "45" actually works for olPost? Maybe I found the wrong bug...

You get class 45 when you check an RSS item. The enumeration tells us that 45 is named olPost. I take it that 45 is a General class for RSS items and maybe others.

[water]

About the multiple Posts Problem: https://social.technet.microsoft.com/Forums/office/en-US/2a179130-b38d-4201-93f4-ef08d4fcf641/outlook-2010-and-rss-feedsmultiple-copies-of-posts?forum=outlook
Does this describe the problem you encounter?

[water]

Quote

I note _OL_ItemFind takes an excessive amount of time to process all items in a folder, even if it doesn't find any of the relevant class. Could a test for ItemsFound.Count = 0 at the beginning of the loop bypass this?

When using parameter $sRestrict then Outlook does the searching and only returns the found items ==> faster
When using parameters $sSearchName and $sSearchValue then _OL_ItemFind processes every item in the (sub)folder ==> slower

[Confuzzled]

The .version clause worked! Thanks.

https://msdn.microsoft.com/en-us/library/office/ff869495.aspx describes the PostItem object. Nary a mention of RSS 2.0

On the duplicate posts issue: I haven't been getting the duplicate problem with duplicate RSS items being downloaded (wow - six years and still unsolved), just with the recursive list returned by _OL_ItemFind as it hits the entire folder tree the first go, and then processes each subfolder again in the loop. The duplicates are in the items returned, not that there are actually duplicate items.

How goes that saying? Compile, run, curse. Recompile, rerun, recurse...

 

Sounds like a little utility coming up to delete duplicate items: find, match and delete (for all classes, including PostItem ones).

 

The tens of thousands of hidden Synchronisation log error messages I suspect are caused by corrupt Outlook pst and ost files and timing issues. I will post an utility a little later that reports on how many are found on a system later in another thread.

I'll check out the $sRestrict options.

 

Again, many thanks for your prompt suggestions. Microsoft support and software development could probably learn a thing or two.

 

Edited April 3, 2017 by Confuzzled

[water]

The function processes the tree just one time. First all items in the start folder, then recursevely all subfolders and their items.
Do you get the same strange result when processing the inbox?

[Confuzzled]

9 hours ago, water said:

The function processes the tree just one time. First all items in the start folder, then recursevely all subfolders and their items.
Do you get the same strange result when processing the inbox?

Yes and No. Strange results only happens on RSS  folders that have subfolders (using class $olPost) where the root RSS folder has each subfolder items listed for it, followed by the listing of items in subfolders individually, but not on mail folders that have subfolders (using class $olMail), where the results work as expected.

 

Edit: Last parameter in _OlFind is "1" in my code - should be "" - works OK when the line is altered to :

Global $ItemResult = _OL_ItemFind($oOutlook, StringMid($FolderResult[$FolderIndex],3), $olPost, "", "", "", "Subject","[Subject]", "")

Wonder why not an issue with $olMail???

Edited April 4, 2017 by Confuzzled
Unbugged

[water]

Blank isn't a valid value for $iFlags. Could you please change the value to 1 and check if this changes the result?

Global $ItemResult = _OL_ItemFind($oOutlook, StringMid($FolderResult[$FolderIndex],3), $olPost, "", "", "", "Subject","[Subject]", 1)

 

[Confuzzled]

It is the '1' that is causing recursive activity. Should I use "0"?

[water]

Wether you want to use 0 or 1, use a number (e.g. 0) and not a string (e.g. "0")

[water]

Version 1.3.2.0 of the UDF has been released.

Please test before using in production!

For download please see my signature.

[water]

Version 1.3.3.0 of the UDF has been released.

Please test before using in production!

For download please see my signature.