When I protect a worksheet, some cells I don't want the user to be able to select at all, or edit in any way. And some cells I want to lock against the user editing, but still need him/her to be able to select those cells, whether it be for highlighting, copying, etc. Additionally, some cells I want the user to select and enter data, but not be able to edit the formatting of the cell. This is currently easy to attain. However, many of my cells have hidden formulas which I don't want the user to edit but I do want the user to be able to drag those cells down to apply the formula(s) to cells in subsequent rows. But currently, if the formulas in cells are hidden from the user being able to edit them, those formulas also cannot be applied to cells in subsequent rows when the user drags them. Likewise, in some of my financial spreadsheets, I have certain columns of cells with auto-calculations/formulas locked against user edit. When I need to select an entire row to drag and apply the formatting and formulas for each of its cells to the next row, I can't do it because Excel throws an error when attempting to drag a row containing one or more locked cells.

Excel needs 2 or 3 levels of protecting each cell in a worksheet where you can:
a. specify particular cells are locked against any form of user selecting or editing (complete lock down of those cells).
b. specify other particular cells in the same worksheet are locked against user edit, but can still be selected in order to copy their values, and their format/formula can also be dragged and applied to other cells.
c. specify particular cells are unlocked for editing while their formulas ARE locked against editing, but those formulas can still be passed and applied to other cells when dragged.
d. specify particular cells in the same worksheet are unlocked for editing while their formulas are locked against editing and those formulas cannot be passed or applied to other cells when dragged.

Excel has the potential to become one of the greatest, most versatile and useful apps on the planet - if Microsoft would just put in functionality its users actually need instead of continually adding bloat with useless features.

Can we please get 8 new EXTREMELY USEFUL events for Excel worksheets: SheetDelete(), BeforeRename(), Rename(), BeforeHide(), Hide(), BeforeUnhide(), Unhidden(), and BeforeNewSheet(). Excel already has NewSheet() and SheetBeforeDelete() events.

It makes sense that the BeforeNewSheet(), NewSheet(), SheetBeforeDelete(), and the SheetDelete() events must be in the workbook code object module, and that they should posses the "Sh As Object" argument in order to determine which sheet the user is attempting to act on. But the rest should be available in each worksheet's code object module.

All of he "Before...()" events, including the existing ones, would additionally need a "Cancel As Boolean" argument/parameter, as well, to allow for cancelling the operation. Because data formatting and VBA code MUST (I can't stress the MUST part enough) often be tied to worksheets and/or their names, we need the ability to determine when the user hides, unhides, renames, adds, or deletes a specific worksheet so that we can cancel the operation, or trigger another follow-up operation once the user-initiated operation (rename, delete, add, etc.) completes.

Yes, I know people suggest to reference a worksheet in code by its index number rather than by its current name. But for those people I can give you 20 examples where using that method also causes unpleasant program conflict and issues. Also, see above where I stress that often code MUST be tied to a worksheet name. And, also quite often, certain calculations or the data being displayed is dependent upon the current name given to a worksheet by a user. Very often also, the worksheet name must comply with company standards, such as is the case at our company. Additionally, we need the ability (better than what currently exists) to cancel the user adding new worksheets and deleting, hiding, or unhiding existing worksheets, because so very often the data in one worksheet is connected to another. Using the 'Protect Workbook' feature is rarely useful because when enacted, also prevents using other features which are useful.

REQUEST

Allow users to place tabs up top, just below the Ribbon. They are getting buried to the lower depth of increasing resolution and screen sizes.

SITUATION

Days gone by, monitor and resolution sizes were smaller and tabs held a relatively larger chuck of desktop real estate within a reasonable peripheral view. This is no longer the case. Monitor and resolution sizes have and will continue grow.

PROBLEM

As the virtual desktop grows in space, the relative size and lower level placement of tabs impedes their recognition and use. I find myself falling into the bad habit of not making an effort to check for additional tabs. Why should I? Isn't everything that matters up top?

REQUEST

Allow users to place tabs up top, just below the Ribbon. They are getting buried to the lower depth of increasing resolution and screen sizes.

Thanks,

Shawn