I have this rather heavy Excel macro. When it runs Outlook freezes.
I know it is not using all the CPU power because
a) I have a powerful multiple-core machine
b) all my other programs (even heavy-duty ones) are running fine.
It seems like Outlook and Excel are sharing a process that Excel is hogging.
My macro does nothing Outlook-related, at least not knowingly. It pulls data from Bloomberg and does some calculation.
I appreciate the horse has very much left the corral...however, I too have experienced this and with no references in my code to the Outlook model. I've also noticed my Excel locking up whilst macros in another Excel instance are running.
To resolve this you need add a
DOEVENTS
line to your code, to quote the MSDN site
DoEvents passes control to the operating system. Control is returned
after the operating system has finished processing the events in its
queue
Where to put the DOEVENTS line very much depends on your code, but in a rather heavy macro of mine where I make a number of SQL calls, I've placed it just before each SQL call which appears to work well. Allowing me to work quite happily in one Excel instance whilst the background instance does a number of SQL fetches.
The same thing happened to me when migrating my macros to Office 2016. The solution: uncheck the library "Microsoft Office 16.0 Object Library", which is included by default when you create a new vba module.
Keep in mind that all calls to the Outlook Object Model are marshaled to the Outlook's main thread, so if your Excel macro is using the Outlook Object Model, Outlook can and will become unresponsive.
Extended MAPI (C++ or Delphi) can be used in a multi-threaded environment.
What does your macro do? Please post the relevant snippet of your code.
I have the same issue. I avoid other Excel workbooks locking up when I run code in a workbook by opening them in new instances. Note that by default Excel now opens all workbooks in the same instance. For workbooks that I have VBA in and for large workbooks - I always try to open in a new instance to avoid freezing and confusion over where the VBA should run. I do this holding the ALT key down when opening Excel (if another instance is already open) and verify I want to open a new instance. This works for other applications as well.
However - I don't know how to tell Outlook to open in a new instance since it is the only instance of Outlook running. Sometimes Outlook locks up when I run code in Excel and sometimes it doesn't (running the same code). I've had some luck in closing Outlook and opening it back up to get it "detached" from my Excel instance I want to run long running macros in.
Related
I have a macro that extracts data from Microfocus RUMBA Mainframe Display and puts in Excel rows one after the other. I have created a Global Mainframe object and that is used for extraction to Excel. But when the process is running and if user decides to stop the processing he cannot click on Stop button on Excel or go to different tabs to see the data being pasted. He has to clicks like 6 times before tabs are switched or stopped.
I see that DoEvents allows mouse click events in the loop to do things but the code is written in a way that there is a lot of lines with in the loop and a function with no loop, and placing DoEvents after everyline seems irrational. I have a feeling there is a better to do that but not sure what that is. Can anyone please help?.
VBA is single threaded. So you can't have one VBA action interrupt another. If you had a cancel button, for example, and the user was allowed to click it via a DoEvents processing the cancel action would still run after the currently running procedure.
In Excel this single threaded nature ends up being a good thing because you generally don't want the user interacting with the workbook while you are making programmatic changes. If this was allowed you would get undefined behavior.
Your best course of action would be to make a .NET application that uses the Excel Interop extensions to move the data from the mainframe to Excel. If you use VB.NET then you will find the code is quite similar to VBA. In fact, the Excel.Application object model is identical so the macro code you already have ports cleanly over.
There is an add-in that will help RUMBA development here:
https://www.microfocus.com/documentation/rumba/desktop951/RumbaSystemAdminGuide/GUID-DDB7571D-6167-4F8B-876E-E7450F3030B2.html
I want my workbook to open in its own separate instance of Excel. If it gets opened with other workbooks, it should reopen itself in a new instance, perhaps using a code in the Workbook_Open event. Additionally, the workbook should prevent files from opening in the same instance, perhaps by moving them to a new instance or moving itself to a new one. Any ideas will be much appreciated.
Edit:
The purpose of this is that workbooks loaded with code and userforms tend to crash easily causing all other workbooks open in the same instance to crash and lose all unsaved changes and the end user gets frustrated. Another issue is that when the Application.OnKey is used, I experienced three problems: 1. shortcut triggers a code that's usually intended to act on the workbook it resides in. This can be solved by checking whether the hosting workbook is the active workbook before running, but it's better to prevent them from running in the first place. 2. common shortcuts can be reassigned to run a custom code, but usually this shouldn't affect other workbooks. 3. problems happen when multiple workbooks that assign same shortcut to custom subs. the most recently open workbook takes over the shortcut action. Also, when the workbook that contains the shortcut is closed, using the shortcut reopens the workbook automatically, which is not a desired! Removing the custom shortcut doesn't solve the problem of multiple workbooks using same shortcut.
Therefore, best solution is to start such workbooks in their own application instances.
I've had to make an Excel workbook (which was running a timer) reopen itself in another instance of Excel. This was to let the user use the first instance of Excel without the timer interfering. I'm not sure if that's exactly what you need, but that can certainly help you get started. You can find the code on GitHub here.
The procedure that you would be interested in is called OpenItSelfInAnotherInstance and is located in OpenItself.bas.
For it to work you will also need to include the code contained in API_Maximize.bas, API_Sleep.bas and UDF_ExcelIntances.bas. (If you copy-paste, always exclude the line that says :Attribute VB_Name =... since it's there only for when you import the *.bas file in from the VBE)
Please let me know if there is anything unclear in there, so I can add some explanations in my answer if needed.
I am wondering if anyone knows how can I go about removing a VB6 COM Add-In from within the Excel environment (i.e., unloading it), through code, but without uninstalling it?
I have tried setting the respective COMAddin "Connect" property to false, with a code like bellow:
MyExcellApp.COMAddins("myComAddin").Connect = False
While that does unload the add-in from memory, Excel will not re-load it again when it is restarted. That is, the COM Add-in was in fact uninstalled, and has to be installed back (through Excel's COM Add-ins menu option) in order to work again.
Why do I want to do that? Well, I am creating a rather complex COM Add-in, and I want to give the end-users an opportunity to unload it if they feel it is disturbing their environment. It will be like an "exit" button for the add-in, but it should allow the add-in to load again whenever Excel is re-started.
This may be a silly question - I haven't found anything on Google about this. No new programs populate in the task manager when VBE is opened from an Office Application, and I don't see an executable that looks probable. DLL maybe?
Some Office applications provide the Run method for the Application class. For example, see Run Excel Macro from Outside Excel Using VBScript From Command Line.
Yes, you can call VBA macro at runtime.
There are applications that don't provide any specific methods for that, for example, Outlook. In that case you can use the late-binding technology (see Type.InvokeMemeber) - see Calling Outlook VBA Macro from outside (VB/VBScript/C#).
You can invoke a CommandBarButton's OnAction macro as a proxy for Application.Run.
For details, see this question How can I run a macro from a VBE add-in, without Application.Run?
I have a c# application that uses Microsoft.Office.Interop.Excel. The application runs for a long period of time! If I try to open Excel manually on a different worksheet from the one the c# application is processing the c# application fails with some HResult cryptic message.
Is there a limitation with Microsoft.Office.Interop.Excel in that only 1 excel process can run at once?
Any information around this issue would be great!
thanks for any help!
Mostly, it is how your code is interacting with Excel that is the problem. Many people use ActiveCell, ActiveWorkbook, and so on. Therefore, when you open another workbook during this process, you will generate some kind of error. To avoid this, open another instance of Excel. In our shop, we created a shortcut in our "Send To..." folder. We could then just right-click on the file in Windows Explorer, select "Send To..." menu, then click on our shortcut. This saved us from having to open Excel, select file open, browse to file, and so on.