Assigning Key to Macro - excel

My real motivation for writing this was Macros Not Showing Up in Macro Table. But the macro question is really just a plain vanilla Sub located in a Module file. Literally:
Public Sub LaunchRecognia()
GetRecogniaFactory.GetRecogniaVm(ThisWorkbook).ShowForm
End Sub
Thinking it might be a security issue but I doubt it (see below).
However the only reason I wanted the dialog was just to assign a shortcut key, so thought I might see if anyone knows how to do this in code while I'm at it.
Any ideas to troubleshoot the macros not being available? Code to assign shortcuts?

Turns out this was a corrupted workbook. NO surprise there but the corruption was difficult to detect!
The workbook had a custom ribbon, with a code module to support it. The code module must have been inadvertently deleted. BUT the code still worked, am surmising that the ribbon must somehow embed the code in binary form.
Moved all sheets and code to a new workbook, recreated the missing module, and all's well with visible macros.
Still would love to know if there is a way to programatically assign a key code tho...

Related

How can a workbook reopen itself in a separate Excel instance

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.

How do I prevent certain macros being run in a Workbook?

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.

Excel 2016 Option Explicit fails to detect undeclared variables

All sheets and all modules have Option explicit at the top.
Require variable declaration is ticked
I have just two sections of code, each in its own module.
But Option Explicit is being ignored.
As a test, I put in a new line of code
sausage = 3
and it compiled without error.
I've checked all the possible code sections in the workbook with the code below. It fails compilation in all of them except one. The entire code in that module is:
Option Explicit
Sub SelectPath_Click()
s = 3
End Sub
Using Debug --> Compile VBA project produces no error, and the option to do it again is greyed out afterwards.
The code is as you can guess called when a button is clicked. I THINK the button is a Form control as opposed to an active-x, but I don't know how to query the button to find out what type it is.
There are no active add ins.
In the meantime, I have moved the sub from a Module to the sheet on which the button sits and hey, presto. Compilation fails.
So the question now is, how can this one part of the workbook ignore Option Explicit? Am I doing something wrong?
Try this. It sounds stupid, but it actually repaired that condition for me on multiple occasions from Excel 2003 through (even this morning) on 2016. If it fails, you'll have only spent 30 seconds trying this admittedly bizarre workaround.
Position your cursor after the "t" in Explicit
Type a space (there's a bizarre technical reason for this; just trust me)
Hit enter
Hit left arrow key
Hit delete key
Now the compiler should do what you expected.
This is in case you did everything right, and you KNOW that Option Explicit is simply not working as it should, which is to give a compile error for undeclared variables.
I found a solution by moving the code from a Module, to the worksheet on which the button calling it was located.
Every other code area correctly failed to compile with duff code (Even the other module with a function in it.)
I had to re-assign the code to the button, but now it all works as it should.
But I have no idea why it should have failed before.
Thanks for looking.

Can the code in an excel vba module become corrupted?

In Excel 2010. Can an ordinary module (not userform, class) become corrupted somehow? I can open my project, even run code, but for one particular module, can't edit, can't even delete it without Excel crashing. ?It's just code, isn't it?
Specific question: Is this a known problem with a known cause and/or solution? While I find plenty of info about corrupted worksheets etc. on the web, I don't find much about this situation. Is there somewhere I can look? Is there a remedy?
I'd recommend the VBA Code Cleaner from AppsPro. What the CodeCleaner does is export all the modules to a folder and then re-export. So actually, if for some reason you cannot install Code Cleaner (because of corporate policy or something) then you can do this manually by right clicking on the module and take the relevant menu item.
http://www.appspro.com/Utilities/CodeCleaner.htm

Excel 2007-VBA, Right Click Buttons

I am having a strange Excel 2007 issue, and I am not quite sure how to explain this. So bear with me please....
I have created a few right click buttons to call various backend VBA functions that I have written. They were working fine earlier today, and now for some reason, a button is appearing that is not from the code in my worksheet. When you click it, it is attempting to open another worksheet and execute code from it. The two files are not in the same directory nor are they named anything similar. I deleted the file that the button is trying to execute from and now it just simply gives me an error 400.
So, I couldn’t figure that out, and have since deleted every single scrap of code in the backend of this file, and the button still appears. Any ideas what could be causing this? It seems like maybe its mixing files up or saving a copy somewhere in a temp directory and trying to access that instead of the actual code that is written in the VBA. Is there a cache I need to clear out or something?
I know I didn’t exactly do a great job describing this, so I will be more than happy to provide any and all other details that you may need. Just let me know what is going on.
EDIT #1 -- New Information ==
I can even open a new, completely blank excel file and the right click button is still there.
EDIT #2 -- Tried Diagnostics ==
I just tried running the Excel diagnostics and it found no problems. It is strange, it is like this macro has somehow became global or stored in some type of cache or something.
I hope I'm understanding your issue correctly.
If you know what right-click (context) menus the button is appearing in you should be able to fix them with a Reset command. For example if it's appearing in the Cell context menu, you could try this in the VBE's Immediate window:
Application.Commandbars("Cell").Reset
This will reset the entire menu to its default state.
Also, you might be interested in a tool I wrote, MenuRighter, that allows you to tweak your right-click menus. It also has a setting to show you the Caption and ID of any context menu.

Resources