CODEWITHSUNDEEP
vbaoutlooktimestamp
sancho.s ReinstateMonicaCellio
sancho.s ReinstateMonicaCellio

Reputation: 15641

Outlook VbaProject.OTM timestamp is not updated upon changing

I have some macros in VbaProject.OTM. Once in a while, I update the code, but the timestamp does not change. I did not check whether the file size changes.

This, this and this report similar observations.

Is this behavior expected?
If not, any idea on what could the problem be?

The first link above shows a couple of workarounds, but I meant to understand the cause for this, and to find a solution to revert this behavior (if possible), instead of workarounds.

Upvotes: 4

Views: 1578

Answers (3)

sancho.s ReinstateMonicaCellio
sancho.s ReinstateMonicaCellio

Reputation: 15641

None of the following appears to be documented, but based on the experience collected from posts already listed in the OP. More solid information might be posted.

Is this behavior expected?
No. This is quite different from what many people would expect.

If not, any idea on what could the problem be?
It appears that this behavior is standard in Outlook (i.e., not something that I see in my system due to configuration issues). So, the "problem" is how Outlook is designed.

... I meant to... find a solution to revert this behavior (if possible)...
There appears to be none.

... instead of workarounds.
As mentioned here and in the OP.

PS: Since none of the two workarounds proposed appear to be options in some cases, one may try to write a macro that would execute a shell command with touch ... (or the like), to set the modification time. It will likely find that VbaProject.OTM is in use, so one would have to deal with that too. Not a trivial task.

Upvotes: 1

Christian
Christian

Reputation: 79

It gets better. None of the "tell me when a file changes" features in Windows, namely FindFirstChangeNotification() and ReadDirectoryChangesW() will report when the file is saved, unless the size changes, and that doesn't happen unless a lot of code is added. I just had to drop in 64 K of comments to get it to change.

procmon shows write operations, but there is no operation to change the time stamp. I don't quite get how they manage to keep the file time the same when the default behavior is to update it every time the file is written to.

This is not just a problem when you want to distribute macros by distributing the file (which you really shouldn't, Microsoft is correct there; the internal structure of the file might change with Outlook versions or even individual updates). It is also guaranteed grief when you reinstall or move computers and find out too late that the copy in your roaming user profile is ancient ...

My personal workaround is to have something in Startup that touches the file. That way, it's always copied.

The cause, btw, is either of the two mentioned at http://blogs.msdn.com/b/oldnewthing/archive/2011/08/12/10195186.aspx. Outlook is using memory-mapped IO, and it may well also do the SetFileTime() thing; I'm not sure if procmon would see that.

Upvotes: 3

David Zemens
David Zemens

Reputation: 53663

From This which you linked to includes two ways to resolve this issue:

  • If you intend to distribute, write a COM Add-in (that has always been the preferred way of distributing macros in Outlook)
  • If you do not intend to distribute and have access to a c# development kit (would not the free version of VSTO work? I haven't tried...) use the three lines of code suggested therein.

Do neither of those work? If not, you might suggest in your question why these methods will not work for you, so that other suggestions may be forthcoming.

Upvotes: 0

Related Questions