I want my workbook to open in its own separate instance of Excel. If it gets opened with other workbooks, it should reopen itself in a new instance, perhaps using a code in the Workbook_Open event. Additionally, the workbook should prevent files from opening in the same instance, perhaps by moving them to a new instance or moving itself to a new one. Any ideas will be much appreciated.
Edit:
The purpose of this is that workbooks loaded with code and userforms tend to crash easily causing all other workbooks open in the same instance to crash and lose all unsaved changes and the end user gets frustrated. Another issue is that when the Application.OnKey is used, I experienced three problems: 1. shortcut triggers a code that's usually intended to act on the workbook it resides in. This can be solved by checking whether the hosting workbook is the active workbook before running, but it's better to prevent them from running in the first place. 2. common shortcuts can be reassigned to run a custom code, but usually this shouldn't affect other workbooks. 3. problems happen when multiple workbooks that assign same shortcut to custom subs. the most recently open workbook takes over the shortcut action. Also, when the workbook that contains the shortcut is closed, using the shortcut reopens the workbook automatically, which is not a desired! Removing the custom shortcut doesn't solve the problem of multiple workbooks using same shortcut.
Therefore, best solution is to start such workbooks in their own application instances.
I've had to make an Excel workbook (which was running a timer) reopen itself in another instance of Excel. This was to let the user use the first instance of Excel without the timer interfering. I'm not sure if that's exactly what you need, but that can certainly help you get started. You can find the code on GitHub here.
The procedure that you would be interested in is called OpenItSelfInAnotherInstance and is located in OpenItself.bas.
For it to work you will also need to include the code contained in API_Maximize.bas, API_Sleep.bas and UDF_ExcelIntances.bas. (If you copy-paste, always exclude the line that says :Attribute VB_Name =... since it's there only for when you import the *.bas file in from the VBE)
Please let me know if there is anything unclear in there, so I can add some explanations in my answer if needed.
Related
Question to Excel specialists:
I was confronted with some inexplicable XLAM behaviour from users in recent days. A bit of screen sharing today piqued my curiosity. The affected user had an XLB file loaded. I enquired about that. His answer: Windows had performed an update and when he logged in after, this Excel session had bootstrapped itself.
The XLAM is stateful. It constructs the initial state on Auto_Open. I have a FEELING that when Excel launches in the particular fashion described, it disables the macros on the workbooks it loads.
I do not know any way of checking whether a given workbook in an Excel session is macro-enabled or not. In fact, the only way I know of enabling macros after they had been disabled is by reloading the workbook. So, I cannot tell whether this XLAM has macros enabled. And I know of no way of reloading an XLAM either.
The circumstance that other workbooks loaded later into that same session had their macros enabled (which apparently allows them to call the XLAM) does not produce the required initialization - and that would explain the cascade of #Value!s.
Can anyone confirm or deny my feeling? Thanks for reading.
I have a macro that extracts data from Microfocus RUMBA Mainframe Display and puts in Excel rows one after the other. I have created a Global Mainframe object and that is used for extraction to Excel. But when the process is running and if user decides to stop the processing he cannot click on Stop button on Excel or go to different tabs to see the data being pasted. He has to clicks like 6 times before tabs are switched or stopped.
I see that DoEvents allows mouse click events in the loop to do things but the code is written in a way that there is a lot of lines with in the loop and a function with no loop, and placing DoEvents after everyline seems irrational. I have a feeling there is a better to do that but not sure what that is. Can anyone please help?.
VBA is single threaded. So you can't have one VBA action interrupt another. If you had a cancel button, for example, and the user was allowed to click it via a DoEvents processing the cancel action would still run after the currently running procedure.
In Excel this single threaded nature ends up being a good thing because you generally don't want the user interacting with the workbook while you are making programmatic changes. If this was allowed you would get undefined behavior.
Your best course of action would be to make a .NET application that uses the Excel Interop extensions to move the data from the mainframe to Excel. If you use VB.NET then you will find the code is quite similar to VBA. In fact, the Excel.Application object model is identical so the macro code you already have ports cleanly over.
There is an add-in that will help RUMBA development here:
https://www.microfocus.com/documentation/rumba/desktop951/RumbaSystemAdminGuide/GUID-DDB7571D-6167-4F8B-876E-E7450F3030B2.html
I have a reasonably complex group of scripts to perform a certain function for my work. Due to the nature of the work, I have validated the code and have it locked down fairly tightly with passwords to prevent improper use/editing (the script is also locked down, but there are no problems with that for this query). This all works well and if it ever has errors, it exits and re-protects the individual worksheets and the workbook. All macros are run via buttons (actually just objects with macros assigned, not the older style coded buttons) on relevant worksheets and output is good.
However, this morning I discovered that the macros can still be run through the standard Macro screen (Alt + F8). As I have a number of scripts in there that I use for development of updated versions, I want to disable this function.
I did a search for options and found UserInterFaceOnly, but it didn't work for my on Excel 2010 and I am led to believe that it may not be used in later versions.
Is there anyone who knows how to disable the ability for the user to run macros through the Alt + F8 Macro window, whilst allowing macros to be run that are assigned to objects within a worksheet?
The code that locks the worksheets/workbook is as follows:
For Each ws In Worksheets
ws.Cells.Locked = True
ws.Protect Password:=strPWD
Next ws
ActiveWorkbook.Protect Password:=strPWD
I have found a good solution using a different approach. Rather than trying to lock the capability, I have used the 'Option Private Module' entry at the beginning of the module, meaning that the user never gets to see the macros that have been written.
This solution is an obvious one when you think about it, but having not used the Private Module option at all previously, it didn't initially occur to me. Hopefully this answer to my own question will benefit some other people in the future.
I automatically open, edit, save and close several Excel workbooks from a Sharepoint location. The following code opens the workbooks (path loops through a list to hit each workbook name):
Workbooks.Open Filename:=path, ReadOnly:=False, Editable:=True
The files open in Read-Only mode, and the yellow dialogue option to Enable Editing does not appear.
I edit these workbooks manually and through a macro, but I am unable to save the files back onto the Sharepoint afterwards without saving as a new file.
I am using Excel 2013. This was working as intended about a year ago, but I believe there may have been updates to Office 365. I checked all of the Excel workbook security options, and nothing is set to open by default as Read-Only.
Is there any way to open the file in an editable mode through the macro, or at the very least allow the Enable Editing option to appear for each workbook?
I have been trying to fix the same problem for my files, and eventually did! So I felt that I could maybe let others know. And this old-ish thread came up near the top of my google search.
What fixed it for me was to edit the link.
from:
https://Company.sharepoint.com/:x:/r/teams/TeamNo/Shared%20Documents/Example/CoolFolder/TheBestExcelFile.xlsm
To:
https://Company.sharepoint.com/teams/TeamNo/Shared%20Documents/Example/CoolFolder/TheBestExcelFile.xlsm
Note that I only used replace to get rid of :x:/r/. I feel like I should have noticed this before but I didn't and no amount of meddling with the Workbook.Open parameters got me anywhere. It just seems odd that the default link copy thing gives you one with special commands in it. For our company most folders have spaces so the link has tons of "%20" in there so I simply read over the ":x:/r/".
Hope it helps someone.
Just for clarity, try this:
Sub Example()
'1.) Get filepath from somewhere
FilePath = Replace("https://Company.sharepoint.com/:x:/r/teams/TeamNo/Shared%20Documents/Example/CoolFolder/TheBestExcelFile.xlsm", ":x:/r/", "")
'2.) Open the file
Set StatisticsFile = Workbooks.Open(FileName:=FilePath, Password:="123")
'3.) Do things
'4.) Close the Sheet, save the changes. I simply like it this way, could be done in a single line.
StatisticsFile.Save
StatisticsFile.Close savechanges:=False
End Sub
I noticed this solution because I could still save the .xlsx file manually with the same name if I navigated to SaveAs. So if you guys can still do that after opening the file via macro, try a similar solution.
The interaction designed for Excel-OneDrive-SharePoint is new in 2016 apps and that version is a requisite to properly work.
The version 2013 may work by tweaking the OnDrive “Account” settings regarding Office co-authoring configuration which is specifically applied to Excel and Word
Right click the OneDrive icon in the taskbar to reach settings
Good luck!
I know your query was posted long ago but I have found the solution to remove the Read-Only blocker and update the excel document via Macro:
If you add "ActiveWorkbook.LockServerFile" after the code of opening the file, then it removes the Read-only and updates the excel as normal.
I can't get the name of the workbook when I use a add-in.
I'm trying to develop a add-in that runs each time you open Excel and reads the filename of the open file.
If the file name is XCFIL.SKV then do something...
This code should do it, but it doesn't. What am I missing?
The code stops and if I debug and press F8 it works fine, but it won't run on it's own.
Private Sub Workbook_Open()
If ThisWorkbook.Name = "XCFIL.SKV" Then
MsgBox "y"
End If
End Sub
Background:
Based in this statement The code stops and if I debug and press F8 it works fine, but it won't run on it's own. I assume the problem relies on the speed of the processor that is not sync with the code (own experience).
Solution:
Since it is Excel and the problem seems to rely only in the opening of the instance itself, you may use Application wait or any of the other functions for this matter.
Further thoughts:
Life cycle comes to my mind in these kind of scenarios. This web page has a neat Lifecycle diagram of excel instance (attached since I will try to explain the scenario)
As you may see "Application" is the first cycle of the Excel application, followed by "Open" and after that "Workbook" object, it may happen that in this life cycle "worbook" has not been created when "Open" comes to play,hence, you need to wait until excel solves this.