Excel changes Link to Add-in - vba

I need to link up an .xls (must not have macros) to a macro on our network. I thought I had found a good solution, which uses a shape to link up to a macro that is set an add-in in Excel. This method worked well for over a year, but now things are starting to act REALLY ODD. Excel keeps changing my links from the network to the local drive!
Basically, at my computer I run code that creates a button and sets the .OnAction value to 'SPC_BUTTONS.xlam!EXPORTSPC' which excel sometimes updates to 'G:\NetworkLocation\SPC_BUTTONS.xlam!EXPORTSPC' (sometimes it leaves it alone). I linked up the add-in to run from the network (and don't copy it locally) so this is a correct address for it. However when I move the file from my computer, to the network and on to the final computer, the link will change to 'C:\NetworkLocation\SPC_BUTTONS.xlam!EXPORTSPC'. The file's links work until the point it lands on the local computer.
'Check if SPC Button already exists
Dim exportButton As Shape
On Error Resume Next
Set exportButton = InspectionWS.Shapes("SPC Button")
On Error GoTo 0
If Not exportButton Is Nothing Then
'Delete the old button
InspectionWS.Shapes("SPC Button").Delete
End If
'Create "SPC Button"
InspectionWS.Shapes.AddShape(msoShapeRectangle, 770, 600, 160, 36).Name = "SPC Button"
Set exportButton = InspectionWS.Shapes("SPC Button")
With exportButton
.ShapeStyle = msoShapeStylePreset34
.TextFrame2.TextRange.Characters.Text = "Export SPC Data"
.TextFrame2.TextRange.Font.Size = 20
.TextFrame2.WordArtformat = msoTextEffect8
.OnAction = "EXPORTSPC"
End With
The first time I saw this problem was when I had changed the add-in. I had made another macro in that file called EXPORTSPC2, and had swapped names with original when it was time to go live. That's when all of the links became broken. I swapped back the names and decided to just swap the code, in case position mattered. Still didn't help with the linking.
I looped the original macro that set up the buttons on every file again, but that failed to rectify the problem. Several hours later, after trying a lot of options I found setting .OnAction to just 'EXPORTSPC' did again get some files to link up again, but ONLY if I did it on the local computer. I had tried the full address, a local address (and moving the add-in location), and SPC_BUTTONS.xlam!EXPORTSPC and of those still ended up with 'C:/Networklocation.xlam!EXPORTSPC'... even when set on the local computer.
The problem is, yesterday, it happened again when someone had replaced the updated files with another set of files he had been modifying on the network. This time around I wasn't surprised to see that they didn't link up (although disappointed), but was surprised that the my code looping the update to EXPORTSPC failed to 'take' for all of the files on the second computer. Only a handful of them would actually change to EXPORTSPC, and I ended up having to assign the link locally on the final computer(s), by hand, for each of the 45 .xls files.
Really, I can't keep doing any of this local repairing, as it creates machine downtime.
So my questions! Is there a better way to do what I'm trying to accomplish (.xls to add-in)? Any idea as to why is moving these files causing excel to change the link, forcing me to set them up locally? Why does it suddenly not accept anything but EXPORTSPC as the link name? Does excel save some sort of ID for macros/add-in/buttons I'm unaware of I'm accidently breaking?
Really, Any sort of insight will help. Thanks!
EDIT:
I did find an error in my looping code, which effected the issue I had on the second computer. It was looping through each workbook fine and saving... but I didn't activate the workbook before running the code, which was pretty important (DOH!). This only resolves the problem I ran into yesterday where I had to edit by hand.
However, digging a little deeper, I do feel like I have a better understanding. I used the code below to determine if what I see in 'Assign Macro' matches the stored .OnAction value, which it does not. Testing on my computer this code:
exportButton.OnAction = "'G:\NetworkLocation\SPC_BUTTONS.xlam!'EXPORTSPC"
would cause the 'Assign Macro' to change to 'EXPORTSPC', even though debugging
debug.print exportButton.OnAction
still displayed the original OnAction value. When I moved the file to the shop floor computer, 'assign macro' would display 'G:\NetworkLocation\SPC_BUTTONS.xlam!'EXPORTSPC until I clicked it, and then it would switch to EXPORTSPC.
So it seems Excel does keep track of where the macro is located once it detects the correct location. I swapped the macros around and it seemed to have broke the connection. My guess is excel then modifies the location to the C:\ once it's internal link is broken. If anyone has any elaboration/verification of this, I'd love to hear it.
I do recall having the add-in button becoming unchecked randomly, which may have been playing into why links kept breaking and reverting to the c:\ while I was debugging what would work. I'm not sure what was causing that either. But using the all forms of exporting seemed to work today. I'm still not convinced that I won't see it again though, since I don't fully understand what was the catalyst of unchecked boxes and swapped links.
If Not exportButton Is Nothing Then
With exportButton
.OnAction = "'SPC_BUTTONS.xlam'!EXPORTSPC"
'.OnAction = "EXPORTSPC"
'.OnAction = "'G:\NetworkLocation\SPC_BUTTONS.xlam'!EXPORTSPC"
End With
Debug.Print exportButton.OnAction
End If
So parts of the process still seem fuzzy, but at least now I know how to better track what I'm seeing.

Try this -- qualify the Add-In filename:
.OnAction = "SPC_BUTTONS.xlam!EXPORTSPC"
I have tested this with an XLAM on a network drive, and an XLS file on my desktop. I have copied the XLS file to a network location, and it still works. I have also done a SaveAs to put the XLS file on yet another network drive, and the action continues to work.
This of course requires that the user's instance of Excel has the Add-In enabled.
Alternatively, try enclosing the path & filename in single-quotes:
.OnAction = "'G:\NetworkLocation\SPC_BUTTONS.xlam'!EXPORTSPC"
This method seems to be preserving the OnAction absolute path.

Related

Disable Macros from Safe Mode

I wrote a macro that now is causing issues with MS Word. I can only open the document in safe mode and cannot figure out how to delete the macro from safe mode. I don't have access to any of the features in safe mode and the macro isn't even showing up. I tried changing the Trust Center settings but none of those options make a difference. Unfortunately I was very dumb and made it a macro on all documents so I can't open any documents without going into safe mode. help!
To be more specific, I believe the code that broke my MS Word was a OnError GoTo ErrorHandler where I tell it to skip to the next if there is an error. I am working on converting equations to a professional format and some of them don't have the right syntax for the conversion so for now I wanted it to ignore those equations and convert the next equation. That is the only change I have made recently that could be the problem.
An additional edit: the macro is coded to run on open. It was running fine before I added the ErrorHandler. I'm sure this is also a huge part of the problem, but a simple solution may not be the right fix since it automatically runs when I open the document. I can't access anything in safe mode.
If you are talking about the "Normal" document in the project explorer, resetting it is easy.
Simply navigate to %AppData%\Microsoft\Templates and either delete or rename the Normal.docm file. Once you reopen Word it will regenerate a brand new file automatically - one that contains no code.
You created an AutoOpen macro which only fires when a document is opened. Presumably this macro is stored in your Normal template.
When you first start Word the macro should not run as you are not opening a document. If Word doesn’t automatically create a new blank document you can safely do so. You will then be able to access and edit the macro you created.

VBA, problems opening .xlsm file on Share Point with Workbooks.Open method

Background:
As part of version control subroutine in my VBA macro, I'm opening a .xlsm file stored in a folder on our corporate Share Point and saving it on a local hard drive.
The file gets opened by Workbooks.Open method, i.e.
Workbooks.Open Filename:="https://<mySharePointFolderPath> & "/file1.xlsm"
When I rolled this out initially, it worked fine for everyone in the team (myself including), apart from one user. At first I thought it was that user's own network issue (they worked from home that day), but when they tried this in the office a few days later, the macro failed again on the above line. The error message says:
"Run-time error '1004':Excel cannot access the file. There are several possible reasons: -The file name or path does not exist.-The file is being used by another program."
None of these applies in our case though.
So I started testing this and somehow managed to cause it to fail for me as well. I can't remember exactly what was it I did, but it was either when I had the file1.xlsm open in Excel the moment I tried to open it again from SP, or when I temporarily removed the file from SP but tried to open it with the macro anyway. Most importantly though, now it fails for me every time I try while it continues to work fine for everyone else (apart from that other user).
Problem:
Unable to open the file from Share Point using:
Workbooks.Open Filename:="https://<mySharePointFolderPath> & "/file1.xlsm"
Other factors:
The affected user and I are both able to:
go to SP folder (via internet browser), download file1.xlsm and open it.
open other .xlsm files in that folder using the above method.
open the .xlsm file in question with Workbooks.Open after it has been renamed (to i.e. file2.xlsm)
open file1.xlsm after modifying the above line to: Workbooks.Open Filename:="\\<mySharePointFolder> & "\file1.xlsm"
but it takes much, much longer to resolve AND still triggers the error 1004 message.
However
opening the file from Excel/File/Open menu (i.e.
File/Open/SharePoint Sites, etc.) gives both of us the following error
message:
"No items to show - We can't open this workbook. It's set to show only certain named items, but they aren't in the workbook. You might
want to contact the author for more information."
While the workbook does have some named ranges which are hidden and
other named ranges that are visible but refer to xlVeryHidden
worksheets, they all are in the workbook, I am absolutely sure about
that. Plus, if this was the cause of the issue, then it should not
work for other users of after simply renaming the file.
So, it behaves almost as if Excel somehow remembered that it once failed trying to open file1.xlsm and is failing every attempt since (no, it's not listed under disabled add-ins).

MS Office - ActiveX Buttons switching places

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

Check for "save changes to 'filename' prompt w/ VBA?

First off, this is not about the saveasfilename dialog box.
Is there a way to have a flag set that checks to see if the "want to save your changes to 'filename.xsls'? dialog box appears during a VBA sub ?
Basically I have a macro that copies some data into another file, displays a MsgBox then closes the file and Excel SHOULD prompt the user to confirm that the file is saved. However, I have a legacy program that locks that file sometimes, causing the prompt to not appear, and it looks like the file was saved but actually wasn't. To 'fix' it I have to close all instances of Excel and the program and start over. It doesn't happen often, but you can miss it if you aren't paying attention or someone less experienced in the process doesn't know to check to make SURE they are prompted to save.
What I'd like to know is if there's a way to have some sort of check / flag value, 1/0, true/false, etc to make sure that dialog box appears. If it doesn't then warn the user that they need to restart Excel and the other program. Basically I'm trying to catch an error that should never happen, so this might be unsolvable.
This is the dialog box I'm referring to:
Sometimes it doesn't appear because the file is locked and the VBA sub just continues on.
It would probably better to solve the other problem, but since you don't have posted it, we don't know it.
Anyway, everything you want is described here: https://support.microsoft.com/en-us/kb/213428
You can bascally do this:
Sub Auto_Close()
If ThisWorkbook.Saved = False Then
'ThisWorkbook.Save this would autosave
Application.GetSaveAsFilename 'this displays the save as dialog
End If
End Sub
I ended up doing this as a work around and it's not truly a solution to my question although I suspect there's got to be a way to do it through window classes checking or something. Thank you to everyone who took their time to chime in and offer their brainpower :)
I declared two variables for the file size before and after the sub runs. If the file sizes are equal, then a msgbox appears and says the file may have not been written correctly, or you are overwriting the existing file.
Dim ExportFileByte As Long
Dim ExportBytePostFile As Long
ExportFileByte = FileLen(ExportSourcePath)
' (sub runs here and exports a copy of some data to an .XLS file)
ExportBytePostFile = FileLen(ExportSourcePath)
If ExportFileByte = ExportBytePostFile Then MsgBox ("Error: File may have not have saved, or file is being overwritten without changes (OK)")

Word opens for real when trying to fill-in the blanks dynamically?

I'm currently using Word documents as templates where blanks have to be filled dynamically/programmatically in PwoerBuilder.
This has always worked fine until the company moves on Windows 7.
In short, the Word application is opened and made invisible.
Word.Application.Visible = false
Except that sometimes, and I don't know why, once the template is accessed, Word opens itself just as if I had double-clicked the template byself through the Explorer - but I didn't.
So, it asks whether I want to open it in read-only mode, since the application already has a handle on the file. And even if I click [Cancel] not to open the file, Word opens with no document, then the application crashes.
It reports PowerBuilder System Error 35.
Error Number 35.
Error text = Error calling external object function open at line 24 in function of_fusion of object n_cst_9999.
The external object that the application is trying to call a function against is Word.
oleobject lole_word
lole_word = create oleobject
lole_word = ConnectToNewObject("Word.Application")
lole_word.Documents.Open("templatefile.docx")
It may work for a few documents, and after a few, the problem comes up. This is the first time ever I meet with this issue.
I'll be glad to answer anyone's question who's trying to help.
Will, you may try setting DisplayAlerts and FeatureInstall properties on Word Application object.
That hid most of word alerts for us. (The code is from C# project and may not be exactly what you need)
Word.Application.DisplayAlerts = Word.WdAlertLevel.wdAlertsNone;
Word.Application.FeatureInstall = 0;
You may also try making a copy of the file before opening it to avoid accessing same .docx from different threads - if that may be the case.