OK, I've made the changes suggested. I also realised that the
Item_Write event of the original form also fires upon a Save, which
was apparently the cause of the problem. I've got it fixed and
everything working shipshape. This completes my requirement.
A couple of points:
1. I thought the Item object is implicit in references to properties
in script, which was the reason I was leaving it out.
2. The message form is published to a public folder. I presume that
when the item is created, code is executed since the Item is not yet
saved outside the public folders. You are right that once the
Correspondence message reaches the user's Inbox, code is not
executed. I would expect this since forms published in a public
folder are trusted, while the one-off form in the user's Inbox (as a
result of sending with form definition) is not. Or perhaps the admin
has set up the Outlook Security settings appropriately...
Thanks for your quick responses which got this project completed in
short order.
--
Sriram
Checking "Send form definition with item" ensures that code won't run on any items, new or received. I can't imagine why a MsgBox would fire under that condition.
In this statement:
set myItem = _
Application.GetNamespace("MAPI").GetItemFromID(Mileage,BillingInformation)
you should use the correct Item.prop_name syntax to get the property values:
Set myItem = _
Application.Session.GetItemFromID( _
Item.Mileage, Item.BillingInformation)
and then check whether the item exists, something like:
If Not myItem Is Nothing Then
If Item.Body <> "" Then
strNewHistory = item.Body & chr(13) & chr(10)
myItem.Userproperties("History") = _
strNewHistory & myItem.Userproperties("History")
MsgBox myItem.Userproperties("History")
myItem.Save
myItem.Close
Set myItem = Nothing
End If
End If
sriramna said:
Sure, code is running in the Message form - various MsgBox statements
confirm that.
The only quirk is that the value of the History property does not
change even with the Save statement. The existing text is retained.
Yes, the "Send Form Definition" is checked, so code will not execute
in the recipient's Inbox, but that is not an issue. The code does get
processed while sending.
On Mar 26, 5:30 pm, "Sue Mosher [MVP-Outlook]"
Are you sure the code is running in the message form? Did you publish it with the Send Form Definition with Item box unchecked?
Duh... except for wrestling with a typo, I've got it working. But
I've run up against an unexepected problem - the writeback to the
original (Task) form field does not "take" presumably because it is
already open in another Inspector:
In the original form:
===>
Function Item_CustomAction(ByVal myAction, ByVal myResponse)
Select Case myAction.Name
Case "Correspondence"
myResponse.Mileage = EntryID
myResponse.BillingInformation = Parent.StoreID
myResponse.To = Userproperties.find("FromID").Value
myResponse.display
Case Else
End Select
and in the Correspondence form:
Sub Item_Send()
dim strHistory
set myItem =
Application.GetNamespace("MAPI").GetItemFromID(Mileage,BillingInformation)
' store message and write it into the log
strHistory = myItem.userproperties.find("History").Value
If (item.body <> "") then
myItem.Userproperties("History") = item.Body & chr(13) & chr(10) &
strHistory
myItem.Save
End If
End Sub
Problem here => the user field History is _not_ updated! Any pointers
why? Closing the original Task form before hitting Send also does not
appear to help.
On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
You would need some kind of identifier. THe easiest solution might be be to have the CustomAction event handler on the task set the value of the new message's BillingInformation property to the EntryID of the original task. That way, the message form's code can get the ID from its own BillingInformation property and then use Namespace.GetItemFromID to return the message.
I have a new email form created by a custom action in a public folder-
based form derived from IPM.Task. I need to record the plain-text
contents of the new email for reference back in the originating Task
form, just before it is sent.
It is easy enough to get a handle on the new mail form in the script
of the original Task form, but how do I do it the other way (locate
the Task item which spawned this item, from script in the email)?
The problem is that the CurrentFolder could be anything, since the
user is opening the Task Item through a hyperlink in a mail in his
Inbox. Therefore even to search the items in a folder, I will have to
find a way of locating the public folder containing the Task, in the
email script. Short of hard-coding the path, what are the options?
