Besides Office, Excel files can be created using numerous software tools. More often than not, batches of macro-enabled Excel files are processed with scripts for productivity purposes. However, VBA code signing cannot be part of an automated process, as it is a manual task that requires opening & saving the file in Excel.

This request is about creating a command line tool for signing Office files with a digital certificate, similar to MS SignTool.

In addition, the existing macro signing process in Office is not 100% compatible with Open XML specifications. I can clarify this statement in a private discussion with MS engineers due to its security implications

Use case: in my world, we have templates that are frequently updated. As a result, the VBA has to be updated and tested as well. I'm not an expert programmer, so there are often many iterations of code tweaks, test, repeat.

The problem is that the template is affected by the code- rows and columns are added/deleted based on the sample data, etc.

So I either have to close without saving, and keep a handwritten log of the next few lines of code I've identified as requiring edits, or, I save the file but then have to go copy/paste the clean format from an older workbook (multiple sheets).

It would be soooo much easier if I could save the VBA code only, then close the template "without saving". Then I would have the updated code that I could immediately run against the original/clean template worksheets

If there is already a way to do this, I am unfamiliar and would greatly appreciate someone telling me how. I'll also go post this in an Excel forum to see if any MVPs have a better approach

After moving from Office 2010 to 2016 (on-prem), our users began to experience severe problems with macro-enabled workbooks (XLSM). These workbooks would not open, or open with errors, or the macros would crash Excel when run, or opening the workbook would crash Excel, or the Visual Basic Editor in Excel would exhibit weird behavior.

In all cases, the problem could be solved by opening the XLSM without active content enabled, and recompiling the VBA project. But in all cases, these were VBA projects that had worked normally before, and had been succesfully compiled before.

Recently, we rolled out an update to Office 2016, and the same problem popped up. The same XLSM workbooks would cause the same range of problems, and the solution was again to recompile the VBA projects.

This suggests that the cause of the problems lies with Office 2016 updates. So my suggestion is: ensure that updates do not corrupt VBA modules in XLSM workbooks.

(I logged a support ticket for this, but oddly enough, support recommended I log a suggestion on UserVoce instead.)

I'm currently debugging some code, and have several arrays where being able to see the full array of values at specific points in runtime would be immensely helpful in my troubleshooting.

I'd like to suggest that rather than having the user write code loops or lines to print out an array in a table format
for I = 1 to 10
debug.print (array1(i,1) & " " & array1(i,2) & " " & array1(i,3))
next I

it would be awesome if the VBE had a built-in function that would debug.print an entire 1D or 2D array, AND with an optional parameter to print out up to 2 dimensions of a larger array.

That would save a lot of time just for bug-fixing, and would be a nice addition overall. The command would probably have to include an optional parameter for a delimiter (comma, semicolon, spaces), and probably a boolean optional parameter that defaults to fixed width

This idea could be extended a little further and allow the user to export their 1D, 2D, or selected dimensions to a worksheet, for example:
=DumpArray(MyArray,Sheet1!A1, ...

where the different elements would naturally be broken out across rows and columns (no delimiter needed). It would be nice if users could transpose when pasting to a worksheet, if needed (maybe to the debu.print as well, but personally I haven't needed that)

This would be helpful in general, but for troubleshooting I could see sending an array to A1 early in the code, then (depending on the size of the code) to H1, then to P1, so I could easily review the worksheet and see what changes happened to the array across different code blocks

If a macro is marked as a UDF, it would be available even if macros have been disabled if a user so selected either as a general option or when opening a spreadsheet.

Any so marked macro (UDF) would be limited to no work outside itself except to provide its result to the cell it is used in and could only use inputs specified in its use. No other externalality could be done: no accessing non-specified cells/range/etc. for any reason, no actions like changing window size or deleting files or whatever. It could only use its defined-in-the-cell inputs and only give a single output into the cell containing it.

Excel could easily check either as one writes the UDF macro, or after, or even when loading the spreadsheet each time, that the macro meets conditions to be a UDF and be available for use.

UDF's can do soooo many nice things nicely. This would greatly expand their use situations.