Manipulate default behaviour of new item button for public folders?

  • Thread starter Thread starter Oliver Giesen
  • Start date Start date
O

Oliver Giesen

Hi all!

Is it possible to manipulate the default behaviour of the existing New
Item button? Is there maybe some way to hook into its click event or
preferably some other ?

I've got an addin that can move sent messages into a public folder when
they were sent while being located on that folder, so effectively, when
seen purely from a user's perspective, I am able to post mail messages
to that public folder - something that is not intended by Outlook as
such which is why the default message class for public folders is
IPM.Post rather than IPM.Note. That is basically what I want to change.
I want the New button to invoke a new mail inspector rather than a post
inspector.

Is this possible at all or would I have to create my own toolbar
button? I'd rather avoid that because I think it would confuse users
more than it would help. After all, this is about those users that
already feel uncomfortable about simply using Ctrl-N or the New
button's dropdown...

Any ideas or pointers?

Cheers,

Oliver
 
You know, that behavior was standard with Exchange 5.5 and invoked howls
from developers when the default was changed to IPM.Post. There are hot
fixes and fixes for that behavior for post-SP fixes.

An alternative if you can't update your Exchange server would be to run an
event sink on that folder that changes the message class of any items added
to the folder from IPM.Post to IPM.Not. That's way better than what you are
trying to do, and it's doable :)

Another alternative would be to run an ItemAdd handler on the Items
collection of that folder and change the message class there if your admins
won't let you put an event sink on the folder.

The sink method has the advantage that Outlook doesn't have to be running
with the addin for things to work, since the sink runs on the server.
 
Ken said:
You know, that behavior was standard with Exchange 5.5 and invoked
howls from developers when the default was changed to IPM.Post. There
are hot fixes and fixes for that behavior for post-SP fixes.
Click to expand...

Is that really the same thing? I had seen those posts and KB articles
but I understood them to be about something else, i.e. that messages
arriving at the folder from the outside would be stored as IPM.Post .
That however is not what's happening here. Incoming messages are
handled as IPM.Note alright.
I even think it makes sense to some extent to change the default to
Post when located on a non-mail-enabled folder. It's really only the
mail-enabled ones where I would like it better to default to IPM.Note.

An alternative if you can't update your Exchange server would be to
run an event sink on that folder that changes the message class of
any items added to the folder from IPM.Post to IPM.Not. That's way
better than what you are trying to do, and it's doable :)

Another alternative would be to run an ItemAdd handler on the Items
collection of that folder and change the message class there if your
admins won't let you put an event sink on the folder.

The sink method has the advantage that Outlook doesn't have to be
running with the addin for things to work, since the sink runs on the
server.
Click to expand...

I really think you must be talking about a different issue than I do. I
don't think the new message gets added to the folder even before I send
or save it, or does it? ItemAdd definitely doesn't fire just from
invoking a new item inspector, I can tell that much.

Cheers,

Oliver
 
ItemAdd would fire when the item was saved to the folder. I missed what you
meant about opening a new Inspector. You're right, a sink or ItemAdd
wouldn't help in that case.

You can't change the behavior of New, so you might need a custom button that
opens a new mail item in that folder. Or to train users to use Ctrl+N to
open a new mail item. However, that would save into the default Drafts
folder, so that would need extra code there to move it to the public folder.

It might even be best just to pre-address mail items opened from a button to
the PF and have the users send to that folder and not try to post there.
 
Ken said:
ItemAdd would fire when the item was saved to the folder. I missed
what you meant about opening a new Inspector. You're right, a sink or
ItemAdd wouldn't help in that case.

You can't change the behavior of New, so you might need a custom
button that opens a new mail item in that folder. Or to train users
to use Ctrl+N to open a new mail item.
Click to expand...

I have no leverage to train users anything here. This is a shareware
product that is marketed via Share-it. It's just that the request for
that functionality pops up rather frequently from users of that addin
and I was thinking whether I might be able to put that in to erase that
hindrance for them.

However, that would save into
the default Drafts folder, so that would need extra code there to
move it to the public folder.

It might even be best just to pre-address mail items opened from a
button to the PF and have the users send to that folder and not try
to post there.
Click to expand...

Well, the messages that the users send do not get sent to the folder,
technically speaking. They're just regular email messages addressed to
outside recipients. It's our addin that moves them there from the
user's Sent Items folder after they have been sent (it also sets the
sender to the folder's address). That's why I was wording it as "from a
user's perspective" in my last post.

Anyway, thanks for confirming my worst fears. ;)
Looks like an extra button would be the only way out then.

<mumble>Or maybe I could hook into the NewInspector event and abort if
it's a Post item and then recreate a Mail item... I'll try something
like that first, I think...</mumble> ;)

Cheers,

Oliver
 
Back
Top