Everytime I load up my Excel document, it repeatedly shows up with the message from the title. The two options are OK and Help. help opens Office Help which is useless for anything. Clicking OK displays another message saying "Compile error: Out of memory." with OK and Help buttons. Clicking OK brings up VBEditor with no debug line selected and no macro popped up either for that matter. Eventually, after it repeats that and complains 20 (exaggeration) more times (I think that's due to having a lot of duplicate code for ActiveX controls on each sheet). It highlights the first line (the Sub declaration) of the code below.
Private Sub ComboBox4_Change()
Range("B3") = ActiveSheet.ComboBox4.text
End Sub
Now this is dealing with an ActiveX ComboBox. Opening a file from an earlier date will give no errors. It's like after a certain date, it just refuses to work with it. And get this, it's only happening on one computer. The files are saved on a network drive, which shouldn't be causing an error.
I'm almost 100% certain I found a solution to this issue. It may have caused issues for someone else 4 years ago, but it caused issues for me today and I wanted to contribute my answer for anyone else running into the same problem.
I had enabled an "Additional Control" in the Controls Toolbox for Windows Media Player. I think when it loaded in a video file, it overran the memory. This is when I started panicking (company computer and all) and Googling and came across this and a few other articles without a real, fast fix.
The hunch: Once that video file was attempted to be loaded in RAM memory (because that's how Userforms work) it locked up all the memory Excel would allow before throwing all the errors.
What I tried from other posts in various places: I rebooted a few times (before Googling, even). I tried the Quick Repair of Office from Add/Remove programs, that didn't work. (I'm using Office 2016.)
So, what worked? I had the idea that maybe I could disable all ActiveX from loading in my file, and Googled that. I got: https://support.office.com/en-us/article/enable-or-disable-activex-settings-in-office-files-f1303e08-a3f8-41c5-a17e-b0b8898743ed and proceeded to disable all ActiveX controls in Excel. I closed the file out. Can't recall if I closed Excel but I probably did.
Then I loaded up my file. (ActiveX is totally disabled at this time.) No errors! I went to VBA (ALT + F11), opened my UserForm, and the video I had inserted and could not remove was just... gone. I saved the file. I closed the file.
I opened Excel. I re-enabled ActiveX in the Trust Center. I opened my file. Still, no more video on my UserForm (I didn't need it anyway) and no "Unspecified" (memory) errors! And, I can save again!
I hope this solution persists... if not I've got some "splainin' " to do. So far, I'm designing and using the Userform, and saving the file, with no issues whatsoever. I think it worked!
I believe the problem was that I had a user form with an acrobat reader display control (like an iframe, but for PDFs). I didn't have this reference or control on that specific computer and it freaked out. Not 100% sure, but the problem no longer exists.
I have been having a very similar problem with WindowsMediaPlayer (WMP) ActiveX control that I have in a Form. Some computers with office 2016 are giving this error code (usless the help button), this is the first post I have found about something similar with WMP, and I found it after searching for this error on ActiveX controls...
So my solution was to go to VBA (alt+F11), right clic on form that has the activex control and then remove it witohout exporting.
The big problem is, that for me, this form is the most important part of the application.
I have no mor information, if I find something I'll come back to post feedback.
I encountered this issue when trying to pull data from an access database. The query I was trying to pull from in the database was an all value query (*). Once I added the individual fields, the error went away.
I've got this error, when I create a user form which has no body section(just header). (Using this method for the messages where I don't expect a user response. Like a progress bar.
Probably, any abnormality(*)or inconsistency with the user form causes this problem.
Solution: Changed the height of the user form just a few pixel.
Just a simple trick worked for me
Go to Excel Options
Manage Excel Add-ins
Uncheck all and click ok
Related
First of all sorry for posting this, I know it's probably duplicated from this post, I tried to post it as an edit but it got rejected and I can't comment because I don't have 50 reputation, also this is not a proper answer. Hope this helps to get a better understanding of the problem and more attention.
I work in a company that uses VBA and we've been using Documents.Open for a long time and it never gave me any problems, until now. The problem seems rather random, as not many clients have this, but it's turning more consistent now mainly with Office 365. Maybe it's due to an actualization?
Whenever I do Documents.Open the requested document will open, but anything that comes after that won't be executed. It can be as simple as:
Sub Test()
Documents.Open(filename)
MsgBox "Hi"
End Sub
And the message box will never be shown. I've also tried this, as I found something related in other forums:
Sub Test()
Dim doc as Document
set doc = Documents.Open(filename)
MsgBox "Hi"
End Sub
I've even tried the old open WordBasic.FileOpen(). Nothing helps, code stops executing after opening the document. In a desperated attempt at making this work, I've created a COM dll that opens a document, with a message box in the dll and in VBA after the dll has done it's part. The dll functions properly but as soon as it gets back to VBA the code stops and it doesn't show the message box.
I've done some research and it has nothing to do with the known shift-key bug since I can run the example code by pressing the play button, so no keys are being pressed when the document opens.
Then I tried to work with the AutoOpen event as seen in this other post and by debbuging I've realized that the PseudoAutoOpen event it's never called in the computers with the problem.
Also made sure that everything it's in the trusted documents location and that the macros are enabled, as this other post said:
Word 2013 VBA - opening document aborts macro
UPDATE
I've found out accidentally while debugging, that if I run the example macro twice, the second time (with the targeted document opened) it works as intended.
I'm starting to lose my mind over this.
The problem seems to be with the 1807 Build 10325.20082 update.
Restoring to an earlier build (9330.2087) fixed the problem for me:
https://support.microsoft.com/en-us/help/2770432/how-to-revert-to-an-earlier-version-of-office-2013-or-office-2016-clic
I've gotten report from MVP's at the forums of microsoft that they did a server sided change to a configuration file that word downloads during startup of word. The change makes it so, so that the (new) problematic code causing (my documents.add) problem gets disabled.
I just tested it with a client that had the problem and were we downgraded the office version to the previous build and now the problem as far i could tell seems to be solved.
It could be if you update your office version again it also works with you. Potentially if the problem still occurs the 1st time you need to close word wait a bit and start again.
Maybe it is now also fixed for the documents.open problem with this (server sided) change.
More info in original discution here
https://answers.microsoft.com/en-us/msoffice/forum/msoffice_word-msoffice_custom-mso_2016/1807-build-1032520082-is-causing-vba-problems-with/538e8c3c-355e-47a7-9e3f-58cf04902c10
We have a large word application with around 100 forms, 50 modules and 20 classes. Over 100 people get into this application and some of them are seasonal which means that they will use different computers. We are running into an issue where windows defender seems to be removing the the vba from the word document. It seems to only happened every once in a while and we believe it is with someone new to the application. Each time it occurs, the file is broken and we have to use our copy to save over the original version. The size of the file will go from 6,897KB to like 60KB. Below are screen shots that I was able to get from one user that caused this issue. Any assistance on how to prevent this from happening would be greatly appreciated.
This is the first error the user receives when they try to open the word document:
This is the error that the user receives after they click on the "First Error":
I am working on a macro-heavy Excel file with many ActiveX controls. All functions of the file work perfectly on my PC and another, but I get the error 32809 when the Auto_Open macro tries to activate a sheet on other PCs.
I know this problem has been posted many other times on many different forums, but none of the solutions I have found that worked for others have worked for me. I have tried all of the following possible solutions:
Deleting all *.exd files from both the Temp\Excel8.0 and Temp\VBA
Disabling all ActiveX controls
Opening the file on the PC that does not work and saving with a different name
Modifying the code slightly, recompiling and saving
Deleting all ActiveX controls and re-creating them on a PC that did not work
The only thing that stopped the 32809 error from occurring was deleting all of the ActiveX controls, but if I save the now functioning file on my PC and try to open it on the one that did not work the error comes back.
While deleting all of the controls did stop the error, it is extremely inconvenient to have to recreate all of the controls on a different PC when I make an update to the file. I am open to just about any suggestion that might help with this extremely frustrating problem.
I ended up deleting all of the ActiveX controls from all of the sheets before saving any changes and writing a routine to run on opening the file to re-create all of the necessary controls and re-save the file with the controls the first time it is opened on any given PC.
Creating the controls doesn't allow debugging until after all routines have completed, so I used the Application.OnTime command rather than simply calling the next routine to work around this.
Hope this can help. I have been dealing with famous runtime error 32809 for a while. in the VBA, if some object is not defined, the runtime error 32809 will prompt up when the Excel VBA runs. but now, more cases about this runtime error is not caused by "undefined objects ...", it's caused by the Microsoft security patch problems. the patch makes the VBA ActiveX controls are not recognizable, so VBA treats these valid ActiveX controls as undefined objects. To resolve the issue, Microsoft released new patches to fix the early issue.
if you ensure the existing VBA has no "defined object" or it used to work well, you can upgrade your Microsoft patch. the latest version for Excel 2010 should be 14.0.7177.5000 or later.
Suggestion: don't include ActiveX controls in VBA if the product is used by a variety of users. this can cause the endless problem. any windows updates can likely impact the VBA.
My company creates workbooks for clients that contain ActiveX controls (in most cases we need the extra functionality as compared to Form Controls). When we create them, they work fine on our end, but when we zip them up and send them to our clients, they open the WB and the ActiveX controls are no longer ActiveX controls, if you right click it, it behaves like a picture.
I feel like this is due to the MS ActiveX debacle. I have had them run the Fix It and making sure all the MS Office components were closed, and had them reboot, but still nothing.
I am pulling out my hair, and have asked on other forums if anyone else has had this issue, and what they have done to fix it. Thanks in advance.
Could you please check in client system whether macros and active x controls are enabled in Trust center setting?
https://support.office.microsoft.com/en-us/article/Enable-or-disable-macros-in-Office-documents-7b4fdd2e-174f-47e2-9611-9efe4f860b12?CorrelationId=fe6a4d24-f4d9-4c6b-afa0-40d2828ad22e&ui=en-US&rs=en-US&ad=US
use above link if needed.
Try closing excel and deleting the .EXD files from your computer.
Source: http://www.mrexcel.com/forum/excel-questions/296750-command-button-turned-into-image.html
While saving the Excel document, save it as "Macro enabled workbook".xlsm
In my case, the worksheet prompts a non responsive error sometimes. When I reopen it, Excel repairs it and turns all active X check boxes (sometimes drop down list and command buttons) into images. It happened many times and I had to spend a lot of my time recreating them and liking to cells.
I experienced a similar problem when Excel repaired a file; this may be similar to what's happening with the Zipped file. FormControl Buttons don't appear to have the same problems but I see you want to keep the additional functionality of the ActiveX Control.
You may be able to make use of the code I created by inserting one Form Control button that runs the Sub RepairMissingButtons() that your clients can press to restore the images to CommandButtons. This currently fixes buttons for any selected sheets, so you'd want to first identify which sheets need to be selected (or add a form control button on each sheet that needs the repair done).
You'd need to modify the Sub CreateButton() to meet your needs (currently requires hard-coding the Caption, BackColor and any other ActiveX properties that may have been lost by the button being converted to an image):
Reverse Excel ActiveX command buttons erroneously converted to images after corrupted file repair
Having this problem, activex controls sometimes change to pictures.
Many places around the internet the answer is: Use form controls, well as far as I can tell form controls don't actually do anything useful.
Even Microsoft's support site says, recommend using form controls, how can that be the answer. being able to interact with VBA is as far as I can tell the only reason to use Microsoft applications instead of free ones.
I am programming the On_Click method for the button labeled "View" in the first printscreen below. The method will load a form with data corresponding with the specific address id in the row containing the "View" button. This code worked perfectly when pointing to a target form called "Addresses". However, when I decided to rename the form "Address", I started receiving the following error message when clicking on the view button:
I did some research on the web about this error message, which lead me to try to delete any outdated references in the VBA editor. But when I clicked on Tools-->References in the VBA editor, I got the following error message:
It seems that MS Access' entries in the system registry might have been corrupted. But I am not certain of this because the documentation of this on the web is sparse and inconsistent.
Here is a link to the database on a file sharing site: http://jmp.sh/b/9Uyx6J2YzWbs8zPq2h6g
If the problem is in the database, you can recreate the problem by opening the form "Main" and clicking on the button "View" for the record shown in the printscreen above, or for other records.
Can anyone show me how to get past this error message?
my advices?
You could rename your Forms!....SourceObject to "Address" instead of "Addresses"
You could copy/paste the form, delete the original, and retry
You could install a decent debugging tool like MZ-Tools for VBA, that will help you manage your errors. Check the details here
EDIT: I used to get similar bugs years ago, when I was writing specific form event procedures. As we decided to switch to a model where forms did not need to be debbuged anymore (check this here), we stopped getting this kind of message. And I think I forgot the trick we used to solve this kind of error. If I were you:
I'd try to open another access database and import all objects ...
I'd put aside/cancel the faulty onClick procedure
And I'd install MZ Tools because otherwise VBA debugging is a nightmare ...
Since access was not liking the command button in each record of the continuous form, I choose to put the view button's logic in the on click event of a text box in each row, which I configured as enabled but locked. This produces a separate link from each record of the continuous form to a unique detail page with more of the chosen record's data.
This solution works perfectly, and is enabling me to move on with my other coding.
However, it would be nice if someone else were able to show how to get the command button solution to work.