Setting destination fields to addresses with initials

[ihertanto]

I have an applet that removes hardcoded addresses from the TO field (if they exist) when a certain option is selected. Here is the source code:

Sub RemoveAddress(addressToRemove, msg)

If InStr(msg.To_, address) Then

Dim newString
newString = Replace(msg.To_, address, “”)

Call GroupWise.ItemSetText(“X00”, itfCC, newString, FALSE)
MsgBox(“TO=” & msg.TO_)

End If

End Sub

If the TO field contains a name in the following format: “John F. Doe” along with the addresses that I want to remove, the name is crossed out and becomes undeliverable.

The same thing happends to random Group names, and occassionally, even names that are formatted without an initial (ie. John Doe). If they are not processed by my script, these same names become deliverable again.

Note: My script works fine with fully resolved e-mail addresses (ie JohnFdoe@mail.com or ‘John F. Doe'<johnFdoe@mail.com&gt, but it would not be feasible to filter each of these names individually.

Why are these addresses undeliverable when they are processed by my script? And is there a workaround for the task that I am trying to accomplish?

Topic

[Support 1a]

Thanks for your post above.

We were able to duplicate the problem as described. Unfortunately, this appears to be a bug in the underlying GroupWise ItemSetText() token. I’ll report this to Novell today.

We’ll spend some time today to see if we can come up with a workaround. I’ll let you know what we find via this thread.

Regards,

Advansys Support

[Support 1a]

Unfortunately we were unable to identify any workarounds to the problem. It would appear the use of these GroupWise tokens breaks the standard address book resolution process that normally occurs.

The only other possible way you could approach the problem would be to use the Object API to create and send the messages. This would involve the creation of a draft message in code, then setting the message properties, including recipients, using the Object API. This is a very different approach, as no user interface is involved, and may not suite your requirements.

We’ve logged the token issue as a bug to be reported to Novell.

Regards,

Advansys Support

[ihertanto]

I appreciate your help. If there’s no suitable workaround then I will put this functionality on hold.

Would you please let me know if/when Novell comes up with a fix?

Thanks again.

[This message was edited by Support 1 on May 24, 2005 at 04:15 PM.]

[Support 1a]

We’ll let you know via this thread and email. I have removed your email address from your post above so it doesn’t get picked up by spammers.

Regards,

Advansys Support

[ihertanto]

Thanks I appreciate that.

[Support 1a]

No problems.

Advansys Support

[Support 1a]

We spent some more time on this issue, and believe we have discovered two cause of the behavior. Whether or not Novell will see these as bugs I’m not sure.

There are two scenarios where this behavior can be seen:

1) Two Address Book entries with the same Display Name value, different email addresses

The problem occurs when you have two address book entries that share the same Display name in different Address Books. One entry is a GroupWise user in the System address book, the other is an external user in a personal address book. This address book may or may not be in the name completion order.

Use ItemSetText() to type the Display Name of the recipient into the TO field. Don’t set the focus to the TO field. When you try to send the message the recipient is crossed out.

It appears the duplicate display names in different address books causes the resolution process to fail. Manually entering the same display name would appear to invoke an internal address book resolution lookup and the send is successful.

2) External Email Address

Define an address book entry in a personal address that has an external (non-GroupWise system) email address. Use ItemSetText() to type the Display Name of the recipient into the TO field. Don’t set the focus to the TO field. When you try to send the message the recipient is crossed out.

In this case it appears address book entry resolution is not occurring. The send succeeds if the text you enter includes the external email address in brackets.

While both scenarios are slightly different, the results suggest that in both cases using the ItemSetText() token does not cause the same recipient resolution process to occur that happen when the same text is typed manually into the TO field. Using ItemSetText() doesn’t cause the individual keystroke events to fire in the same way as when you manually enter text into the recipient box. I’m not sure whether Novell are going to view this as bug.

Regards,

Advansys Support

[ihertanto]

Thanks, I appreciate the reply.

Is there a way then to remove specific addresses from the TO field without having to use the problematic ItemSetText() to re-insert or replace names into the field?
Maybe there is a way to cross out these addresses deliberately so that message aren’t sent there?

Just to further clarify our requirements:
Our applet provides an option to file messages into a central repository. If this option is checked, system addresses are automatically appended to the TO field. If a recipient of this message hits REPLY ALL and then selects the option to NOT file the message, then these addresses should be removed.

Is there no “Remove”-type command that I can use that I might not be aware of?

[Support 1a]

quote:

---

Is there a way then to remove specific addresses from the TO field without having to use the problematic ItemSetText() to re-insert or replace names into the field?
Maybe there is a way to cross out these addresses deliberately so that message aren’t sent there?

---

Unfortunately not. When you are composing a message, the ItemSetText() style tokens are all that is available.

It might be possible to solve your problem by delaying the point at which you add the system addresses. Other customers do a similar thing, except they add the system addresses in the ‘OnSend’ event. This way the users don’t get the opportunity to manually remove the system addresses.

Regards,

Advansys Support

[ihertanto]

Hello,

Has Novell identified this issue as a bug? Do you know if the latest version of Groupwise addresses the faulty ItemSetText() token?

Thanks.

[Support 1a]

This was reported to Novell as a bug prior to GW7. I recall they had difficulty reproducing it in the GW7 client, so it may have been resolved. We have not yet confirmed if this is resolved in the FTF version of the GW7 client just released.

[Author]

Replies