On 1 Jun., 01:57, donvreug <donvr...@gmail.com> wrote: > The environment this is occuring in is a corporate one where there are > a number of Excel workbooks each with VBA modules that are deisgned > for different tasks. Occassionally someone tells me a macro has > failed, and when I check they usually have two or more Excel workbooks > open.
Who is "they"? Usually one knows which workbooks one has opened and particularly why. Or is this some kind of environment thing, such as "that is just some stuff that appears automatically when I boot my machine". What are the tasks that these workbooks are designed for? Although an Excel workbook normally just sits there and does pretty much nothing, one can design workbooks that regularly do some system maintenance jobs like back-ups. That would make debugging quite hard (you would first have to determine which Excel application is giving the error message). Or do you mean that when you perform some action you get "occassionally" an error message (in contrast to the scenario where you do something else and suddenly an error message pops up)? And what is the exact text of the error message? Please elaborate. > Closing all workbooks and then reopening just the one which > failed usually lets it run successfully. So there must be some kind of > interaction at the macro level between these workbooks. It could be very well be that different worksheets are trying to operate on the same set of files. This would lead to Access Denied errors. > Some of the > modules occur in more than one Excel workbook and there may be common > sheet names as well. I was wondering if there is a way to isolate the > macro, in either code or some other way, so it only interacts with its > parent workbook or whether this should be happening anyway? I don't think that it is possible to restrict Excel's macro processor in such a way that macros can only manipulate the worksheet that they belong to (I'm not an expert in these matters, maybe Office 2007 and later offer such functionality). As far as I know, any macro can manipulate any workbook (and even the code in other workbooks, see my previous answer). > Perhaps a > better way of implmenting workbooks in such an environment is > required? VSTO perhaps? I can imagine that VSTO should make anything better with regard to your problem. I just guess that you'll have to find out what is going wrong by yourself (which is usually the hardest part of programming). Good luck, Stuart -- ---------------------------------------------------------------------------------- Some important links for excel users: 1. Follow us on TWITTER for tips tricks and links : http://twitter.com/exceldailytip 2. Join our LinkedIN group @ http://www.linkedin.com/groups?gid=1871310 3. Excel tutorials at http://www.excel-macros.blogspot.com 4. Learn VBA Macros at http://www.quickvba.blogspot.com 5. Excel Tips and Tricks at http://exceldailytip.blogspot.com To post to this group, send email to excel-macros@googlegroups.com <><><><><><><><><><><><><><><><><><><><><><> HELP US GROW !! We reach over 7000 subscribers worldwide and receive many nice notes about the learning and support from the group.Let friends and co-workers know they can subscribe to group at http://groups.google.com/group/excel-macros/subscribe
