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?

--
Sriram

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.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"sriramna" wrote in message ups.com...
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?

--
Sriram

Thanks for the tip. I presume the GetItemFromID method will need the
StoreID parameter also, since the folder could be anywhere in the
public folder tree.

So I've gotten upto here in the custom action code:

Function Item_CustomAction(ByVal myAction, ByVal myResponse)
Select Case myAction.Name
Case "Correspondence"
myResponse.BillingInformation = EntryID
myRepsonse.Mileage = Parent.StoreID
myResponse.display
Case Else
'Do nothing
End Select
End Function

This errors out with "Object Required: Parent.StoreID". Anything
wrong with the code?

The Correspondence item is based on IPM.Note and addressed like a
Reply. The originating form has been duly saved to the folder before
triggering the custom action.

--
Sriram


On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx



"sriramna" wrote in oglegroups.com...
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?

Item.Parent, not Parent.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"sriramna" wrote in message oups.com...
Thanks for the tip. I presume the GetItemFromID method will need the
StoreID parameter also, since the folder could be anywhere in the
public folder tree.

So I've gotten upto here in the custom action code:

Function Item_CustomAction(ByVal myAction, ByVal myResponse)
Select Case myAction.Name
Case "Correspondence"
myResponse.BillingInformation = EntryID
myRepsonse.Mileage = Parent.StoreID
myResponse.display
Case Else
'Do nothing
End Select
End Function

This errors out with "Object Required: Parent.StoreID". Anything
wrong with the code?

The Correspondence item is based on IPM.Note and addressed like a
Reply. The originating form has been duly saved to the folder before
triggering the custom action.

--
Sriram


On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.


"sriramna" wrote in oglegroups.com...
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?

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(Mil eage,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.

--
Sriram

On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx



"sriramna" wrote in oglegroups.com...
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?

Are you sure the code is running in the message form? Did you publish it with the Send Form Definition with Item box unchecked?

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"sriramna" wrote in message oups.com...
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(Mil eage,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.

--
Sriram

On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx



"sriramna" wrote in oglegroups.com...
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?

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.

--
Sriram

On Mar 26, 5:30 pm, "Sue Mosher [MVP-Outlook]"
wrote:
Are you sure the code is running in the message form? Did you publish it with the Send Form Definition with Item box unchecked?

"sriramna" wrote in ooglegroups.com...
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(Mil eage,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.

--
Sriram

On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"sriramna" wrote in oglegroups.com...
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?- Hide quoted text -

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(Mil eage,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
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"sriramna" wrote in message ups.com...
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.

--
Sriram

On Mar 26, 5:30 pm, "Sue Mosher [MVP-Outlook]"
wrote:
Are you sure the code is running in the message form? Did you publish it with the Send Form Definition with Item box unchecked?

"sriramna" wrote in ooglegroups.com...
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(Mil eage,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.

--
Sriram

On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.

"sriramna" wrote in oglegroups.com...
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?- Hide quoted text -

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

On Mar 26, 6:56 pm, "Sue Mosher [MVP-Outlook]"
wrote:
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(Mil eage,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
--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"sriramna" wrote in oglegroups.com...
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.

--
Sriram

On Mar 26, 5:30 pm, "Sue Mosher [MVP-Outlook]"
wrote:
Are you sure the code is running in the message form? Did you publish it with the Send Form Definition with Item box unchecked?

"sriramna" wrote in ooglegroups.com...
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(Mil eage,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.

--
Sriram

On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.

"sriramna" wrote in oglegroups.com...
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?

1) Good coding practice means using implicit parent objects, especially when you're asking someone else to decipher your code.

2) No, you should never check "Send form definition with item" if you want code to run. There is no concept of "trusting" forms specifically in public folders.

--
Sue Mosher, Outlook MVP
Author of Configuring Microsoft Outlook 2003
http://www.turtleflock.com/olconfig/index.htm
and Microsoft Outlook Programming - Jumpstart for
Administrators, Power Users, and Developers
http://www.outlookcode.com/jumpstart.aspx

"sriramna" wrote in message oups.com...
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

On Mar 26, 6:56 pm, "Sue Mosher [MVP-Outlook]"
wrote:
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(Mil eage,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" wrote in oglegroups.com...
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.

--
Sriram

On Mar 26, 5:30 pm, "Sue Mosher [MVP-Outlook]"
wrote:
Are you sure the code is running in the message form? Did you publish it with the Send Form Definition with Item box unchecked?

"sriramna" wrote in ooglegroups.com...
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(Mil eage,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.

--
Sriram

On Mar 26, 1:00 am, "Sue Mosher [MVP-Outlook]"
wrote:
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.

"sriramna" wrote in oglegroups.com...
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?