I have a private subroutine in Workbook A that is running any time I open or close and save other unrelated workbooks. I'm trying to understand why that occurs so I can capture all potential errors that may occur.
The subroutine is an ActiveX ComboBox named TabProg that is supposed to run when the value is changed. I have currently added in a check to see if the active sheet trying to run the code is the "Program Loading" sheet to try and divert any potential errors. See snippet below.
Private Sub TabProg_Change()
MsgBox "Whomp!", vbOKOnly + vbExclamation
If ActiveSheet.Name <> "Program Loading" Then 'do nothing
Else
'Run desired actions on "Program Loading" sheet
End If
End Sub
Any known reasons why this is occurring or other ways to catch it would be helpful. Thanks!
Edit 1: I do not see this problem occur when I open other workbooks in new instances of Excel.
Edit 2: I have modified the code to include a message box whenever the code tries to run, now shown above. It is occurring every time I open or close and save any Excel file, including the file itself. The drop down list in the ActiveX ComboBox is a list of names that correspond to 10 sheets within Workbook A. If I delete the sheet that ComboBox is currently set to, the error will disappear. If I change the ComboBox to a different sheet, the error will reappear.
From what you've wrote in your question, I don't think that your problem can be replicated. I think that your Excel file got corrupted. I had an experience like this: had a file for experimenting with macros, one of the macros used Excel Speech object to say "This is a test file" on opening that particular file. The macro was (as all other macros from this file) not part of my PERSONAL workbook, it was assigned to ThisWorkbook in the bespoke file. At some point a funny thing happened: this "This is a test file" private subroutine got activated every time I opened any Excel file. I did not find any solutions, I just deleted the file where the subroutine was stored. This resolved the problem, but I have no explanation for this. I am afraid the same thing may apply to your file, but maybe other folks have a better idea... maybe it's something in the system registry??? I don't know. Can you manually copy elements / code from this file to a newly created file and just delete the original?
Related
I have been creating a .xlsm Workbook that contains various bits of VBA. It simply copies data from two other workbooks into tables and then refreshes the PivotTables that are based on those tables to update the charts on the main workbook. All things I have done before in different workbooks without issue. Whilst working on the workbook I have naturally open, saved, and then closed the workbook several time over several different days.
Typically, now that I believe the workbook to be finished, it has developed a glitch whilst opening. Initially I was unable to open the file at all, as it would immediately crash. Only by saving the file to onedrive and downloading it back again, have I been able to keep the file open to see what is going on (for some reason this worked, I don't know why!).
I immediately suspected something in the VBA and so one press of Alt+F11 later I was confronted with this (image above).
All of the Blue Excel Objects in this picture were not created by me!
They contain no code and I do not seem to be able to open them as regular Excel Worksheets.
My Questions are,
does anyone have any idea what may be causing this?
Has anyone even seen this before?
Where do I start debugging this?
Attempting to run any of the VBA in the workbook causes it to instantly crash.
The VBA i suspect the most for the crashing is in these sections;
Public Function ThisWorkbookPath()
ThisWorkbookPath = ThisWorkbook.Path & Application.PathSeparator
End Function
which is passed to;
Public Function CheckPath(ByVal PathString As String) As Boolean
Application.Volatile (True)
If Strings.Right(PathString, 1) = "\" Then
CheckType = vbDirectory
Else
CheckType = vbNormal
End If
If Len(Dir(PathString, CheckType)) > 0 Then
CheckPath = True
Else
CheckPath = False
End If
End Function
These are both used in the workbook as user defined functions to check if the folder that contains the other 2 workbooks exists on the computer before trying to open them.
ThisWorkbook is now ThisWorkbook1 which might explain why, as the forumla in the workbook calculates, it can't find the correct path and just crashes.
But this doesn't explain where these extra objects came from in the first place.
Any help would be gratefully appreciated
I just had the same issue with Office365, made a code review and found out that I was using the same name for a public constant and a parameter to a function. After renaming the parameter and rerunning the macro, it did not happen again.
Context
I have developed a .xlam add-in that contains user-data inside. In other words, the user can decide to show the add-in file through a ThisWorkbook.IsAddIn = False to edit the content, which is functional to the add-in itself.
However, the user should not be able to perform some operations when he's/she's working on the add-in's spreadsheets rather than on the normal workbook where the Add-In is running.
Need to check for file extension
From here, it comes my need of checking for the file extension and validate it when some specific "forbidden" procedures might get called. I have made the following tests:
If ThisWorkbook.IsAddIn = True, then ThisWorkbook.FileFormat = 55;
If ThisWorkbook.IsAddIn = False, then ThisWorkbook.FileFormat = 52;
The source of confusion
This is not what I was expecting. By simply executing a FullName request when the Add-In is set visible:
ThisWorkbook.IsAddIn = False
MsgBox ThisWorkbook.FullName
I can read that my file is still named C:\myFile.xlam, even if in that moment is visible to the user. So, I would expect ThisWorkbook.FileFormat to raise a 55 even if visible at run-time. But it doesn't do that, apparently.
The question
I need to make sure to distinguish between modifications on the Add-In (.xlam) and modifications on a possible .xlsm file that the user created, from which is using my Add-In.
Why is the FileFormat of my add-in being equal to the one of an xlsm, if the file is clearly xlam to which is associated a 55 instead of a 52? Where am I being wrong?
EDIT - Example of the action to forbid
On the ribbon there's a button created and added from the add-in, which is connected to a macro that cannot be run into the Add-In. So the check I had in mind was something like this:
If ActiveWorkbook.FileFormat = 55 Then
Exit Sub
End If
However, as said above, this check will not be performed because the Add-In has FileFormat = 52 in the moment in which is set to .IsAddIn = False; hence, even if the ActiveWorkbook is the add-in where I do not want to run the macro, the check will fail and the macro will run anyway.
The .IsAddIn workbook property simply indicates whether the file is being run as an Add-in. It does not change the file format. From the documentation:
When you set this property to True, the workbook has the following characteristics:
You won’t be prompted to save the workbook if changes are made while the workbook is open.
The workbook window won’t be visible.
Any macros in the workbook won’t be visible in the Macro dialog box (displayed by pointing to Macro on the Tools menu and clicking Macros).
Macros in the workbook can still be run from the Macro dialog box even though they’re not visible. In addition, macro names don’t need to be qualified with the workbook name.
Holding down the SHIFT key when you open the workbook has no effect.
I sense that this is the real problem you're trying to tackle:
However, the user should not be able to perform some operations when he's/she's working on the add-in's spreadsheets rather than on the normal workbook where the Add-In is running.
Perhaps it will be best if you can specify what actions you're trying to restrict? There may be a better way to solve this.
For the moment I have found four possible solutions, that I'm going to post here just in case someone would have my same issue:
Comparing the full names - credit to Tim Williams
The "special code" cannot run if the full names are different:
If ActiveWorkbook.FullName = ThisWorkbook.FullName Then
Exit Sub
End If
'"special code"
Comparing the isAddIn property - credit to David Zemens
The "special code" cannot run if this workbook is not currently an add-in:
If ThisWorkbook.IsAddIn = False Then
Exit Sub
End If
'"special code"
Comparing the two objects
The "special code" cannot run if the active workbook is the add-in workbook:
If ActiveWorkbook Is ThisWorkbook Then
Exit Sub
End If
'"special code"
Checking for "xlam" extension
The "special" code will not be run if the extension of the file is xlam:
If Right(ActiveWorkbook.FullName,4) = "xlam" Then
Exit Sub
End If
The four solutions above work fine for the purpose, but the question is still opened : why the FileFormat property changes over the same file depending on ThisWorkbook.IsAddIn being False rather than True?
Have Excel (2010 in my case but I think it will be the same also in other versions) with two workbooks. Save first one with name "1.xlx" (example) via Save As dialog. Save second one with the same name "1.xlx" to different location. Excel will not allow it with following warning message:
"You cannot save this workbook with the same name as another open workbook or add-in. Choose a different name, or close the other workbook or add-in before saving."
So far so good. But my problem is that I need to invoke dialog via VBA. I am using following code:
Sub test()
Application.Dialogs(XlBuiltInDialog.xlDialogSaveAs).Show
End Sub
Now I am trying to save second workbook (with the same name to different location) but when I click to 'Save' button nothing happen, no warning message. If I wouldn't know what is wrong it would be very difficult to tell. I didn't change any setting (there is nothing as DisplayAlerts set to true or so). Any idea how make SaveAs dialog invoked via VBA to display similar warnings?
I'm not sure why that doesn't give you an error, but it doesn't me either. If you use Application.FileDialog, you can get that error.
Sub testts()
With Application.FileDialog(msoFileDialogSaveAs)
.Show
.Execute
End With
End Sub
Or you could use GetSaveAsFileName and check the names of all the open workbooks and generate the error yourself.
Can you try with the below code on starting on your code.
Application.DisplayAlerts = True
We receive Excel files daily from our field offices which I have to clean and re-format (about 110 columns and 500 rows-worth) using VBA.
I need to save my VBA as a macro so we can use it to clean up all the workbook we receive by running the macro and saving the edited sheet as a new worksheet by getting the name from UserForm Combobox items.
Where exactly should I store the VBA snippets? I mean when I open the Visual Basic panel, I have these three options:
Running The Code From Microsoft Excel Object :Sheets1(Sheet1)
Running the Code From An Inserted Module
Running the Code From User Form
If I am supposed to use options 1 or 2, how can I call the UserForm for saving the sheet?
I Recomend you to use modules (Option B)
Option C goes with option B, ill explain, you can create a sub in a module in option B, then you can do:
UserForm1.show
In Option B I would writte this code, but before trying this i recomend you to understand a bit more of vba
sub ClearWBs()
'opening workbook
Workbooks.Open Filename:="c:\book1.xls"
'your code
'your code
'below code for saving and closing the workbook
Workbooks("book1.xls").Activate
ActiveWorkbook.Save
ActiveWorkbook.Close
end sub
Use Module:
If your VBA code focusses on data summarization and manipulation I suggest you use a Module.(example is what you have described in your question).
Use Form:
If what you wan't to do requires a GUI(Graphical User Interface) then you'll have to resort to Form where you can design your GUI. (example is if you have many fields that the user needs to fill-up with distinct values in which you provide the choices)
Use Excel Object:
If what you wan't to do has something to do with events happening on Worksheet and/or Workbook, like for example whenever you add sheet the macro runs, or when you open or close the workbook the macro runs then you will have to write the macro in the Excel Object.
This is basically what i have in mind, hope this helps.
If you receive files that do not contain VBA and you need to apply the same code on those files all the time then I propose that you either save that code in your personal workbook.
You can see how to do that here: http://office.microsoft.com/en-ca/excel-help/copy-your-macros-to-a-personal-macro-workbook-HA102174076.aspx
This is nice because you can also tie it to keyboard shortcut or just have it always ready for you to use.
The disadvantage is that it will only be set up per user session per computer. What you can do is have that code all set up in a module and then import it into your personal workbook if you change session or if someone else has to do it.
Once it's done, you will not have to include the module in your files your receive again.
I'm going through 100s of excel files in VBA, extracting certain data and copying it to a main spreadsheet in a main workbook. I have a VBA script that resides in this main spreadsheet.
I'm trying to get each source workbook to close after I open it and get what I need. It looks something like this:
dim main_wb
dim source_wb
set main_wb = activeworkbook
Loop thru workbook names
set source_wb = workbooks.open(a_workbook_name)
do some stuff
eventually copy a few rows from various sheets into the main wb
source_wb.close()
set source_wb = Nothing
End Loop
The problem is that it SEEMS like the system is continuing to keep the file open in the project explorer ... and eventually it runs out of memory or something. All files work fine individually. It's only when I attempt to process them all at once that I have a problem. The workbook "closes()" but the project still exists in the project explorer in the developer window.
How do I tell it to close out a project. I need to be able to, no BS, close the project and go on to the next one for hundreds and potentially thousands of files - automatically, in code, no intervention from user.
try... It works for me in a similar type of program.
'closes data workbook
source_wb.Close False
I recently had this problem: I have a workbook that grabs data from other workbooks that I use as databases. On one of these, I inadvertently placed some code. This caused the workbook to remain visible in VBE even after it had been closed. My solution was to keep my database workbooks free of code, and that solved the problem.
It seems that the VBE editor is not always visible to the workbook that is being closed.
I included the following code in my ThisWorkbook module which comes from a comment in another thread and this resolved matters.
http://dailydoseofexcel.com/archives/2004/12/11/google-desktop/
Private Sub Workbook_BeforeClose(Cancel As Boolean)
On Error Resume Next
' -------------------------------------------------------------
' this code ensures that the VBA project is completely removed
' when the workbook is closed
' http://dailydoseofexcel.com/archives/2004/12/11/google-desktop/
' -------------------------------------------------------------
If Not (Application.VBE.MainWindow.Visible) Then
Application.VBE.MainWindow.Visible = True
Application.VBE.MainWindow.Visible = False
End If
End Sub
Solution :
Manage your Save (Yes, No, Cancel)
Destroy links to Addins in your Application
Close these Addins
Close your Application