I am running Excel as a calculation engine (no user interaction) through VSTO and would like to be able to cancel a long running macro programmatically.
My current approach is to put the blocking call to run the Macro (Application.Run("MyMacro")) on a separate thread and then attempt to interrupt it from the main thread.
There does not seem to be any in built method call for this purpose such as Application.Interrupt(), so I am trying to programmatically trigger the keyboard interrupt that occurs when CTRL+Break or ESC are pressed.
Current code looks like:
Application.CalculationInterruptKey = XlCalculationInterruptKey.xlAnyKey;
Application.EnableCancelKey = XlEnableCancelKey.xlInterrupt;
Application.SendKeys("{ESC}", false); //have tried with true as second argument
In this case the code blocks on the final line which does not execute until the macro has completed.
I have also tried obtaining the process hook for Excel, setting it as the active process / window and calling SendKeys without success.
As this needs to be a generic solution for executing any macro, I cannot modify or provide any guarantees as to the macro contents.
Any ideas?
Thanks,
PS I have also tried sending the CTRL+BREAK keyboard command as in Application.SendKeys("^{BREAK}", false); The debugger pauses on this line until the macro finishes execution, so it seems like the Application object is blocked from processing any more commands until the macro has completed.
Related
I am using winit crate in Rust to create a new window. My program initially creates a CLI, and the GUI window is created based on an optional input from the user in CLI. How do I close the newly created window without exiting the process and closing the program completely.
The documentation and examples I have seen all use ControlFlow::Exit to handle the CloseRequested event, but that exits from the entire program; I only want to close the window that was created and continue running the rest of the code in the CLI. If there is an OS-specific command, I am targeting the windows OS.
To close the window, just drop the Window object.
However, I suspect you might be looking to also exit the event loop. That is not possible on all platforms, which is why you don't see documentation covering it often. To run the event loop and have an opportunity to exit it, use winit::platform::run_return::EventLoopExtRunReturn::run_return(), which is a trait implemented only on those platforms which can support returning from the event loop (which include Windows). Within that run_return(), using ControlFlow::Exit from the event handler will return control to the calling function, instead of exiting the process.
You could also do one of these things instead of using run_return():
Structure your program so that it continues running, with the CLI interface, within the winit event loop after having closed the window.
Run the CLI interactions on a different thread.
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 got a file in task scheduler which has a macro that triggers opening like this:
Private Sub Workbook_Open()
Call OpenRunMacroandCopy
End Sub
A bit like a house alarm, I'd like to have this macro wait before executing the Call for a set duration so I could use ctrl+Break which i believe would interrupt execution and let me read the file and close it without OpenRunMacroandCopy running at all.
I know of Application.Wait and Sleep but they don't work here and i do not know why.
I also used Application.OnTime Now + 5 / 1440, "OpenRunMacroandCopy" which does seem to make it wait but ctrl+Break gives me no notification and i've had that macro run anyway so i'm not sure interruption is working? When I use ctrl+Break on an infinite loop macro i do get an error window which is quite nice so i definitely know i have it stopped.
Got an idea, or a more purposeful way to make that happen?
my original question posted
Simulate Double Click Event in IE EXCEL , VBA interaction
.
You said,
this is a deadlocks for me because 1) i trigger the prompt from excel
to retrieve data from server 2) the server is stop responding until
prompt is being dismissed 3) all codes coded to handle prompt not
being processed because excel still waiting for the #1 to complete
I made a tests with some suggestions in older threads, but nothing worked.
References of those older threads.
(1) Disable Alert message of a webpage using VBA code (Refer the second answer)
(2) vba to dismiss an IE8 or IE9 "message from webpage" popup window
The thing is that, VBA code execution get stops when IE display the Alert() message. As code execution is already stopped we are not able to handle the Alert() prompt using code. So user need to close the Alert() prompt manually which resumes the code execution.
For simplicity in testing, if you just try to create an IE object and display the prompt and put some other lines of code after the prompt than you will notice that execution of code get stopped when prompt get displayed and until you close the prompt manually further lines of code will not get execute.
I agree with the suggestion given by the Zhi Lv - MSFT in your referenced thread for using the Selenium Web driver.
It can be the easiest solution for this issue.
References:
(1) Selenium Web Driver
(2) Selenium handle alerts prompts confirmation popups
As the title suggests, I am having a problem with Excel's Workbook_BeforeClose event handler. I know I am using the correct method signature (shown below) because it has worked in the past, and I have correctly placed the event handler in the "ThisWorkbook" module of the VBA editor. However, I have noticed that whenever I do a significant amount of coding within the VBE (in other modules), this method is not executed. Even when I place breakpoints inside, the breakpoints are not hit before the workbook closes. Again, this only happens if I have been messing around with other modules in the VBE; if I just open the workbook and immediately close it, this method runs fine and the breakpoints get hit. Saving or not saving the workbook does not seem to make a difference, and this problem occurs in Excel 2013 and 2016 (haven't tried opening the workbook in earlier versions). This issue is really starting to impede my workflow, so if anyone has a thought on why my Workbook_BeforeClose handler is not being called, I would very much appreciate the help!
Private Sub Workbook_BeforeClose(Cancel As Boolean)
'More code...
End Sub
After posting this question on the Mr. Excel forum, I was given the solution: Some of the other modules that I was editing contained optimization code. This included disabling Application events while the macro was running, then turning them back on after completion. However, while debugging, I would obviously occasionally stop the macro before it completed, so Application events were never being turned back on!
So now, all I have to do is execute "Application.EnableEvents = True" in the Immediate Window before I try to close the workbook, and my event handler runs fine!