Hi everyone,
I maintain an addin that listens to Inspector events.
When I receive the Close event, I disconnect from inspector events interface
and release all the references to the inspector (otherwise it will stay
alive).

Recently, I've encountered a scenario when the Close event is fired when the
inspector is not being actually closed:
1. Set Outlook to spell check each sent message(
Tools -- Options -- Spelling, check "Always check spelling before sending")
2. Set the message editor to outlook editor (not word)
3. Compose a new message and write some gibberish in the body
4. click "send"
5. When the spell checker pops-up, click cancel.
6. outlook will ask whether you like to send the message anyway - click no.

when you click "no", the close event will be fired.

After you perform these steps, many addins will stop working for the
inspector (Outlook Spy is one of them).
Probably because the addins release their reference to the inspector and
disconnect the events.

I have checked it with Outlook 2003 SP2.

Do you have any idea how to overcome this problem ? How to identify this
situation ?
When is the right time to release the inspector if not in Close event ?


Thank you in advance
for your suggestions.
Arcady.

Maybe we can count on the fact (which I observe) that when the "real" Close
event fires, inspector's window is already invisible ?
Does anybody know whether it is guaranteed ?


"Arcady" wrote:

Hi everyone,
I maintain an addin that listens to Inspector events.
When I receive the Close event, I disconnect from inspector events interface
and release all the references to the inspector (otherwise it will stay
alive).

Recently, I've encountered a scenario when the Close event is fired when the
inspector is not being actually closed:
1. Set Outlook to spell check each sent message(
Tools -- Options -- Spelling, check "Always check spelling before sending")
2. Set the message editor to outlook editor (not word)
3. Compose a new message and write some gibberish in the body
4. click "send"
5. When the spell checker pops-up, click cancel.
6. outlook will ask whether you like to send the message anyway - click no.

when you click "no", the close event will be fired.

After you perform these steps, many addins will stop working for the
inspector (Outlook Spy is one of them).
Probably because the addins release their reference to the inspector and
disconnect the events.

I have checked it with Outlook 2003 SP2.

Do you have any idea how to overcome this problem ? How to identify this
situation ?
When is the right time to release the inspector if not in Close event ?


Thank you in advance
for your suggestions.
Arcady.

No, that's not guaranteed. Not only that but there's another case you
haven't considered. If WordMail is being used you have to account for the
time taken to reformat the document (email) if the Send is canceled.

The false close event seems to have come into play with an Outlook 2003
update, I first noticed it in the update that changed the version to
11.8010.

I set a flag if Item.Send is entered. At the end of .Send I enable a timer
for about .5 - 1 second. If the timer fires I clear that flag. If the flag
is set I ignore the first Inspector.Close and clear the flag in that event.
If MailItem.Close fires I call my release code and clear the flag.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Arcady" wrote in message
...
Maybe we can count on the fact (which I observe) that when the "real"
Close
event fires, inspector's window is already invisible ?
Does anybody know whether it is guaranteed ?


"Arcady" wrote:

Hi everyone,
I maintain an addin that listens to Inspector events.
When I receive the Close event, I disconnect from inspector events
interface
and release all the references to the inspector (otherwise it will stay
alive).

