Not a duplicate because the issue described here happens despite having deleted the *.exd files as suggested in the answer to Excel renaming Activex Controls on other computers and elsewhere.
One particular machine on our network (let's call it "Computer 2") spuriously and silently changes the code name of ActiveX command buttons placed in Excel workbooks. Whatever the (Name) property of a button was before, it returns it to the default CommandButton* scheme. (CommandButton1, CommandButton2... etc.)
Witness the screenshots below. The code name of btn2 changes to CommandButton1 when opened on Computer 2.
Why? How do I fix this?
I can even have the exact same workbook opened from the same Book1.xlsm file on a network drive simultaneously on both machines (one of them read-only, obviously). Looking at both screens at the same time, the button names are different! Computer 2 changed it.
This, of course, breaks the functionality of the buttons, because they no longer trigger their intended event code. In the example below, btn2 used to call Private Sub btn2_Click() from the sheet module and execute the code in that Sub. But on Computer 2, the button is no longer named btn2, so it doesn't trigger that event; it does nothing — or worse, if there happened to be a button called CommandButton1 before, it triggers that unrelated event.
Workbook opened on Computer 1:
Exact same workbook, but this time on Computer 2:
Now, this has happened to me before. Once or twice over the years, on a couple different machines, all my commandbuttons got renamed like that. But I've never been able to reproduce this, and I thought, corrupted workbook, no big deal.
But this happens consistently on Computer 2, every single time.
Non-ActiveX, Form Control buttons, such as "Form Button 1" in the example above, are unaffected by this issue. An obvious but tedious fix would be to get rid of all my ActiveX buttons (as suggested in this answer) and convert them into e.g. Form Control buttons, but the aim is to avoid this nuclear option.
First, I have very limited knowledge of VBA.
Second: I have no idea why this happens, but I have an idea for how to fix it... In workbook_open could you run code that renames any CommandButtons to your desired name? It would be annoying, sure, but it would be at least a temporary fix until someone can find out why on Earth this happens! :)
Sub Not_Workbook_Open()
Dim btn As OLEObject, increment As Integer
increment = 1
For Each btn In Sheets("Sheet1").OLEObjects
btn.Name = "btn" & increment
increment = increment + 1
Next
End Sub
Since none of any recommended solution worked for me, I am assuming some people still have that problem and are interested in the fix that helped me:
Make your button names shorter!
Sounds stupid, but I found out that button name length has it's limits.
Try this out by making a new sheet with one ActiveX CommandButton in it.
Then add this code and execute it repeatedly by pressing F5:
Public Sub test()
For Each o In ActiveSheet.OLEObjects
Debug.Print Len(o.Name); Tab(5); o.Name
o.Name = o.Name & "X"
Next
End Sub
You will notice that the code stops executing after
31 CommandButton1XXXXXXXXXXXXXXXXX
And yeah, I found this fix because I was desperate enough to try seadoggie's solution, which failed because you can't read a button's caption to identify which name the button should get. :)
A colleague found out that this can occur if there is a mix of Office 2010 and Office 2013 products installed on a machine. The procedure to fix this is:
Download these patches:
Office 2010 patch: http://support.microsoft.com/kb/2553154/EN-US
Office 2013 patch: http://support.microsoft.com/kb/2726958/EN-US
Close all Office programs (including Lync if you have it).
Install the Office 2010 patch.
Install the Office 2013 patch.
Remove *.exd files from your profile and for all other user profiles. For instructions, see this Stack Overflow answer and this Microsoft solution.
Restart your machine.
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
There are several instances of this problem, but this one is predominant. This is in relation to updates (our most notable problem child being KB2726958). We have a Leave Spreadsheet that looks like this:
Leave Spreadsheet example
By pressing the grey Leave button, you end up here:
Leave Word doc
All the programming for these is written in VBA (i've never worked with VBA before, I can understand it to a degree).
Now, the issue is that using the ActiveX button in the 'Leave Spreadsheet example' causes the 2 buttons 'Send by Email' and 'Save' to switch functions; Send by email attempts to save and save opens up Outlook and creates the email message.
Both functions have completely retained functionality, just on the wrong buttons.
The thing I find weird is that a hyperlink to the very same file works; the buttons aren't switched and have full functionality. The only hint that I have towards resolution is that when using a hyperlink, it's directly opening the file. When using the ActiveX button, it seems to be creating a new file based off the file it's linking to. For example, the hyperlink directly opens C:\Report.dotm but the ActiveX button opens Document1.doc with a template based on Report.dotm.
I'm considering that maybe the activeX button is opening up Word with an incorrect extension? But i'm not sure how to figure this out (code below shows that the linked file on the activeX control is a .dotm).
What further throws a spanner into the mix is that it only affects some computers... Considering on-site we all use the same type of PC with the same image... :(
My question is, does anyone know why they may be swapping? They're located on the same network drive albeit different directories. They require the same permissions to access. The code for the buttons is as follows:
Excel Button:
Private Sub CommandButton1_Click()
' This button links the excel spreadsheet to the word doc
Dim wrdApp As Object
Dim wrdDoc As Object
Dim i As Integer
Set wrdApp = CreateObject("Word.Application")
wrdApp.Visible = True
Set wrdDoc = wrdApp.Documents.Add("\\networkdrive\directories\Request for Leave.dotm")
End Sub
Word buttons 1 and 2:
Private Sub cmdSend_Click()
' This is the code for the button 'Send by Email'
MsgBox "Send the following email to your Team Leader/Line Manager", vbInformation
SendDocumentAsAttachment "", "IPL Request for Leave"
End Sub
Private Sub cmdSave_Click()
' This is the code for 'Save'
modSend.SaveLeaveForm
End Sub
Please Note: The comments above are not in the code in VBA, i've written them in myself in this question to provide clarity.
Troubleshooting that i've done:
Removing all .exd files
Running the MS Hotfix (removes all .exd files in a GUI)
The next step would be to try running all 6 patches related to fixing ActiveX controls with the particular patches we've done to see if that fixes the problem. The reason I haven't done this yet is because of ITIL (Change management) although I may try testing this later today.
What is the outcome i'm after?
Ideally, I want to understand what is causing these buttons to, from what it looks like, swap their functions. I have different scenarios of button swaps, some of which are remedied by removing the .exd files, and some that aren't.
By understanding what is happening, I hope that I can apply the knowledge to the other scenarios (same problem, different coding).
Then, I'll be able to document my findings so that when we perform the next round of patching that is known to break ActiveX controls, my organization will know how to deal with it.
So the patch mentioned below has fixed this issue. There's still some other issues that I need to test this patch against, but I definitely should have started there. Lesson learnt.
From my work email:
I’ve just tried using the patch related to the ActiveX controls breaking, KB2920754. I’ve used it on two PC’s here in the training room; both had different issues:
- The first one had buttons that had switched around (save attempted to email, email attempted to save)
- The second one couldn’t use the buttons at all.
This patch cured both w/o requiring a restart or logging out and back in. I didn’t remove any .exd files, either.
It does state, however:
“Important For this fix to be fully effective, you also have to apply the other patches for Office 2013 that are listed in the "Resolution" section of the following Microsoft Knowledge Base article”
There are 6 in total.
Patches:
1. KB2920754 – (the one I’ve used successfully)
2. KB2956145
3. KB2956163
4. KB2965206
5. KB2956176
6. KB2956155
I have a workbook with lots of sheets and several macros. When I enter VBA and try to write a new Sub into ThisWorkbook module, I see:
"This will reset your project, proceed anyway?"
assuming, that some project is currently running.
If I press Ctrl + L right after opening the file to check the Call Stack, it just shows nothing.
I did non run any macro myself and there's not a macro, which would handle any event (as far as I checked all sheets and modules in the project) except a little sub for saving event:
Workbook_BeforeSave (ByVal SaveAsUI As Boolean, Cancel As Boolean)
but this one AFAIK should be activated only before saving, thanks to Captain Obvious.
Another mysterious thing with this book is abnormally slow filtering for structured tables, which may be cured by turning off event handler:
Application.EnableEvents = False
Since both these facts are related to Events, I guess they might be somehow connected to each other.
Updated to include comments below.
Well, the problem still exists and I appreciate any idea that may help to locate this pesky macro running totally hidden.
Hm. Anyone with any ideas?
One way to reproduce the behavior that you describe is as follows:
1) Have a public variable which is initialized in Workbook_Open()
2) Have the option Notify Before State Loss enabled (under Tools/Options/General)
In this case when you first open the workbook and try to create a sub you see the warning about resetting the project even though no macro is currently running.
If this is the case, a simple fix (if it still bothers you) is to disable Notify Before State Loss.
On the other hand, it seems that your project has more general problems. VBA projects can become inexplicably corrupt and this might be the case here. A fix which sometimes works is to export all modules, userforms, etc., delete them, and then reimport them. Rob Bovey (a highly respected VBA guru) has written an add-in called Code Cleaner to automate the process. I haven't used it personally but it might be worth a try.
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 have created a Macro which is working just perfect in my machine (Windows 64 bit & Office 32 bit)
But client is facing issue. He is having Windows 64 bit & Office 64 bit.
Don't know why but Sheet.Activate is not working on his machine. Refer below screen prints.
Based on your input, I cannot find back a declaration of "Recordsheet".
Since you input this code in the event routine "Workbook_open", I doubt that you did the declaration anywhere.
If you want to apply
RecordSheet.Activate
The least thing you should do is:
Set oRecordSheet = thisworkbook.sheets("Records")
oRecordSheet.activate
I strongly doubt that your version of Office / Windows has anything to do with it.
Vba is not supported by Microsoft anymore and no further developments to the language are made.
If it's a client, take into account the possibility that this client might have changed the name of the sheet.
In case you properly set the sheet object, this may also be the source of the problem.
Edit:
After looking at your file received by mail, I confirm that the above solution fixed the bug.
Replace the entire
UserForm_Initialize
Subroutine with:
Private Sub UserForm_Initialize()
Dim oRecordSheet As Excel.Worksheet
Set oRecordSheet = ThisWorkbook.Sheets("Expense Report")
oRecordSheet.Activate
EnableDisableConrols (False)
Call FillDropDowns
Navigator.Max = RecordSheet.UsedRange.Rows.Count
If RecordSheet.UsedRange.Rows.Count = 1 Then
RowNumber = 1
Else
RowNumber = 2
Call FillDataIntoControls
End If
End Sub
Edit 2:
The above solution is correct, BUT, if indeed the codename of your sheet is set to RecordSheet, you can use this solution too. However, note that the codename can only be used with the workbook.
I would think there may be missing references.
go to Tools -> References, and see if any are listed as missing
Remove the checkmarks there, and the basic stuff like date will start working again. If those references are critical to the code you are running, you will have to search out the 64 bit equivalents
More about references - normally resolving "Missing" fixes it, but, from here
What you're describing is typical of corrupted references. This can
be caused by a referenced file being a different version or in a different
location between the machine on which the code was developed, and the
client machines. Our company also tries to keep all the machines configured
the same way, but I've found it's essentially impossible to manage.
Open any code module (or open the Debug Window, using Ctrl-G, provided you
haven't selected the "keep debug window on top" option). Select Tools |
References from the menu bar. Examine all of the selected references.
If any of the selected references have "MISSING:" in front of them, unselect
them, and back out of the dialog. If you really need the reference(s) you
just unselected (you can tell by doing a Compile All Modules), go back in
and reselect them.
If none have "MISSING:", select an additional reference at random, back out
of the dialog, then go back in and unselect the reference you just added. If
that doesn't solve the problem, try to unselect as many of the selected
references as you can (Office may not let you unselect them all), back out
of the dialog, then go back in and reselect the references you just
unselected. (NOTE: write down what the references are before you delete
them, because they'll be in a different order when you go back in)
(as a side note, disambigulating as VBA.xxxx will work, since Excel no longer has to
look through all of the references.)
The first line of your code shows a UserForm. Some widely-used form controls (those defined in the ComCtl library) don't exist in the 64-bit version of Office so it's highly likely that the UserForm is the problem.
There's no easy solution unless you can convince the client to use 32-bit Office instead or alter your UserForm so as not to use the affected controls.
Affected controls are: ImageCombo, ImageList, ListView, ProgressBar, Slider, StatusBar, TabStrip (although there is an alternative version of TabStrip in the normal MSForms library), Toolbar, Treeview
Details of the problem are discussed in this thread and confirmed here