 Page [ 1 2 3 4 5 6 Next >> ]
|
|||
| Outlook Form Design Printer Friendly Version | |||
|
Designing custom Outlook forms and form regions and writing code for them | ||
| Topic | |||
|
Item.Close olSave Now Broken in OL11 as well asOL12?
Has anybody else applied the very latest Security Update for Outlook 2003, released on 1/9/07? If so, are you experiencing the same improper behavior that was already present in OL12 where calling Item.Close olSave (or in VBScript, Item.Close 0) yet the user is still prompted to save changes or not? I have verified on several machines, all running OL11 (version 11.8010.8107) that the problem does not exist but after applying the security update (now version 11.8118.8107) that the problem does exist. If anybody from MS Outlook dev team reads this - will there be an immediate hotfix or patch released to restore the proper functionality in OL11? Is this going to get fixed in OL12? Thanks for all input, although regretably I think I already know the solution to the problem is don't call the method or educate users that the prompt will appear and they should click on Yes. Tom Dougherty 11-Jan-2007 07:40 |
||
|
|
Sue Mosher
11-Jan-2007 19:43
Tom, what procedure are you calling Item.Close from? |
||
|
|
Tom Dougherty
11-Jan-2007 20:59
Sue, In the close event of a Conatct item. I haven't touched my code in this particular form in quite a while and it's been working fine using Item.Close 0 - the form closes and saves the contents without prompting the user, but post appkling the latest Security Update the prompt dialog started to appear just like the known issue in OL12. Have you heard anything about it from MS? |
||
|
|
Sue Mosher
11-Jan-2007 21:10
You shouldn't call Close for a Close or Write event. It has always been a source of problems. Can you provide a link to the security update you applied? That will make it easier ofr us to see if more info is available. |
||
|
|
Tom Dougherty
12-Jan-2007 07:09
Security Update for Outlook 2003 (KB924085) is the item listed in Microsft Update history but a search at microsoft.com retruns no records yet. I took your advice and switched the line code in item_close from item.close 0 to item.save and the behavior is back to normal. I haven't tested this on OL9 or OL10 but it works in OL11 (and maybe will coorect the behavior in OL12 I've dealing with). I really appreciate your input but I'm puzzled as to why this code has worked for a long time on more then a 1,000 desktops without any problems and then this latest security patch caused the problem. The reason for the original code is there is conditional logic in the close event of this form that could take any of 5 different actions, 3 of which result in item.close 1 (discard changes without prompt) or item.close 0 (save.changes without prompt). I'll also have to test the lines where the changes should be discarded. Thanks! |
||
|
|
Kinga Parajdi
12-Jan-2007 09:32
I have the same problem. I was waiting for a solution for this problem under Ol12 and I get the same problem under Ol11 too. :( This happened since the last ms updates. It's causing major problems with our customers, still looking for a solution. |
||
|
|
Sue Mosher
12-Jan-2007 10:36
Kinga, it would probably be helpful if you described in more detail what "the same problem" means to you. A code snippet would be a good start. |
||
|
|
Tom Dougherty
13-Jan-2007 10:13
I have successfully used Item.Save instead on the previous Item.Close 0 and then let the close event complete without a problem. As Sue, pointed out this is a better coding practice and it does remove the prompt the user was seeing. The remaining issue is what to do when I've been calling Item.Close 1 (olDiscard) where I do not want the changes saved and I do not want the user prompted as it's confusing. I have verified the line works in the item_close event in OL9, OL10 and OL11 (pre the service update mentioned before) but does NOT work correctly in OL11, post service update, nor does it work in OL12. Sue, I understand you saying that calling item.close in the close event can be problematic, but was not the method designed to allow programmatic control over the very circumstances we are discussing? While I'm fine with the item.save in lieu of item.close 0 change, can you offer an alternative to item.close 1 to prevent changes from being saved programmatically? Thank you! |
||
|
|
Sue Mosher
13-Jan-2007 17:10
The usual way to block changes from being saved is to cancel the Write event by setting the return value of the Item_Write event handler to False. I haven't had a chance to test OL 2003 with the new update, but will try to do that soon. |
||
|
|
Kinga
17-Jan-2007 11:45
Sue, I am talking about this problem: http://www.outlookcode.com/threads.aspx?forumid=3&messageid=20694 I can't use methode item.close anymore. (http://support.microsoft.com/kb/929593 Some methods no longer work in the Inspector_Close event or in the Item_Close event In versions of Outlook earlier than Outlook 2007, a crash may occur if you use one of the following methods in the Inspector_Close event or in the Item_Close event: • The Inspector.Close method • The Item.Close method |
||
|
|
Sue Mosher
17-Jan-2007 12:10
Kinga, you still have not stated clearly what your problem is under Outlook 2003. We know about the general Outlook 2007 problem and as the KB article says, calling the Close method from a Close event has long been a problem in all versions. That doesn't tell us anything, though, about your specific Outlook 2003 issue. |
||
|
Page [ 1 2 3 4 5 6 Next >> ]
|
|||
| Post a new message to this topic. name email  |