My Problem: Treeview Control 6.0 becomes unresponsive in Excel 2013 64 Bit (Compile Error: Method or Data Member Not Found). I am able to delete the control, insert a new Treeview and it initializes fine (loads Imagelist, allows user configuration of nodes, etc.); however, once I save/close/reopen it becomes unresponsive again. This Excel tool allows users to configure a dashboard using Treeview and it worked fine (still works fine) in Excel 2007. I can include the code to initialize the Treeview control, but it is not a code issue as it works perfectly in Excel 2007.
Attempted Solutions: I have read through many forums and have tried numerous solutions to fix, but none have fixed the issue...
Running a batch file (as Admin) to unregister/re-register MSCOMCTL.OCX in the correct location
Deleting all .exd files from my hard drive
Removing/adding Common Controls reference in VBA editor
Deleting/Recreating the Treeview numerous times
Repeating above solutions in every possible order
The strangest part to me is that I can re-create the Treeview (insert, set properties), run code to initialize, and completely configure the Treeview with no issues... it only becomes unresponsive after saving/closing/re-opening. Again, the opening/closing routines worked fine in Excel 2007 so I don't think it is a code issue.
Any help would be greatly appreciated... I need Treeview to work as it stores all of the user dashboard info (TV terminals, files to open/close, etc.).
I encountered the same problem with EXCEL 2016, 32 bit version. EXCEL does not recognize the embedded TREEVIEW control after saving and reopening the file. (Sometimes it would work on the first save and reopen, but fail on the second.) This problem did not occur with EXCEL 2010 and earlier, same spreadsheet. Like you, I can embed a new TREEVIEW control, name with the name the macro populating uses, i.e., the name originally given to the unresponsive TREEVIEW control. I did not have to delete the unresponsive control like you did because EXCEL did not recognize it. You can check this by going to Develop tab and activating the properties view.
Curiously, I found a couple of workarounds this bug in EXCEL:
When I saved the file while in Developer mode, it opened OK and the TREEVIEW control worked, but you have to run a macro to populate. So far it works, but who knows....
When I embedded the TREEVIEW control in a Form, rather than directly in the spreadsheet, it saved and reopened OK, at least so far. No need to be in Developer mode or rerun the populating macro.
Good luck, maybe one of these will work for you.
Related
Since upgrading to Excel 365, my company has been having all sorts of trouble with VBA-supported Excel workbooks crashing or not functioning properly. The issues have popped up in various workbooks and various departments, including seemingly simple VBA workbooks. I've discovered a fix (see below) but it's not sustainable.
The Issues
The various issues we have experienced are listed below. Note, these issues only occur when you open a file in Excel 365 desktop. The same files, when opened in the Excel 365 browser app or in Excel 2016 will work fine. Also, all these issues happen at random. A user may have been working in a file for weeks and then the next time they open the file they get one of these errors.
"Can't find project or library" errors even when we are using the standard set of libraries and basic VBA. Then when you open the VBA Editor window, all the VBA screens are essentially frozen up and the library list is inaccessible.
Excel hard crashes or locks up when opening these files and enabling VBA. Note, the crash only occurs when the VBA is enabled. If you open a file without enabling VBA, it will work fine (though obviously you can't use any of the code).
The file opens seemingly fine, but the VBA doesn't work and once again, everything is locked up when you access the VBA editor window.
"unhandled win32 exception occurred" error
when executing a command, getting an error 32809 which seems to indicate the compiled VBA has been corrupted
The Fix
Opening the VBA Editor window, then selecting Debug -> Compile VBAProject seemingly fixes the issue. I've yet to experience any of the above issues where the file had been manually compiled this way. The problem with this is that every time you add code to a file or any time you add a new tab to a file, you have to go in and perform this manual compile again.
Yes, apparently adding a single tab in a file changes the workbook structure enough that it is necessary to compile again. The Compiled VBAProject selection will be greyed out. But adding a tab (or adding new VBA) will un-grey it and require another manual compile or the problems start occurring again.
This fix also works to repair files where the above issues are occurring. To fix those files, you can:
Make sure "Disable Trusted Documents" and "Disable VBA macros with notification" are toggled on in your security settings so that VBA doesn't automatically run when you open a file.
Open the file with the errors but do not enable the VBA.
Go to the VBA Editor window, select Debug -> Compile VBAProject.
Save the file, close it, reopen it, enable the VBA, and everything works fine again.
But again, this isn't sustainable because all my users will have to remember to go compile VBA any time they add a new tab to a workbook.
Help?
Has anyone found a more sustainable fix to this issue? Is there a bug with the Excel 365 Desktop automatic compiler that Microsoft is working on?
I think I perhaps found an answer in this thread:
https://social.msdn.microsoft.com/Forums/en-US/814ac2ce-ab45-45dc-8c6a-8ef0775d189a/excel-64bit-crashes-when-activating-macros-but-excel-32bit-does-not?forum=exceldev&prof=required
Per that thread – “the cause is that Excel does not correctly save the compile state of the VBA code and 64 bit Excel cannot recover from that issue when opening the afflicted Excel file (32 bit usually can). A fix was released for only Excel 2016 and not for other versions". That would indeed confirm that it is a bug within Excel and explains why we only see the issue with 365 64 bit Excel.
That also explains why my manual compile fix works. Based on the article I found, there is a more sustainable fix. You can change Excel’s registry and force VBA to compile accurately.
To implement the permanent fix:
Open the start menu and type “reg” and select the “Registry Editor”
Navigate to: Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Excel\options
On the Edit menu, point to New, and then click DWORD Value.
Type ForceVBALoadFromSource, and then press Enter.
In the Details pane, right-click ForceVBALoadFromSource, and then click Modify.
In the Value data box, type 1, and then click OK.
In Excel, I’m having my cursor/selection on a specific cell. Up until a recent Office update, the behavior upon inserting an Office.js-powered “content add-in” was like this:
The add-in is being inserted
The container of the web control is focused (you get the resize handles and Excel reveals the Drawing Tools menu) and the focus on the sheet is lost
getSelectedRange() right now would not yield any results but an error
You need to make at least one click into the web control’s area to de-focus the container and focus both the web control and re-focus the cursor/selection on the sheet
getSelectedRange() works now
After a recent update, I’m using Excel for Office 365 Version 16.0.11328.20362 now. And the behavior changed to this:
The add-in is being inserted — unchanged
The container of the web control is focused and the focus on the sheet is lost — unchanged
getSelectedRange() right now would not yield any results but an error — unchanged
Clicks on the web control don’t change the focus anymore, the container keeps being focused!
While the old behavior was already cumbersome as interaction between the add-in and the sheet was not possible directly after add-in insertion (only after at least one click), now not even the workaround of making that single click in the add-in is working anymore.
My original requirement was to read data from the sheet that has been selected just prior to inserting the add-in (just like it works with the native Excel charts). That’s why I had to come up with this one-click workaround in the first place.
What is now the best (if any) way to work with the workbook/sheet right after inserting the add-in with as few quirks as possible?
I have an Excel spreadsheet with VBA programming, form activex controls, form controls. The spreadsheet has worked normally, until last week. I think the problem started when the automatic installation of windows uptade took place, however it might be only coincidence, since I am not positive if this is the cause. Now, the spreadsheet opens and immediately a small window appears that indicates :
“Visual Basic for Applications - Permisson Denied to use object (OK,
Help)”. Selecting help, minimum information and it is irrelevant.
Selecting OK, another window pops out “Visual Basic for Applications -
Unexpected error 419 (OK, Help)”
I cannot even save the sheet to another name. The VBA code cannot run. If I open any new spreadsheet, Excel functions normally, also with its VBA. Just before having this problem, every time that I opened the spreadsheet a window appeared, indicating that Excel blocked the functionalities of the ActiveX controls and asking that if I would allow the use of ActiveX. Today, I enabled all macros and also all activex controls. My previous backups of this spreadsheet have also the same problem. None works. I went to VBA Edit-->References and compared the Libraries I had and the Libraries that are there on the spreadsheet. It seems that no library is missing. How to solve that?
The permissions have changed on your workstation and/or network. Specifically, the folders that hold the DLL files that contain the objects referenced in the VBA. As an example (and I don't know if this is exactly the case, but an illustration), if your code is referencing the Microsoft Scripting Runtime (many VBA projects do), your code needs permissions to access C:\Windows\SysWOW64\scrrun.dll. (I found this by calling up the VBA editor, selecting Tools-->References, then selecting Microsoft Scripting Runtime and reading the bottom of the dialog window for the location.)
This is the location of the DLL on my workstation. Yours might be different or it might have moved during a systems update or the permissions to access that folder may have changed. You'll have to check the locations of all the references in your VBA project to determine this. Sometimes the libraries referenced are located on network drives, which can complicate matters if the network permissions change.
I decided to try to export all the forms (*.frm; *.frx). Everything went fine until I came across to a specific form that had a shockwaveflash object. At this point the message "Permission denied to use object". Bingo!
I then tracked the location on my workstation of such shockwave object reference and applied full administrator control. However, I still could not use shockwave objects. I then uninstalled flash and downloaded the lates shockwaveflash plugin from Adobe. When I open Excel->Developer->Insert->ActiveX Controls->More Controls -> ShockwaveFlashObject and then insert the object in a sheet, the message: "MS Excel - Cannot insert object" appears. I have manually deleted the "*.exd” from C:\Users\[User ID]\AppData\Local\Temp\Excel8.0. Also deleted from C:\Users\[User ID]\AppData\Local\Temp\VBE\, but the problem was still there: "Microsoft Excel - Cannot insert object".
To solve the issue I finally accessed the VBA editor and deleted the userform that had the ShockwaveFlashObject in it. All went back to normal afterwards.
Excel crashes when opening files that contain a userform
This is a known problem with a known solution workaround which is to delete a file called Excel.box from here:
C:\Users\SlowLearner\Application Data\Microsoft\Forms\Excel.box
According to this forum post the purpose of the Excel.box (& Word.box) file is:
Files such as Winword.box and Excel.box are associated with the
Control Toolbox you see when you are designing a UserForm in the
Visual Basic editor. The files contain information about the layout of
the Control Toolbox (additional tab pages, controls that have been
added or removed, custom icons, ...) If a user has never modified the
Control Toolbox in any way, there will probably be no .box file. By
deleting a .box file, you will restore the Control Toolbox to its
default (factory preset) configuration - this is the only way to do
that. Sometimes, the .box file becomes corrupted and must be deleted.
There are no negative side effects to deleting it.
Unfortunately Excel.box returns :(
It would seem that for most users the problem is fixed by deleting the file, sadly not for me.
I'd like to understand what is causing this problem to recur. A few points to note:
this (touch wood) is not impacting MS Word on my PC
I am using Office 2010, 64 bit version on Win10
I have not made any conscious change to form settings
if I delete the file > start Excel > UN-DELETE the file: everything works :-/
some other experiences with this issue here
For the time being I'll just check for and delete the file before launching Excel, but this is hardly an acceptable solution for the long term. Appreciate thoughts for a proper fix... TIA
Additional Information:
I have not fully explored the crash but so far it happens when:
starting the application by opening an xl?.m file with a userform
application does not get past the splash screen
crashes with the application's CRASH screen (... encounted an error...)
starting the application with a blank worksheet then adding a userform
crashes immediately with the applications CRASH screen displayed (see below)
The above crash happened after rebooting my PC, had a chance to explore it some more.
First I opened the file I had been working on (contains userforms):
annoyingly it opened without crashing
I did NOT enter the IDE
I closed the file (Excel closed normally)
Then I created a new worksheet
I opened the VBA IDE
right-click 'add UserForm' - Excel crashed immediately
(I aborted the recovery / search for a solution attempt)
Then I re-opened the file I had been working on
opened the VBA IDE (the project is PW protected)
the very instant that I entered the PW and hit enter Excel crashed
crash was same both times...
Safe Mode:
Crash still happens in safe mode - steps to reproduce:
Run: Excel /safe
Open VBA IDE
r-click add userform
crashes immediately
Creation of the EXCEL.box file
Based on visually observing the folder which had the Excel.box file I did some tests to try and see when it was created. Basically it seems to appear when one of the following happens:
- the UserForm tools box is closed
- the IDE is closed (after showing the userform)
I've also now tried to modify the userform toolbox by removing everything from it. Excel is still crashing after every restart of the application (which is odd as I was not able to crash it like that earlier).
Office Repair - not tested (yet)
Reluctant to try Office Repair as based on the following quote from here (scroll down: pg 1 reply 8 by Steve IT) I'm not expecting it to work :-/ (but will try if no other suggestions surface).
Thanks for the continued suggestions, however I have tried a repair and also removed Visual Studio 2013 and Office altogether (just in case VS was interfering) and reinstalled both, but it still throws the errors reported previously.
Other user profiles
Created a brand new user called 'test'. Test has the exact same problem.
This problem eventually resolved itself, not sure why. I continued to use Excel normally and it continued to crash so I would delete the offending .box file and start over...
As of Nov 2017 Excel no longer crashes with respect to this issue; my best guess is there was an automatic update that resolved the issue.
Looks like this issue still occurs and it is not just limited to Excel but also Powerpoint.
The fix as mentioned above works where you move / delete any files in the below folder location resolves the issue.
C:\Users\%username%\Application Data\Microsoft\Forms
It is highly likely that this error is caused by bad code in a macro or an Add-In that uses forms. The problem is replicating this can be difficult so you have to debug this in some way when it does crash out.
POWERPNT.box
EXCEL.box
are some of the files that get generated, where Excel or Powerpoint crash on the splash screen.
Try adding the command
ThisWorkbook.VBProject.VBComponents("UserForm").Activate
just before your
"UserForm".Show line.
About a week ago, I found that all ActiveX buttons stopped working in all spreadsheets, when running on my computer. They work on others just fine. There had been no issues for the past year.
I know there was recently a Windows updates that caused a stir, preventing people from even being able to click on ActiveX buttons. The issue I am experiencing seems to be different... I am able to click on the button (once clicked, it will show the dotted line around the perimeter of the button). however, nothing happens.
I have these buttons created to open User forms. I have checked to verify the PrivateSub code still exists to launch the form on the Button Click.
Since all my staff are still able to use the spreadsheets and ActiveX buttons, I am thinking there is something occurring locally on my computer, and it is not necessarily programming related, but I have had no luck finding any cause.
Any ideas?
I found a solution to the issue. It appears as though my issue WAS still related to the Microsoft update.. I just happened to be experiencing a different symptom, and needed a different solution as well (rather than just delete MSForms.exd files)
I recompiled the projects (Open VBEditor, Debug Menu, Compile VBA Project), saved workbook, closed excel, and re-opened. Everything worked as normal again.
Unfortunately, I need to do this for all files I work with which have ActiveX controls, which is several dozen.