I have an application where I have used a Webbrowser component in a wrapper to open an Excel worksheet. Now, when I press the exit key of the form containing the Webbrowser component, I would like it to find that particular Excel instance (leaving others) and kill it.
How can I do that?
Related
Similar to Errors when calling certain Excel VBA macros from C#, I want to implement an error handler that will catch VBA errors and return gracefully.
Basically, I'm opening up an arbitrary macro workbook in Excel, and if the macro fails (i.e. you get a VBA error dialog with "end" and "debug" buttons), I want my application to handle it internally instead of using the VBA's dialogs. This is primarily so that a buggy book won't freeze processing (I'm using a queue of sorts to process multiple workbooks).
I already know about the DisplayAlerts=False property, and On Error Resume Next inserted into each routine, but I don't want to need to inject this into everything (especially since some of these workbooks may already modify the mentioned settings and reset them mid-routine!)
My best idea so far is to write up some sort of process watcher that looks for windows titled "Microsoft Visual Basic" and sendkey an "E" (to click the end button).
I've read in a few places that there's a property called Application.BreakOnVBAError that can be set to False, but it doesn't seem to exist in the interop assembly.
With the help of pinvoke.net and MWinAPI, I've been able to enumerate all of the windows created under Excel's process ID, which I can then drill down into to discover the elements of the dialog (if it's a dialog such as the Microsoft Visual Basic dialog).
Since it's an automated instance, the main window is hidden so the only thing that should show up are message boxes and the VBA error box, which I can then send keyboard input messages to to End the script when necessary.
Of course, this method never hits the "Debug" button so I should never see the VBE windows, but just in case I handle that too.
Source code available upon request?
I am developing an excel sheet which has lots of ActiveX elements in it.
I am not using UserForm and all the data is loaded when an activeX button is pressed.
At this point a hidden excel app is created where various actions are performed.
This new app is then combined with other data etc etc.. based on what the user is doing on the front-end with the provided ActiveX controls.
My problem comes when the "project is reset", where all the objects are released from memory and everything.
If this was a user form I would have implemented "on terminate" event where I would close hidden all workbooks that I have used, basically clean after myself.
However this is not a userform and there is no way to detect when the "project is reset"(as far as I know) so the hidden excel app that I've created remain open but nothing points to it.
If I go to the task manager i see various "EXCEL.EXE" and the number of those is basically the number of times I have run the tool.
So, is there any way for me to detect when VBA is about to "stop the project" in the same was as there is "terminate" for user forms so I can delete unsused stuff and reset elements in the spreadsheet?
Thank you!
I have found that there is no corresponding event to catch this.
Best way to handle this is to create a hidden userform object which will "hold" all global variables and objects that I define. I can then implement a UserForm_Deactivate event to catch when the form is exiting and clean up after myself.
My colleagues and I have created a userform with a suite of tools for doing tasks in Excel and Word
I'm quite familiar with spawning application objects from modules and closing them without effecting anything else - or other running copies of Excel.
However the user form must start some where - this leaves an Excel sheet open in the background.
I have tried Application.Visible = False but this hides all open workbooks - Kind of annoying if you have other worksheets open
I was thinking of a wrapper sheet which creates an Excel and runs the macro (spawning the macro in its own instance of Excel) - this works but then Im left with the wrapper sheet and potentially an orphan excel app if I close my parent.
Is there a better way than this to execute macros without affecting the rest of the user experience on MS office?
Yes, you can create an Excel add-in. Simply save the Workbook containing your code as an Excel add-in (select the appropriate file format in the "Save As" dialog) and configure Excel to load the add-in at startup in the "Options". You won't see anything of the add-in besides the functionality it provides.
First of all, thank you for your time and assistance in reviewing this!...
I'm trying to upgrade an Excel VBA workbook to a VSTO Excel Add-in in VB.NET using VS 2010. In the original (i.e.- VBA) version I have a modeless UserForm (called frmMain) that floats on top and is visible at all times while the user is still within the Excel application, but is not visible if the user moves to another window outside of Excel.
For example, within Excel the user can click on any worksheet tab, select any cell, etc. and the UserForm is still visible. This is exactly how I'd like it.
The problem is, that in the new VSTO add-in, I can not get the Windows form to mimic this same behavior.
I use frmMain.Show() to show the form as a modeless form, but the moment the user clicks an Excel worksheet (i.e.- activates a worksheet) the form becomes hidden behind the worksheet.
I can manually Alt-Tab to bring the form back into view, but I need it to always remain in view - floating on top of the Excel worksheets so long as the user hasn't left the Excel application.
I tried various things, including setting the form to TopMost, however, that causes the form to be TopMost everywhere - including outside of Excel. Worse than that, if the user does anything that would normally result in Excel's launching a dialog box (e.g.- closing an open workbook, raising the alert "Do you want to save the changes...") the alert dialog box itself is hidden and inaccessible behind the frmMain form (since the frmMain is TopMost).
How can I get my form to behave in the desired way (i.e.- the same way it did in VBA)?
Thanks!!!
Rob
You should take a look at Custom Task Panes which can be docked or floated within the Excel application. You could also look into the COM interfaces for a lower level connection (see related SO Post) - although Task Panes are really what this type of behavior was intended for.
This method might work (worked for me):
Create a worksheet_selectionChange event handler inside your form class
Put these lines in this event handler:
Dim FormHandle As IntPtr = Me.Handle
Me.Visible = False
Me.Show(NativeWindow.FromHandle(FormHandle))
I have 2 questions :
1) In my VSTO Add-in, I created a button. When clicked, it starts a STA thread, launching a WPF Window (which is in fact my real application).
The application is treating Excel Data, sending them to Web services, etc etc.
At a particularly moment, I call :
System.Diagnostics.Process.Start(filePath);
the path is like "C:\file.xls". Indeed, it opens an Excel file.
The problem is that the focus is beeing made on this file instead of remaining the focus on my WPF window.
I tried to set the focus to the Current process, but since the new file opened and my WPF Window are hosted in the same Excel process, it didn't solve the problem at all...
Any idea ?
2) As you can see, as my WPF application is launched in a thread, even using a modal dialog, I can still modify the excel file in background... which is not what I want at all...
How to fix this, blocking the excel file in background ? Is it possible to do this using the Workbook COM object that I can control ?
Ok I solved my problem not using a thread.
I launch my application directly in the VSTA_Main thread (the Add-in thread), causing a freeze on my button...
Since it's not another thread, my entire process in blocking.
For the second question, I launched another Excel process like that :
ProcessStartInfo info = new ProcessStartInfo("Excel.exe",filePath);
Process.Start(info);
I still have a little bug with the generation of the Excel file, but still solved my principal problem.