Support 1a

[Support 1a]

This depends on when you are trying to extract this information, and from what.

Assuming you mean a message that is in your mailbox (i.e. a message you have received), use the Message.Recipients collection to iterate through each Recipient object. Each Recipient object has a property TargetType, which indicates the type of recipient you are dealing with. Possible values are:

0 – To. A primary recipient.

1 – Carbon Copy. A secondary recipient.

2 – Blind Copy. This address is hidden to all users except the sender and the receiver.

I hope this helps. Please let me know if I have misinterpreted your question.

Advansys Support

[Support 1a]

Change line number 165 from:

RecHolder = RecHolder & RecipientEntry.EmailAddress & “, ”

to

RecHolder = RecHolder & RecipientEntry.DisplayName & “, ”

I hope this helps.

Advansys Support

[Support 1a]

This issue was due to a beta version of the applet being used. The release version does not exhibit this problem.

[Support 1a]

I suspect you have either a corrupt applet, or an applet that contains no source code. The assert failure you mention indicates the latter, and has been changed to handle this situation more gracefully in SP1, which will be made available very early in the new year.

You could either check each applet manually using a text editor, looking for an empty XML CDATA tag, or the easier option would be to ZIP all your applets and email them to support@advansyscorp.com, where we will locate the offending applet for you.

We will be notifying all users when SP1 becomes available.

Advansys Support

[Support 1a]

Let me have a look and get back to you.

Advansys Support

[Support 1a]

As you mentioned, I don’t think the delivered status is accessible via the Object API. I did write something years ago that actually parsed the properties text of an item to determine this kind of information – very unpleasant.

We will have a look to see if it is possible to add support for this in the future (perhaps SP1).

Advansys Support

[Support 1a]

Dave,

There are a couple of Object API methods of the Message object available via the Formativ applet language (including NotifyWhenOpened). However, my understanding is that these are of little use once a message leaves the confines of a GroupWise system.

You may wish to confirm this with Novell.

Advansys Support

[Support 1a]

You may wish to try the following syntax:

(MAIL) AND (READ OR OPENED) AND (<ABC, String> DOESNOTCONTAIN “”X””)

This may or may not work, depending on your application – this does a ‘not contains’, as opposed to ‘does not equal’, which I’m not sure is possible with the filter syntax.

If this is not acceptable, you may need to perform two processes: one to filter on MAIL and READ or OPENED, then iterate through the resulting message list and process only those messages that do not contain a single ‘X’ in the ABC field.

I hope this helps.

Advansys Support

[Support 1a]

Great to hear it works OK. I’ll advise Novell of the problem with the documentation.

Advansys Support

[Support 1a]

Try BEGINSWITH instead of BEGINS WITH, i.e

sFilter = “(MAIL) AND (<MyCustomField, STRING> BEGINSWITH “”Opened””)”

You may need to call the Refresh method of the messagelist you apply the filter to prior to calling FindMessages, i.e:

code:

---

Set iMsgs = GroupWise.Account.MailBox
iMsgs.Refresh
Set iMsgList = iMsgs.FindMessages(sFilter)

---

Advansys Support

[Support 1a]

Using find with custom fields requires you to specify both the field name and type. The syntax is “<[Field Name], [Data Type]>”.

Assuming your custom field stores string data, your filter would be:

sFilter = “(MAIL) AND (<MyCustomField, STRING> CONTAINS “”Opened””)”

I hope this helps.

Advansys Support

[Support 1a]

Hello,

I do not believe GroupWise exposes any drag and drop event handling, either via the Object API, Token API or any other mechanism. This is certainly an ommission. Unfortunately Formativ is only able to take advantage of the underlying features GroupWise actually exposes.

My understanding is that the GroupWise XIS API _may_ provide change event handling. However, if and when this API is made available is unknown at this stage.

This only leaves the TPH API. As you have written a TPH DLL to trap all tokens, you should be able to determine if this is going to provide at least some of the functionality you require.

Advansys Support

[Support 1a]

Thank you for your question regarding the Spam Filter macro. We are currently investigating this issue, and will reply shortly.

Advansys Support

[Author]

Replies