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.

I have a number of very large number crunching models that are run by macros and often take several hours to complete with my core 5 computer. I set these up to run over night or during the day when I am out or working on other things. When Windows decides that it is time to do an update it simply closes Excel even though it is very busy crunching numbers. Today I lost three hours of work because it does not even bother to save the file since it only does that when the program is sitting there not doing anything. I could have the program stop what it is doing and save itself periodically but that would only add time to the processing and there are not that many meaningful places to stop and save.

Could Excel simply prevent the system from closing down if it is busy doing calculations?

When macros are signed with a certificate, the user is given the option to "Trust all documents from this publisher". However, this option is not available when the signed macro is attached to a Shape.

This behaviour should be consistent no matter where the macro was attached.

See attached "failbook.xlsm" and "successbook.xlsm". Failbook has a macro attached to a shape, successbook has a macro attached to a form button. The images "macrooptionssuccessbook.png" and "macrooptionsfailbook.png" show the differences in the macro options screen between the two excel workbooks.

Reproduction steps:

1.-In the Excel Trust Center, enable "Disable all macros with notification"

2.-Open Failbook.xlsm. You would see a message at the top complaining that "Macros have been disabled". This is expected.

3.-Click on "File" tab. It will take you to Excel's backstage and you would see the message "Security Warning" in a yellow box.
4.-Inside this box you would find a button named "Enable content". Click on this button and choose the "Advanced options" option from the dropdown menu.

5.-The "Windows Office security Options" window will appear but you cannot see the signature information on it. Means you cannot choose the option "Trust all documents from this publisher".

6.-Open "SuccessBook.xlsm" and repeat the same steps. You would see the above mentioned option. Means the users can click on "Windows Office security Options" and check the certificate information on the same window.

Expected outcome:

Both excel spreadsheets should give you the same options, as the only difference between them is that one has the macro on a form button, the other has it on the shape.

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.

Due to a number of factors (I started having this problem mostly after our company implemented OneDrive, but I'm sure there are complementary factors like intermittent network connection, etc) I keep having Excel restart or reconnect in ways that it has to recover files including personal.xlsb.

For most "front-end" files, I can just open the most recent one from the recovery panel, and move on. However, when Excel re-opens it does so with personal.xlsb loaded, and I haven't managed to figure out how to tell Excel "only use the most recent [recovered] copy". So these backup copies get stored/saved, and I can't tell which ones have code changes and where

This may be user error, maybe there is something simple I'm missing to ensure that the backup copy automatically replaces the version already re-loaded with Excel...

but in case there isn't a good way, or others have the same issue- it would be great if there was an easy way to compare two vbaproject.bin files and get a report saying what is different. Maybe a listing of every module, within that every Sub, and the number of lines in each sub- that way it would at least be easy to narrow down where there are differences. A more sophisticated solution might compare each sub, and if there are differences (even within the same number of lines of code) would detect and report that as well ("Sub ABC differs starting on line 12")

I guess the best win would be to identify why Excel is suddenly creating so many backup copies (I currently have 5) and prevent that in the first place, but I don't have enough information to provide a root cause analysis with this suggestion

Ok, I know this is a minor nit, and probably NOT appropriate for the visible sheetnames (because it would throw half the user base into a panic)... but I often find myself renaming the sheet codenames (and controls) using 01, 02, 03 because of the way the VBE sorts things. Obviously this only helps for workbooks less than 100 sheets, but that is probably 99% of the use cases, whereas the current approach only works up to 9 sheets, which is probably only half the time.

Sure, I sometimes rename sheets with more intuitive text names as well, but this is just for straight-up, out-of-the-box organization.