Recently, I've encountered a scenario when the Close event is fired when
the
inspector is not being actually closed:
1. Set Outlook to spell check each sent message(
Tools -- Options -- Spelling, check "Always check spelling before
sending")
2. Set the message editor to outlook editor (not word)
3. Compose a new message and write some gibberish in the body
4. click "send"
5. When the spell checker pops-up, click cancel.
6. outlook will ask whether you like to send the message anyway - click
no.

when you click "no", the close event will be fired.

After you perform these steps, many addins will stop working for the
inspector (Outlook Spy is one of them).
Probably because the addins release their reference to the inspector and
disconnect the events.

I have checked it with Outlook 2003 SP2.

Do you have any idea how to overcome this problem ? How to identify this
situation ?
When is the right time to release the inspector if not in Close event ?


Thank you in advance
for your suggestions.
Arcady.

Hi Ken,
Thanks for your reply.
I'm not sure I understand the case you are talking about.
I see that inspector's false close event is fired only when isWordMail =
false.
There is also a false item close event fired from a word editor after
sending is canceled (is that what you are talking about?).
That's why I was used to destroy my item related objects only in inspector
close (because once, there was no false inspector close events)

Anyway, it seems that your solution would not work on my machine: in the
scenario I have described, send is not fired at all.

I thought about two solutions (similar to yours):
(I store all open inspectors/items wrappers in a global list)
1. When isWordMail = false, item close event will set a itemCloseFlag and
inspector close event will set a inspCloseFlag. If one of the two events sees
that the other's flag is set, the release code will be called. This will work
if item close fires if and only if the item is really being closed (I think
it is true when isWordMail = false).
2. When inspector close event fires, I set a timer to fire every second. If
the timer sees that the window of the inspector is invisible (I get the hwnd
of the active window in on activate event and save it in inspector's wrapper)
it calls the release code.

What do you think about these solutions ?

Thanks.

"Ken Slovak - [MVP - Outlook]" wrote:

No, that's not guaranteed. Not only that but there's another case you
haven't considered. If WordMail is being used you have to account for the
time taken to reformat the document (email) if the Send is canceled.

The false close event seems to have come into play with an Outlook 2003
update, I first noticed it in the update that changed the version to
11.8010.

I set a flag if Item.Send is entered. At the end of .Send I enable a timer
for about .5 - 1 second. If the timer fires I clear that flag. If the flag
is set I ignore the first Inspector.Close and clear the flag in that event.
If MailItem.Close fires I call my release code and clear the flag.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Arcady" wrote in message
...
Maybe we can count on the fact (which I observe) that when the "real"
Close
event fires, inspector's window is already invisible ?
Does anybody know whether it is guaranteed ?


"Arcady" wrote:

Hi everyone,
I maintain an addin that listens to Inspector events.
When I receive the Close event, I disconnect from inspector events
interface
and release all the references to the inspector (otherwise it will stay
alive).

Recently, I've encountered a scenario when the Close event is fired when
the
inspector is not being actually closed:
1. Set Outlook to spell check each sent message(
Tools -- Options -- Spelling, check "Always check spelling before
sending")
2. Set the message editor to outlook editor (not word)
3. Compose a new message and write some gibberish in the body
4. click "send"
5. When the spell checker pops-up, click cancel.
6. outlook will ask whether you like to send the message anyway - click
no.

when you click "no", the close event will be fired.

After you perform these steps, many addins will stop working for the
inspector (Outlook Spy is one of them).
Probably because the addins release their reference to the inspector and
disconnect the events.

I have checked it with Outlook 2003 SP2.

Do you have any idea how to overcome this problem ? How to identify this
situation ?
When is the right time to release the inspector if not in Close event ?


Thank you in advance
for your suggestions.
Arcady.

You can try them but I don't think that the Inspector would always not be
visible in all cases.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Arcady" wrote in message
...
Hi Ken,
Thanks for your reply.
I'm not sure I understand the case you are talking about.
I see that inspector's false close event is fired only when isWordMail =
false.
There is also a false item close event fired from a word editor after
sending is canceled (is that what you are talking about?).
That's why I was used to destroy my item related objects only in inspector
close (because once, there was no false inspector close events)

Anyway, it seems that your solution would not work on my machine: in the
scenario I have described, send is not fired at all.

I thought about two solutions (similar to yours):
(I store all open inspectors/items wrappers in a global list)
1. When isWordMail = false, item close event will set a itemCloseFlag and
inspector close event will set a inspCloseFlag. If one of the two events
sees
that the other's flag is set, the release code will be called. This will
work
if item close fires if and only if the item is really being closed (I
think
it is true when isWordMail = false).
2. When inspector close event fires, I set a timer to fire every second.
If
the timer sees that the window of the inspector is invisible (I get the
hwnd
of the active window in on activate event and save it in inspector's
wrapper)
it calls the release code.

What do you think about these solutions ?

Thanks.

Hi Ken,
I see now that after the scenrio I have described occures, a false item
close event fires when closing the messages and choosing "cancel" when
prompted to save.
So my first idea won't work.

I'm trying my second solution.
Do you have any sample scenario when the inspector stays visible seconds
after the "real" inspector close event fires ?

Thanks,
Arcady.

"Ken Slovak - [MVP - Outlook]" wrote:

You can try them but I don't think that the Inspector would always not be
visible in all cases.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Arcady" wrote in message
...
Hi Ken,
Thanks for your reply.
I'm not sure I understand the case you are talking about.
I see that inspector's false close event is fired only when isWordMail =
false.
There is also a false item close event fired from a word editor after
sending is canceled (is that what you are talking about?).
That's why I was used to destroy my item related objects only in inspector
close (because once, there was no false inspector close events)

Anyway, it seems that your solution would not work on my machine: in the
scenario I have described, send is not fired at all.

I thought about two solutions (similar to yours):
(I store all open inspectors/items wrappers in a global list)
1. When isWordMail = false, item close event will set a itemCloseFlag and
inspector close event will set a inspCloseFlag. If one of the two events
sees
that the other's flag is set, the release code will be called. This will
work
if item close fires if and only if the item is really being closed (I
think
it is true when isWordMail = false).
2. When inspector close event fires, I set a timer to fire every second.
If
the timer sees that the window of the inspector is invisible (I get the
hwnd
of the active window in on activate event and save it in inspector's
wrapper)
it calls the release code.

What do you think about these solutions ?

Thanks.