Make Undo stacks track per workbook instead of globally
Undo stacks are currently global between all workbooks that are open at a given time, so pressing undo on one workbook might undo a change in a different workbook. As someone who frequently has multiple workbooks open at a time, it would be much more helpful to be able to step through the edits made on each individual workbook.
Justin
shared this idea
Thanks again for all the passion on this issue – we hear you and we’ll get someone on the team to dig in to the issue. I’ve seen a few related sub-issues while scanning over the comment section for this one, so we may reach out to a few of you for clarifications. Thanks again for all the votes, and keep them coming for the issues you care about!
John, Excel
203 comments
-
Carlos Roriz
commented
Up
-
Roy
commented
Holler.
-
Rob
commented
@Evan: I'm with you 100%. My point was more that there has to be a reason MS did this in the first place, and the reason they haven't fixed it may be due to there being a lot of (lucrative) users who want it.
Now, that doesn't in any way excuse having not made it optional in the first place...
...or having not fixed it so it's optional after all these years of complaints...
...or having been so thick as to not realize it was going to be a problem for a TON of users.At this point, I'm thinking the code is a bloated, tangled mess (FFS, the app is 916MB when 10 years ago it was 58MB) and fixing this would be a bigger project than any of us imagine. Doesn't mean they shouldn't get on it.
Just saying there might be more to it than we know. Of course, the REASON we don't know is because when MS folks haven't stopped by in 2+ years, despite having raised our hopes.
-
aye, and it wouldn't even be that bad if the undo stacks stayed merged... provided it was improved maybe just a tiny little bit so as not to be such the total fiasco as it currently stands.
i mean, you have several speradsheets open simply updating stuff like normal humans do, but then when we find something we change our mind about, you want to simply go UNDO that. well, how to find it? MS WreckCell is no help at all here, its worse than finding a needle in a haystack since the only way to find the needle is to essentially BURN DOWN the whole friggin haystack.
The undo entries are so minimalistic as to be useless as mental indices (examples: 'paste', 'typing excelsucks in F454', 'bold', 'show/hide detail', 'zoom' ..yes those last two ones being so critically important to track those and fill up the undo buffer).
Now if MS could simply prepend the sheet/file name to these it would help us find exactly what the undo is referring to in order to decide if undoing something would destroy other work we have completed in the interim, but i guess that would perhaps just add more fuel to the fire that we actually need a NON-LINEAR merged undo palette to make a merged undo stack to be useable at all. So apparently they wont even bother to fix the easy stuff around this issue. -
Roy
commented
@Evan: with MDI, one could divide spreadsheets into pieces to allow only what a user needed to be under his influence. Doesn't need access to all the underlying data or the output the boss gets? No problem... he can't open those files and may not know they exist anyway. He DOES need access to some part of it? No problem. He can open that and 2-3-4 other files, then get to work. Because the work is all a part of one thing, a shared Undo made Undo work just like expected by a user. No undoing three things, then realizing he needed to undo something in spreadsheet 3 after the first thing, then go back to spreadsheet two and do the other two undos.
Well, people are doing that less, is my impression. Now they use shared files and step on each other with each user's filtering. Etc. Oh, and these users are NOT power users in any way. That's kind of the point.
Now when someone sets something like this up, four open files that one wants to look at all four of while working gives one a view of four Ribbons and no cells. It's a big complaint, along with other aspects having to do with running macros. Databases are cheaper, going in, nowadays, so one suspects spreadsheets are already less used as stores of sizeable data than once upon a time. Easier to draw the data out for use in a spreadsheet, but since the base of the set-ups I mentioned above was having the data IN Excel, one needn't have spreadsheet families so much and each user CAN have a single file to work with populated with sheets and macros for his work. Although, to judge by complaints on this site, neither shared worksheets, nor Ribbon covered monitors are pleasant to have anything to do with.
I personally don't use that approach and find a shared Undo to be a beast of a problem. I was pointing out that MS COULD defend its long ago choice by correctly claiming it saved a lot of *sses over the years. I am not a fan, I think anyone could agree, of much that I perceive MS being about. But to deal with a thing, one must not delude oneself. It was not utterly stupid in every case over the years. Always in my cases, a problem, not a good thing. But that experience was not everyone's over the years.
Certainly MS cannot defend not changing it now. Other Suggestions on the site usually have some dissent offered in the comments. I don't believe I have seen even one single comment here that wishes for Undo to stay like it is.
And certainly, none from me.
-
Evan La Marr
commented
@Rob - I don't know what kind of power users you're referencing, but global undo is pretty darn stupid for me, and I use Excel for work regularly. I'm not running VBAs or Macros all the time, but I'm definitely one of the best people in the office with it. I see no reason to have undo apply chronologically to all open sheets, when you can just do the work you need to do in one sheet. Yes, you can link sheets, but if you're data is so inextricably linked that you need undos to be chronological across more than one open workbook, you should probably just have your data in the same workbook.
-
Roy
commented
Those corporate users USED TO find it useful, in the days of MDI. Then you could divide up functionality between several spreadsheets, to better suit your use needs, and people would open them as a set which then could very much benefit from a global Undo as their workspace (remember real Workspaces... took that away too) of several related spreadsheets could then have Undo's performed in a meaningful way.
Now it's much harder to do those things (since SDI) without unweildy implementation of the Ribbon, just for example, leaving you what amounts to a command line of space to work in each sometimes. And when macros bridge everything together, disturbing (to users) stuttering and flashing screen changes, and so on. A number of those things are talked about below, and more elsewhere. And the protection is no longer the same, in practice, and not in a good way.
So... I gotta doubt the corporate users are still perfectly happy.
And all the Jim Bob's in the world who also chip in monthly for Excel, "...and the rest...," definitely feel like they're "...here on Gilligan's isle..."
Worse, I personally believe they actually are planning these things in order to drive users in that very corporate world to PowerApps, and related PowerCr*p programs, for which any user wouild then pay an easy five times as much for, monthly... and STILL have Office and so STILL be paying for Excel. I mean, that's easy math, even for MS.
The health industry in the US is one-sixth of the economy and that is mostly due to the economic distortions that ALWAYS stem from the consumer of a thing not being the PAYER of a thing. That describes corporate just about to a "T" adding further encouragement to any effort to shift corporate users to more lucrative "solutions." Not being the payers makes that barrier to acceptance of the move that much easier.
-
Rob
commented
I hate this functionality too, and Microsoft NEEDs to make it possible to turn it off, so people who work with one workbook at time don't have to deal with potentially dangerous Undos.
But keep in mind, everyone who thinks global undo is "silly" and asks if the developers have ever used their own product, that Excel's bread-and-butter is corporate power-users for whom this behavior is beneficial.
Microsoft didn't pull this functionality out of their backsides. There's a reason for it. A good reason, in fact. Where they screwed the pooch was in making it the default with no option to turn it off, thereby demonstrating no consideration for their *common folk* users.
-
Ben
commented
This issue was created almost 5 years ago. They aren't fixing anything don't even know why I'm still subbed to this thread. Office 365 is the worst thing to ever happen to Office.
You know I remember right before 9/11 Microsoft was under fire for monopolizing the office suite. Conveniently everyone forgot about that. Shame nobody else can even remotely compete with Microsoft. No competition, no incentive to innovate and evolve.
They've got such a stranglehold as the market leader they've completely lost the need to improve anything about their products. Office is d*mn near required in every business with an office setting, so now with Office 365 subscription services they are raking in the profits more than ever before.
Microsoft gets worse every year.
-
Roy
commented
One could even have argued it was actually necessary the way people set up multiple, linked spreadsheets in the days of MDI. But MDI is gone and isn't coming back. So that's not any kind of reason to keep it, rather, it's a follow-up requirement for fixing after having made that choice.
I get the VBA-wipes-out-the-stack thing too. How could they possibly predict how a macro is going to do things and therefore what events not already tracked by Undo would now have to be, nor can one expect a 100 event Undo stack to be meaningful after a macro runs that worked on 20,000 rows making 23 tracked changes per row... 460,000 events pouring into and off it leaving only the last 100 makes the Undo stack simply irrelevant at that moment and so clearling it doesn't seem such a bad decision. Except...
Why not let the writer decide? An option a macro could specify saves the Undo stack before beginning its work, then restores it afterwards. Writer got it wrong? Tough luck, write your macro better. I can live in a world where you have to make good choices.
But the move to SDI had to be aimed at destroying the linked worksheets being essentially an app ecosystem, so finish the job and unlink the Undo functions for open spreadsheets. There's no need for it now that splitting into several worksheets that run together is now fraught with difficulty and practical issues and for my money it's always been undesirable anyway, so finish the job!
Remember, as I've mentioned before, Excel has NO difficulty dealing with it as each piece being owned by a particular spreadsheet* so the underlying work, that of knowing what goes with what, is already done. Just have to stop aggregating them.
* Two veins of reasoning: 1) Well, it must because if it only kept track of "A1 got overwritten from '=A4' to '=SUM(A2:A4)', how would it know to shift from the active spreadsheet to a different open one to restore that where it happened rather than restoring it... but in the active spreadsheet, not the one it actually happened in, and 2) Open three spreadsheets. Make changes in all three. Undo them and watch them happen as they ought. Do it again, but close one of them first. Undo will undo the changes to the two still open, but not the one closed. Further, before trying Undo, re-open the one you closed. Do Undo and it still won't affect that one: Excel knew what to remove and has the ability to selectively do so.
(So all the tools for this are there, currently provisioned, just not used in the desirable way we all wish for.)
-
S. Stockton
commented
@{this is a shame} Similarly, why on earth must Excel continually clear the clipboard? For instance, why does "Esc" key mean not only "remove the dashed boarder around what I copied" but also "clear clipboard? An application shouldn't touch the clipboard unless instructed it to put something else on it. Dainbramage! Say I goto another program and copy something; frequently Excel decides it knows better, and thinks that in fact I didn't really want anything on the clipboard. As an unreliable workaround, I've taken to using a "clipboard manager" tool keep the last several clipboard items; every once in a while, it can't paste quite the same content as if the clipboard hadn't been cleared, but at least there's /some/ way to smack Excel around and say "No, I really did need the contents of the clipboard.". Windows 10 has a built-in clipboard manager, but I can't rely on it always being available (usually due to Group Policy).
The lack of separate Undo stacks for each Excel document also is …unfortunate… because running ALMOST any VBA will destroy the entire Undo history for the whole application.
I'd like an optional Undo Actions palette, like PhotoShop — preferably with mini preview of the affected area — where I can click any point in the list to jump backward or forward in history without having to step through each intermediate stage.
-
this is a shame
commented
First, I can't believe that someone in your design/product teams has accepted and approved this silly undo behaviour. And no one said it's moronic.
We want to edit the documents individually. Have the guys who "invented" this nightmare ever worked with documents?
What if Visual Studio had a global undo stack? How would you develop? I'm sure you would use notepad after a day or so. -
Gau
commented
When is this going to happen, if ever???
Free competitors do not have that issue, and this fix has been requested by customers for over 2 decades. Please move to 21st century!!!
At this point I do suspect that you've lost the source code... Otherwise why would you waste money changing icons and colors when such a functional issue does not move forward! -
Roy
commented
The money whispering in MS's ear at the moment is saying "Look how much of me you'd have to spend to fix this... $5 is $5 man... don't lose focus and cause an earnings drop... $5 man, $5... keep perspective here..."
-
Randall
commented
Has anyone discovered why Microsoft makes more money with it this way than the other way?
I mean, money talks, right? -
Anonymous
commented
Same problem in 2019, so hardly making it to the top of the revision list.
Still a real pain, though.
-
Anonymous
commented
Yes, I am having the same problem at work. WHEN WILL THEY FIX IT? Extremely annoying as I have 4 or 5 open to research, and copying and pasting across a couple of them - so it is really frustrating when I want to undo one or more items in one spreadsheet (as trial and error is needed in what I am doing) and it undoes things in the order they were done, across all open Excel sheets - when maybe I want the other spreadsheets to remain as they were!
-
SC
commented
If you're not planning to do this, a much quicker solution would be to bring back the "open each workbook in a new instance of Excel" option, which is something I always had turned on until you removed it a few months ago.
-
Vincent Empain
commented
It could even be more than this: the possibility to undo "previous" actions without having to undo all those that followed it, which prevents redoing those following ones after that change. If after many changes in one workbook you realise that you would like to undo one specific action, the only choice is to do that manually, or to undo the whole set.
-
Rob
commented
@Anonymous on 2020-02-21: Hit the nail on the head. I *do* understand why MS wanted to make undo stacks global. I understand why power-users might need that. But there's just NO excuse for not making it optional. 1) They *must* have known that the vast majority of Excel users will never need this feature, and 2) as you've so perfectly pointed out, they didn't think through the work flow and how this rotten execution bleeds over into other functionality. It's terribly botched in execution. But I suppose that shouldn't come as any surprise for software as bloated with code as Excel. There may truly be no equal for spreadsheet apps, but 1.64GB for a single app just screams "Our app is full of dead-wood code leftover from 15 years ago."
For my use case, which is fairly sophisticated, Excel 2008 still does 95% of everything I need, and it's only 58MB (97% smaller than Excel 2016), and has 90% fewer bugs. Of course, the devil is in the details, and that last 5% of improved functionality is stuff I *really* need, so I'm stuck using this bloated, bug-riddled version of Excel that doesn't think like its users think.
