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.
Related
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.
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 have created an excel vba tool that utilises userforms to create a shopping experience for the user. Once the user opens the tool he will be able to pick orders from the user form. The code then processes the orders and returns with a calculated estimated cost.
The Problem is I don't want to let the workbook(and sheets in it) visible to the user. I need to hide my active workbook without any pop ups.
I recently crossed with the below solution however, I found out that upon initial launch by the user, he encountered "Security Warning Macros have been disabled. Enable Content (button)" which renders the initial solution worthless. Any advice is appreciated. TIA.
ActiveWorkbook.Windows(1).Visible = False
forgot to mention the obvious
XLAM
save your book as an xlam. put it in the addin folder (or explicitly point to it) and select it through Excel's interface.
addins are not visible by default
you still have to manage the security warning, frankly this is a user concern that you'll likely be forced to address and it's an issue that will never go away.
i will not say this is "good" advice and you may scof or reject the idea on principle, but if you don't have a legit way of signing your projects, consider the possibility of installing a personal cert on the users computer and signing the project locally or walking users through the process remotely
You can permanently enable macros for a certain workbook in the Trust Center of the excel workbook. So whenever the user opens the workbook, he/she will not need press the button each time to activate anything macro related.
In your case you want to select: Enable all macros (not recommended; potentially dangerous code can run)
After a while of not opening Excel on a specific PC, I have noticed that ALL the add-ins are disabled (even Solver and Data Analysis Tool packs). What I have noticed is that I am able to re-enable them by first deactivating and then activating them as one would normally do. And they all work just fine as usual. Unfortunately, once I close Excel and open it again, all the add-ins are once again disabled, even though Add-In Management dialogue box shows them being activated (ticked boxes)... I have tried to find the same issue both here and by googling but has been unsuccessful so far... Perhaps my query is not accurate enough. I would greatly appreciate any help from the community.
I stumbled on a way to crash excel in Workbook_Open while making an .xla It's still a toy project, so I've been able to just delete it and start over (and now I'm coming back with version control and baby steps.)
However, assuming I didn't have those options, how would I possibly edit the .xla remove the fatal code, since I have to load it to edit, and loading it crashes the editing environment?
This isn't exactly what you are looking for. But some advice during development.
I always work on my xla files as xls files until they are stable. That way if it isn't stable, I can just not enable macros on opening, and fix the problem, then close and reopen with macros enabled.
--EDIT--
I did some more research, because I was curious and because I remembered hearing about disabling macros on startup. Here is a link that says you can hold 'Ctrl' while Excel is starting, to start in Safe Mode. There is a bit of other information that is worth a read to see if it applies.
http://support.microsoft.com/kb/826922
--EDIT 2--
Another link that says holding 'Shift' might also do the trick
http://www.mrexcel.com/forum/showthread.php?t=348351