Feedback by UserVoice

Roy

My feedback

  1. 12 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  2. 1,056 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on 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

    An error occurred while saving the comment
    Roy commented  · 

    It's SHIFT for me. I verified it, and the behaviors I mentioned, before posting my first post of today. Always do before stating anything operational like this.

    (Not necessarily so for theory, unless the discussion has a direct practical aspect as well, which is one's opinion anyway, though most "stating theory" expect it to be received like God's Holy Writ, not as opinion.)

    Wonder if ALT works also.

    Ahh... perhaps you mean it WAS Alt in version 2013? Doesn't match my memory, but, you know, senility. Hmm... actually, it seems this (how to achieve it, not what it is after achieving it) might be much more a "version of Windows" thing not a "version of Excel" thing.

    An error occurred while saving the comment
    Roy commented  · 

    Lol, I do love that expression you used though:

    'with LATEST REV of Excel 2013' (my emphasis)

    Like those credit card ads from those long ago days, the ones that ended in "Priceless."

    An error occurred while saving the comment
    Roy commented  · 

    Well, I won't argue with the Excel 2013 thing except to say "YES IT DOES."

    I used that back in the day and long, long before. For the 29 years I've been using Excel, Shift-start ALWAYS has opened a completely separate running program that, as mentioned, among other things allows the normally forbidden "two files, one name" to be opened, maintained utterly separate Undo stacks, and made sure that if one file "failed open" requiring Excel to be shut down abnormally, only lost the work being done in that one's file or files while the other running copy was just fine.

    ALL three things that I've used and relied upon through all these years and all the versions along the way.

    But hey, I must be senile, so... whatever. Thing is, I don't remember being senile during those many, many years. Maybe that's the way senility works though?

    An error occurred while saving the comment
    Roy commented  · 

    @Ronald Hoek: Yes, it definitely is possible to do so. Simply press Shift while clicking the icon to start Excel. That will open as many absolutely separated instances of Excel as you care to click for.

    They will be as separate from each other as any two utterly different programs are. As separate as if you opened Excel, then opened GIMP.

    And their Undo stacks are UTTERLY separate as well. You can open same name files (from different directories, obviously), one in each, without being told you can't. Because they are utterly separate.

    However, in each of them (call then Excel-1 and Excel-2), if you open more than one document, those documents opened in Excel-1 will all be in separate "instances" of that running program (SDI now, no longer MDI) and related in many ways, such as copy and paste working naturally between them AND they have a common Undo stack (our problem here). But all of them are utterly and completely unrelated to anything happening in Excel-2: you can't do normal copy and paste between them, only the crippled version, and they do NOT share Undo stacks. Or anything else.

    Things can complicate this. For example, exactly how you do things if you use two or more virtual desktops (perhaps I should call having two desktops one "real" one and only one virtual one, but you get the idea). Yet when you see the gestalt involved there, each situation makes the same sense as simply the one "real" desktop scenario.

    Since a common Undo stack was something far more of interest to the ways people often did things (By no means "always"! Just "often.") in the MDI world of Excel, it seems like this should no longer be a "thing." Or if some/many actually still find it useful, it should be something one can turn on and off, an account option, or something one could set spreadsheet by spreadsheet (with the default being NO common Undo stack!).

    If YOU need utterly unconnected Undo stacks and the various other things are of lesser importance (I found the crippled copy and paste between spreadsheets to be... crippling... until they fixed that for all workbooks in the same running copy of Excel. Still crippled between running copies.), then just open however many utterly separate running copies as you need with Shift-start. There are other ways too, but that's simplest.

    (I use, above, the description of running copies and similar language to refer to the big picture, two or more utterly separate running copies: the originally opened one and all Shift-start ones. The ones I mention that are as separate as one of Excel and one of GIMP. I try to stick to the word "instances" or similar, for separate sheets opened in a single one of the running copies. Hopefully it is not too confusing 'cause I'm not sure there is much better language available.)

    An error occurred while saving the comment
    Roy commented  · 

    Holler.

    An error occurred while saving the comment
    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.

    An error occurred while saving the comment
    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.

    An error occurred while saving the comment
    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.)

    An error occurred while saving the comment
    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..."

    An error occurred while saving the comment
    Roy commented  · 

    Now you can be confused since I began and ended with opposites. Hint: I voted for this quite a while ago.

    An error occurred while saving the comment
    Roy commented  · 

    Against. Period.

    There's this thing called sarcasm. I may not have been deft with it, but even poor sarcasm is usually recognized as sarcasm. Perhaps a clearer version would "Hey, MS just solved the single Undo stack issue. They withdrew Excel from the market..."

    In any case, in general, I like to try to understand how a thing came to be and to give "props" when due. I think many do. But it doesn't in the least let me live happily with this sad situation.

    To be fair to my point, I was pointing out that the single-sheet version of affairs was similar to our world of single but multi-sheet spreadsheets. And that for the last 26 years there's literally no reason on Earth why the shared Undo stack would have been kept.

    It sets the sitch in stark terms. A lot of people don't even live 26 years. And this drags on. With no excuse or reason ever presented. Since I haven't sunk to the misery of not thinking on it anymore and just building hatred and resentment, I occasionally speculate. Not asking for forgiveness either. My life will go on with or without this. A part of it will suck, but that's all. And I'll still want individual Undo stacks the whole while. (Sorry, I couldn't fit "whale" into that.)

    An error occurred while saving the comment
    Roy commented  · 

    Rob... my man... MS DID solve this already, made sure each file has its own Undo stack!

    It's called (the horrible and monstrous forced shift to the world of) SDI. If you don't fight Excel, it will open a new instance for each spreadsheet and those instances are almost as unaware of each other as Spotify and Quicken are of each other.

    Including individual Undo stacks. Oh boy!

    Of course, fight progress and open your spreadsheets in ways that open in a single instance and those spreadsheets that are completely separated from each other via SDI (which operates regardless of single instance or multiple Excel instances) are suddenly still joined together via, amongst a few other things, their single, shared, Undo stack.

    But you really can have separate Undo stacks if you just open instances willy-nilly.

    And oh yes, it surely should be an easily set user preference. Right on the money there!

    But it is not by any means a "pro" feature. Even if you just need two spreadsheets open at once for manual work you intend to do in each as required by your job's minute-to-minute needs, you will sooner or later suffer with a single Undo stack. Or suffer from the disconnection between instances of Excel. And there are at least 10 other situations I expect arise very often amongst us all that are nothing pro-like, just average Joe-like.

    Admittedly, almost nothing is the end of the world here, usually one can give up his work by closing without saving if needs be. But it SUCKS to lose work for such a simple thing to fix. Sometimes it's a LOT of work, but even still, it's not like a tornado ripping up Xenia. It just sucks though each time you end up in that bind and it should never even be able to occur.

    By the way, I think you have the lead on an important "how it came to be": Until about 1993, there was a single sheet per spreadsheet. If one needed multi-sheet functionality, one had to make several, or many, spreadsheets that would work together. Still separate files though. A single instance of Excel-wide Undo stack makes pretty decent sense then, it would actually be enabling for many, though not required. Maybe how we ended up having it so long before it's last need for being went away.

    As soon as multi-sheet ("tabbed") spreadsheets could be created, most things settled into single spreadsheets and so a private Undo stack for each multi-sheet spreadsheet would have kept that equivalent functionality without hindering the future.

    Yet... here we are, relegated to the "hinderlands..." (sorry, couldn't resist)

    An error occurred while saving the comment
    Roy commented  · 

    No doubt.

    Right hand, left hand, neither knowing the other exists.

    I'm not sure if I should wish they shared best practices around the company (or had done so, long ago), or if I should be happy to see a monopolist miss a pretty good trick (the sharing of best practices).

    Seriously though, as I described in more detail lower down here, close an open workbook and they have no problem whatever identifying the Undo elements registered to that workbook and deleting them from the stack. It's not like you re-open it immediately and they're still available. So they can already identify what goes with what. How hard... oh... yeah, not hard. Must actually be a motivation issue.

    (Not really clear why macros have to wipe out the Undo stack either. Never seen a plausible explanation for that.)

    An error occurred while saving the comment
    Roy commented  · 

    Posting the 1st half now, so it is in order. Here. Sadly, that will make the halves come backwards in any emails...

    1st half:

    Have a SINGLE INSTANCE of Excel open and IN IT create 3 files, A1.xlsx, etc. Make some clear entries, patterned for each one, like 1,1,1 and 2,2,2 and 3,3,3.

    Try UNDO. That last 3 goes away, no matter which file you are in AND, unlike described following those links to different places after them, you go to that exact cell in that exact spreadsheet and see what went away. No "hidden" Undo's occur. Yay. BUT you were in A1.xlsx when you hit UNDO and wanted the last thing done there to be undone.

    Of course, that did NOT happen and CAN'T happen which is why this Suggestion exists.

    Those links are said to make the point that this is programmed in in such a way that it CANNOT be undone, reprogrammed, overridden... it is an aspect of MDI and flat cannot be done any other way. Those poor dears at MS have no physical way to override that behavior so this is an outcome. Choices? Well... no UNDO at all, of course, or SDI and then it never comes up to discuss so problem solved. Whew... no more dirty bathwater, problem solved... hey honey, where's the baby? He was here right before I threw out the dirty bathwater and now I can't find him... solved the dirty bathwater (UNDO) problem though.

    However.

    In the links, a person mentions that closing one of the contributing files wipes out its contributions to the Undo stack, but leaves the rest. Yeah, that happens, both with the 2016 I have now and the 2010 I have still at home. Another person says no... yeah it wipes out that file's contributions, but only by wiping out the entire stack, all gone, not just some. His point would seem to be the "nothing at all can be done with it in an MDI world." But he is wrong, and so is his point, and also that of anyone else saying so.

    You have the above work. Close any of the files, the one with the last changes (so hitting UNDO would have Undone something in IT), saving or not saving first. Try UNDO. It doesn't open that file up and Undo that last thing. Even if you saved it with the changes so that it had something to undo. That file and its contributions to the Undo stack are GONE. Open it, make changes, save and close it, try Undo (it acts on the other files since that one is gone). Well... open it back up. Now:

    1) When you closed it, the Undo stack KEPT its contributions until the Excel instance would be closed and now that you have opened it back up it will Undo things exactly as if you never closed it because it can't do anything else.

    or

    2) When you closed it, its contributions from the stack were removed. Gone. Never to return. Or at least marked to be permanently ignored. So opening it back up can't reactivate its contributions. They don't exist anymore.

    An error occurred while saving the comment
    Roy commented  · 

    Posting the 2nd half first so it appears after the 1st half, I hope. (It seems I write too many characters sometimes.)

    2nd half:

    If it is 1), nasty things will happen. Saved material will be subject to being undone. That might be the least of it. Making that impossible might have been the whole point of your saving, closing, and reopening. Nasty, nasty, nasty, on a whole new level from what we have now. But it doesn't happen, not at all. Those things are actually gone, so it is 2), above.

    Alrighty... if the actions are removable then they are ignorable. In other words, if in the MDI world, Excel can now ignore the fact of those actions being in the Undo stack and make no use of them, only acting on the items the never closed files contributed (easy to ignore something that doesn't exist any longer, right?), then it can certainly ignore them for other reasons.

    YES... for sure there might be reasons you would not want to and the program's guiding lights might have gone with the "hard choice" and made the Undo stack the monster it is today. Sure. Maybe. I know none of us would agree that that is so: about "reasons" and hard choices that is.

    However, no matter what they or anyone else says, that is all a lie. It is a lie because it has been said (mainly to avoid the work, I guess) for 25 years now, since computer generally had enough power and a worthwhile Windows version (3+) to do menaingful work on more than one file at a time.So while an off-the-cuff, first time I thought of it remark might be "wrong", going on with it, stubbornly, for 25 years makes it a lie about a month or so into the 25 years.

    If the stack can keep track of the spreadsheet the contribution came from (and it can or change cell A3 in A3.xlsx, switch to A1.xlsx and hit UNDO and you would see A3 Undo all right... A3 in spreadsheet A1.xlsx, not in A3.xlsx... it would act relatively because it did NOT know which spreadsheet put that act into the Undo stack... which is clearly and absolutely NOT the case!), then a trivial amount of code can look at a setting you have chosen and decide whether to ignore all contributions from the other spreadsheets and on UNDO in the one you have up (or not, if you set the setting the other way).

    Yes, that could seem to lead to issues, but not really since it would be Excel-wide, not spreadsheet by spreadsheet that one made that choice. The other aspect for trouble would be "tree-ing", akin to forward and back in web browsers, and having to deal with the situation in which you have ten things in the history, go back 3 to the 7th, then click something new and it becomes the new #8 while the old #8, #9, and #10 are permanently lost. Same idea.

    So NO, FLAT NO, this is NOT NOT NOT a physical impossibility. It just ISN'T. If I can see that, for G*d's sake so can 3,000,000 programmers. And their managers and strategic guiding hands. This CAN be done, and with the same trivial code college kids use to write browsers for a grade one week in some semester's class. It literally is not rocket science. It's TRIVIAL. Period.

    NOT doing it is a choice, not a physical law of the universe. A choice. A bad one.

    An error occurred while saving the comment
    Roy commented  · 

    Guys, I'm done arguing the point with the following last bit:

    No. And further, I have two instances showing up in Task Manager and Ending one's process leaves the other open and happy.

    That is from opening them by opening files from Explorer one at a time. One istance opens, then the second. And third. I did the screen capture after Ending it so it doesn't show there.

    Normal file opening techniques yet separate instances like when you forced them for years if you had to make Undo not a problem. NOT NOT NOT opening normally and creating separate windows but really being one instance.

    And no related Undo stacks.

    Well, I guess I don't see how to add a file to the comment, so no screenshot.

    An error occurred while saving the comment
    Roy commented  · 

    @Dave:

    Yes, exactly... IF you have a single instance of Excel open. For instance, I can open Excel, then open a second file in that instance with File|Open. Those two files will behave precisely as you relate.

    However, if I open an instance of Excel, and a file in it, then open a new instance of Excel (using Ctrl-Click for example, in the wonderful version I used to have that supported MDI), and open a file in it, the two files I have open are UTTERLY separate when it comes to the Undo function.

    This has been the case for a very long time, and for those of us who had to edit a couple spreadsheets at the same time (editing one, say, and the boss calls and wants you to edit a second one right then), we would open a second instance, on purpose, with Ctrl-Click. And the two would be safe from each other.

    The problem happens when Excel releases versions that do NOT support MDI, they are SDI only, out of the box. Then the Undo stacks are separate, by default. Hey! This problem is solved! No more whiners like me!

    People claim it was meant to solve some esoteric problem that I've never seen or heard of involving two or more monitors. Maybe. But I have plain vanilla equipment and never saw any problem yanking maximized Excel windows from monitor to monitor or even extending the workspace over both, so I don't buy it as a big enough problem to need solved over MY back.

    And htough I meant the below comment about them doing it to solve this problem as a bitter, bitter, joke, the longer I think about it, the more it seems like they meant it to "solve" this problem.

    Rememmber, if the second instance you open does not have a problem with your Personal spreadsheet already being open, then it is simply a new window for the first instance, not a separate instance like we see.(Or you don't have a Personal workbook. Lol. there's that possibility.) Open something, then open (Ctrl-Click) a second instance, see the warning about the Personal spreadsheet being in use already, then open a new something there. Then check the Undo function like I mentioned.(Maybe the mention is in the MDI suggestion.) You'll see what I mean.

    An error occurred while saving the comment
    Roy commented  · 

    "Anonymous" posted the Support link I could not remember:

    https://support.microsoft.com/en-au/help/3165211/how-to-force-excel-to-open-in-a-new-instance-by-default

    (posted it after my comment in the MDI suggestion:

    https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/11706627-restore-mdi-file-handling-open-all-files-in-one-w?tracking_code=854d5e956e3785f7b97ddcbdb33bd5c0

    )

    Adding my comment, because he was doing more than giving us the exact link:

    "Yep, that's the one.
    In the Support article it implies/makes clear that if the entry does NOT exist, you have MDI. MAYBE that is the case in a version that has MDI for a default. Hoever, my Excel 16 has SDI as a default and I was strictly limited to File|Open or everything created a new instance. After creating the entry and giving it the value of zero, rather than no entry at all, I got some capabilities back, for instance, being able to drag a file from Explorer onto the instance of Excel and it would open in that instance where before creating the entry, it would open its own instance.
    So take the "no entry at all is the same thing" that they either say or imply with several grains of salt."

    tl;dr? Make the entry even though it implues (or states) you don't need to. The instance above that I mention as probably when no entry is fine will NOT be the case for anyone suffering from the SDI issue so make the entry.

    An error occurred while saving the comment
    Roy commented  · 

    @Ed Hansberry:

    No. If I have two instances of Excel, they have completely separate Undo stacks.

    I just experimented in case I was wrong. Completely and absolutely separate. If I fill four cells in one and four cells in another, the hit Ctrl-Z eight times, the first four are still populated. Fill the second four back up and hit Ctrl-Z, the fourth one empties. Switch instances, and Ctrl-Z empties the fourth celll in the first instance. So, no. They are NOT interrelated.

    I meant it as a joke anyway, of the bitter variety. (Which is why I experimented before replying, in case my observational memory was not utterly correct.)

    As to SDI allowing the movement of files between monitors, well, maybe it does. HOWEVER, as I noted a few weeks ago, I could ALWAYS do precisely that between my two, completely cookie-cutter monitors and my one built on the Dell motherboard graphics card. Maybe people with better hardware have issues, but I never did and I absolutely will not buy that I have some "perfect storm" of hardware, coincidence, and providential choices with bizarre setup otions that every other person in the world missed.

    So... No to that as well. Whatever it DID alleviate, it was not an endemic problem with multiple monitors. To be honest, it was probably a stock watcher complaint. Gamers. People using systems meant to run on obscure combinations of settings because full-bore, cutting edge tech just isn't perfect. The rest of us, I'm betting, experienced what I always did and never bought the other anyway.

    And finally, SDI means one instance after another of Excel. Literally the same as opening Calc and Excel give you separate instances of programs for spreadsheets. MDI allows a hundred files to be opened in one instance using ANY method of opening Widnows itself supports, not just opening from that instance's File|Open method.

    With that registry fix I mentioned, I have some of that back. Just not all, and since one glaring one lacking is opening atachments from Outlook, it's still a huge problem for me, not just an occasional annoyance.

    But no, the first thing is completely wrong. And the second is not a matter of any concern for any average user. Nice they fixed it for a few unhappy people, but did they have to ***** 130,000,000 others to make 50,000 stockbrockers and day-traders happy? No.

    An error occurred while saving the comment
    Roy commented  · 

    Hey guys... they solved this already!

    This has to be what SDI is all about, right? If every file is opened in its own instance of Excel, then every file has its own Undo stack, right?

    For MDI rather than SDI, see:

    https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/11706627-restore-mdi-file-handling-open-all-files-in-one-w?tracking_code=ed54178708d5ae046e142c16184f5720

    but, hey, don't support it! It solves Undo completely! Yay...

    An error occurred while saving the comment
    Roy commented  · 

    'Tis empty.

    Office does not use the Clipboard the way Windows pushes it to others and never has. They did other unfortunate programming along the same veins. The "Undo stack" is one of them. They took the core of the program and made the shortcuts when they reset it as Excel and positioned it to work properly in Windows. They "rolled their own" instead of using their own Windows tech. So now... it'd too deep to rework easily. And I, for one, suspect they DON'T muc like things that don't lend themselves to "easily done."

    Accordingly, this kind of request simply involves too much effort on their part. If they could have rewritten their usage, they would have decades ago.

    Nothing has a higher level of votes. Or a higher level of frustration and pain. And yet, even though THIS suggestion has been here, buoying to the top endlessly, you'll note the Admin comment came 2½ years after it existed. And the comment is a pseudo-"we're looking into it, we really are" kind of comment meant to string us along rather than either promise solution to the problem or meaningful commentary on how they are noticing, after getting into the meat of what needs done to solve it, that there are several strains of interest and therefore several problems they need to work on.

    Instead, we see a mendacious comment about sub-issues meant to: a) Temporize, and lull us for some length of time, and b) To imply there really are sub-issues ifurther implying "boy, this will take some time here" and "it really isn't one thing, so all those votes are really not so impressive"...

    Thank you "John, Excel" for your shilling effort.

    But there is ONE single issue here, ONE single need, and there are absolutely NO sub-issues. There isn't even anyone with legacy work that would be destroyed, or someone who just doesn't want to change 30 years of keystroke habits. No one is arguing any point at all in these comments. No one thinks we are better off like we are. There are absolutely NO sub-issues to balkanize the support or to complicate solution efforts. This is NOT like the people yammering to return to every file opened is in a new instance of Excel and can only (poorly) use the Clipboard for interaction and after every one of those suggestions, a following one demands a return to every file opened is in one instance of Excel and nothing is shielded from the rest. There is ONE SINGLE DESIRE here: Undo stacks for each file, nothing to do with each other, and if you want changes reverted in more than one, you do that, yourself.

    And they don't even promise a solution, just that after getting a stunning number of votes and 2½ years of being noticed by them (yea, I know, good boy John is suggesting they just noticed there in March), they are going to use mendacity to ease us along for another year or two (it's been another ½ year already).

    This has ONE root: their own programming choices decades ago. For the love of God, they should just add code to work as desired and trap the calls to the sad legacy work sending them to the nice, modern code yielding the nice, modern (30 year old modern) need.

    Mendacity. It ain't just a funny word from "Cat On A Hot Tin Roof" Excel. It IS pathetic though. Sad.

    But yeah, Anonymous, it is an EMPTY response.

    An error occurred while saving the comment
    Roy commented  · 

    Oh, sorry, I was rolling way past my fingers in the lower 640K thing... I didn't mean to point it as if I meant no one thought computers would ever have more memory or that anyone could write a program that needed more. Because people said that was so much, professionals, not users, it was why would anyone spend the money (that sense of why would anyone ever buy more than that). Just buy 192K, say, and run the little programs of the day. You're unloading each one to run the next, so it's all there for it! Err... except for the footprint from DOS. But seriously, set the lowest 384K for the system instead of the highest... IF there is any... and now you're forcing people to buy 384K for that alone, then more and more to be able to run programs.

    So the guy with 192K for programs would have had to buy three times as much to have that. (It warn't cheap either.) NOT the best idea to underpin your marketing on. For all I know, IBM knew and approved. And people did write worthwhile things in space like that, though lots wanted to have infinite memory. Another for all I know is that MS nannied that by forcing them to limit size and therefore shiftless programming.

    But whatever the set of concerns, the 640K thing blew up on the DOS world but was NEVER EVER fixed. Because of ALL the compromises and ALL the "dishonest" programming (Did I do that? Address hardware directly? Yes, "Urkle, Excel", you did.): fix it and every program addressing that memory would fail. So it was never fixed, just bumbled along. Like this and a few other things.

    Anyway (rolling again), lots of folks would've bought a Mac if they could have gotten a second mortgage instead of a PC if they had to spring for a ton of memory or else. That was the meaning I meant to convey. And Lord, a Mac world is just all we need. (No need to even bother with the SARCASM() function for that last sentence!)

    An error occurred while saving the comment
    Roy commented  · 

    Lol, they hear us.

    This is one of those things whose underlying reasons were no one programmed "honestly" once upon a time, for Windows, not even the owner of Windows, and then there were choices one had to make that limited one's future options because something limiting was chosen and then inserted deep into the code.

    (For limiting, remember how the obvious choice of using lower memory for DOS programs (Because who would ever buy more than 640K, right? And by then, they'd be migrating upward and away from DOS and replacing every program anyway... yeah, remember the telephone company mode of progress? And cell service providers today?) led to years of limitations? And who ever chose those ridiculously small memory heaps for running Windows? "Resources" is a four-letter word to my gneration.)

    For an example of something with a wonderful utility (possibility) that wastes along, fairly (not completely) useless and never upgraded to its logical wonderful capability and launched across Windows:

    Word's "spike"

    Buried too deep to drop and too deep to make sing with greatness, it limps along and makes a few of us happy, but mostly makes anyone who thinks about it... just sad...

    Don't get the idea this last year or two is the only time period they've hear (or seen) complaints of the quantity and quality herein. It's been something to hate for decades now and surprise... it has been! Even the laziest users ever that still have enough gumption to say "Well, what if I change that value? What could go wrong? I'll just UNDO it in a second, oh, hello boss, yeah, let me bring that other spreadsheet up..." has regretted this and sworn at MS for it. And his little boss too.

    So thank you "John, Excel" (who has a middle initial of "," anyway???) (oh... need that SARCASM() function again, to wrap that kind of thing in, or a set of related functions... a lot of people would hate the "invalid argument" error message when trying to use (misuse) the IRONIC() function, eh?) but you folks ain't doin' nothin', not soon nor never. Except gladhanding us along. I'm less than 60 and I will die in my sleep before you do. So keep that gladhanding to yourselves please:

    HOPE springs eternal, they say, so even the above hurts. A "corporate lie" is still a lie "John, Excel." And the hurt is the same.

    An error occurred while saving the comment
    Roy commented  · 

    Indeed, about cross-workbook links. It is hard to see how, when the work is always one-way (note that linking back and forth is two one-way flows, not somehow a single flow).

    Link from A to B and the work is in A's undo stack. And vice-versa. Not complex at all, and I doubt complicated either.

    The truth is that this must be a function that is utterly buried in original programming and MS fears what they might break by attacking it. But that need not be a problem. One simply programs the good Undo stack approach using what I s'pose would be called a new stack, distinct from the old stack's place in memory, and adds a bit of code to make the old approach's stack simply a dead end - anything that reads it is directed to the new stack.

    "Simply" being... semi-loosely defined of course.

    But it would make the old code dead since it can't affect anything, and give us a properly functional, modern if you will, Undo stack. With code that can be accessed in the future.

    An error occurred while saving the comment
    Roy commented  · 

    Wow... all we have to do is keep voting! Over two years since ADMIN pumped us up with that "Under Review" and 509 votes and about 1 person in 10 even comments...

    ... and ... here we are still wishing without even a mendacious update from ADMIN to keep us pumped up...

    Seems to me I remember Pavlov's experiment had some data showing dogs, after conditioning, still having some degree of salivary response that was measurable as far as 10,000 trials without rewards. Something to consider?

    Since nothing else seems to be getting considered here.

    Roy supported this idea  · 
  3. 586 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  4. 32 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    Yes... is a cell address really "relative" if, when it is moved, it retains any part of its address?

    Sheet1!A1 is not actually relative if it will still say "Sheet1" when copied to another sheet. That actually doesn't happen to me, but clearly it does to you guys so good luck!

    (And I do mean just a simple copy and paste, no weird, unique, or special actions along the way). Now in the SAME sheet, well...)

    I AM voting for it though since I would like an easier way to copy something like the

  5. 44 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  6. 72 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  7. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    You DO know that at the moment, you can achieve this by pasting normally which carries everything, formulas included, then immediately Paste|Special|Values ("PSV") which will overwrite the formulas with their values?

    OR, you can PSV, then Paste|Special|Formatting so only the values are ever pasted, but then the formats are pasted over them. This one has the advantage that none of the formuals will fail and, catching your eye, send you off on trying to fix them when it is the source values that will overwrite things, not these values.

    Both methods will include all Conditional Formatting that applies to the source.

    Another option that does things directly, with a couple mouse clicks (i.e.: not just a helpful button on the right-click menu, but just one or two more clicks), is to click the Paste Special function button under those helpful popular buttons, and when the menu comes up, the first thing you see is a list under the word "Paste": (a bullet style list that you click to enable or disable options). Those options are:

    All (this is what regular pasting does, "ALL"
    Formulas (unwanted, eh?)
    Values — YES, click this one!
    Formats — YES, click this one!
    Comments and Notes — click if desired
    Validation — click if desired

    and to their right are more particular formatting choices if the general choice doesn't seem to give perfect results.

    I mention the above NOT to discourage you interest in your Suggestion (I would never generally do so since this site's stated purpose is to make Suggestions for precisely what you want!), but rather to give you a way to accomplish things fairly easily in the meantime.

    Though, since it is readily available, albeit with effort instead of just a final click, and possibly not a request with a huge base of support, I do think embracing the above, especially the third way, would be something to consider.

  8. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  9. 193 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    You can forget usability things like this. Anything they do to let you do with the Excel-you-already-subscribe-to rather than PowerApps which requires a new subscription for each app, each creator, and each user works to defeat that 10-100x cash (cow) flow.

    Nowhere is this more definite than in useful things to ease a user's experience and lower his barrier to acceptance of those apps vs. that horrible monster Excel. NOTHING that eases that barrier for Excel will be done in the next two-three decades. And this one is absolutely that. Date Picker is another that flat isn't happening.

    Sorry guys, I'd like this too. Especially if able to selet this formatting, then "inside it" select the character it uses. Or color. After all, it's a TRUE/FALSE thing so any either/or available to general formatting could conceivably be opted for here, and also, any several either/or's like not-checked is light red background, light blue dot fill, no check character and checked is yellow background, no fill, "X" check character.

    Ugh, and for God's sake, never try to make the built-in control work. It just doesn't and it's a beast anyway.

    Actually, since formatting is simply text stored in a regular way in the XML file/s, it is hard to imagine why no one finds any of this, and other similar complaints, compelling enough to write a standalone program, hooking in via Addin or what-have-you, or even opening any file Excel is told to, then passing it to Excel as if it were reading it off the disk, that does exactly that, store things Excel won't itself create.

    Unless... MS is right to not do it because it is some kind of beast of a job that no one outside Excel wants either... validation of their ignore-ance of these complaints would suck, I think. Hope that's not it.

    Roy supported this idea  · 
  10. 71 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  11. 216 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    The UDF in a Named Range thing, just create the thing, then when happy with it (all polished), copy the sheet to the new workbook template so the Named Range work is copied into it without error, then delete the sheet and everything new will include the function you created.

    And no macro status.

    They'll be even better once the LET() function is broadly available. Single name works, easier to maintain. Man... when I was a kid, those clicker toys only clicked, they didn't even usually add on an extra "toy" layer by painting them like ladybugs or whatever. Then in the '80's I saw some that did that, made them toy-ish even when not clicking them. Now LET() is coming! Life just gets better every day!

    An error occurred while saving the comment
    Roy commented  · 

    With text in column A and which element of it to return in G1:
     

    =IF(OR($G$1<1, $G$1>COUNT( UNIQUE(IFERROR(FIND(" ",$A6,SEQUENCE(1,LEN($A6))),LEN($A6)),1) )),
    "Error in which element to select.",

    MID($A6,

    1 + IF($G$1=1,0,
    INDEX( UNIQUE(IFERROR(FIND(" ",$A6,SEQUENCE(1,LEN($A6))),LEN($A6)),1), $G$1-1)),

    -1 + INDEX( UNIQUE(IFERROR(FIND(" ",$A6,SEQUENCE(1,LEN($A6))),LEN($A6)),1), $G$1) - IF($G$1=1,0, INDEX( UNIQUE(IFERROR(FIND(" ",$A6,SEQUENCE(1,LEN($A6))),LEN($A6)),1), $G$1-1))

    ))
     

    As I have it for actual use, I put a large part of the four basic elements into a Named Range so it looks cleaner, but I will probably put it all in (you can do what is effectively a UDF inside a Named Range so I can pass it the parameter of the cell (G1 used here) that tells it what element to obtain.

    It is hardcoded for a "space" as the delimiter, but that can easily be upgraded to allow one to be selected. It will return anything between the spaces which is good and bad, but that's the general effect everyone faces: how do you get it to return precisely what's there, but also, gosh, expect it to know you wanted "pig" not "pig,"? However, it is set to drop the absolute last character of a string, expecting a sentence and therefore ending punctuation (I set this one up to operate on text, so... not as generalized as it could be, yet), and not desiring the ending punctuation to be included. Easily modified if that IS desired, or it's used on text for which that condition isn't the case.

    An error occurred while saving the comment
    Roy commented  · 

    The following can find a desired instance number in a delimted data cell:

    =MID(SplitSource,SMALL(IFERROR(SEQUENCE(1,LEN(SplitSource))/IF(MID(SplitSource,SEQUENCE(1,LEN(SplitSource)),1)=SplitDelimiter,1,0),""),SplitDesiredElement-1)+1,SMALL(IFERROR(SEQUENCE(1,LEN(SplitSource))/IF(MID(SplitSource,SEQUENCE(1,LEN(SplitSource)),1)="$",1,0),""),SplitDesiredElement)-SMALL(IFERROR(SEQUENCE(1,LEN(SplitSource))/IF(MID(SplitSource,SEQUENCE(1,LEN(SplitSource)),1)=SplitDelimiter,1,0),""),SplitDesiredElement-1)-1)

    It just looks brutal. Lots of repetitive stuff.

    One could add error checking to make sure the SplitDesiredElement value does not exceed the count of elements.

    Since the elements are simple and repeated a time or two, it lends itself to simplification of appearance via Named Ranges yet would still be easy to maintain.

    I suppose ways around the problem have existed for years. I just don't know them.

    It has two basic components, to find the n-th (desired) delimeter, then subtract 1 for the one preceding it, then to return what's in between. Could be altered to allow more than one segment to be returned. 1st, last, any particular one, a count, all can be achieved via COUNT() acting upon the element inside IFERROR().

    It would fail if a delimiter were the first character, and if there is more than one contiguous delimiter (like in "abc $$ def$gh" if the "$" were the delimiter).

    The internal array produced is of the positions of the delimiter so it can feed directly into anything working off position. A multi-character delimiter is possible if one uses LEN(SplitDelimiter) for the early "+1" and very end's "-1" as well as the length of return for the first and last MID()'s but not the middle one.

    Anyway, possibilities seem to exist in it. Someone usefully simplifying it would be handy. Until MS programs in a proper function!

    Roy supported this idea  · 
  12. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    Works just fine for me.

  13. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    Yeah, they ain't changing that anytime soon.

    If it has to be a number, you're screwed. If it can be treated as text, format the cells for Text, then it will be happy to take it.

    But it still won't USE it as a number in some other cell's formula. Unlike many cases wherein you have something as text, but can have Excel add it somewhere else without work to change it from text to number first.

  14. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    The only place they are off by one day takes place 120 years ago. I cannot see how the attached file interacts with that. All uses in it, etiher absolute dates, or days between dates, would be far more recent than 120 years ago.

    If you use DATEDIF() in a couple of the ways it can be used, there are known difficulties. Not bugs as usually claimed, but difficulties due to how Excel help expresses the way the options should work, but actually, if one looks at them differently ("stupidly" being a synonym here, as would be "convoluted"), they become understandable and give the results you'd expect. No one has time for that though, so if you use that function, choose a new way and just avoid the whole rabbit hole involved.

  15. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    MS has avoided this for decades, with nods to the Excel 4 Macro system's EVALUATE() function. But we do need a way to build formulas dynamically without leaving the sheet (EVALUATE() only works inside the Named Range functionality unless you have enabled Excel 4 macros)... in which case you need to write an Excel 4 macro to use it so still not a natural sheetside function!)... some function to wrap the built string and make it become a formula, analogous to what INDIRECT() does for turning strings into cell references.

    Need one to turn a string into an actual, working array as well. That seems like another idea altogether at first glance, but really, what we need are ways to turn strings into several different Excel calculational items. Especially now that we can extract formula parts FROM formulas, not just put them in lookup tables (my dear wish in life to break the nested IF() situation) and user choice cells (as mentioned in your Suggestion).

    For decades, they didn't provide a direct, sheetside way to get a formula's text since the Excel 4 Macro language offered it. Maybe might not want to correct the deficiencies involved with EVALUATE() for another 35 years...

    But they DO seem to want to make Excel more like a programming language (notice SWITCH() a while back and how LET() is supposed to come, someday?). Being able to construct a string and then have it actionable in various ways, including this one, seems a natural for that seeming desire on their part. So maybe there's hope for it in what lifetime I have left.

    Roy supported this idea  · 
  16. 3 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    Afraid I don't get it.

    INDIRECT() already can do precisely what you ask for. The following is exactly what you give below as an example except it uses the work " INDIRECT " instead of " CHOOSECELL ":

    =SUM(A1,INDIRECT("B"&C1))

    So if A1=2, B3=8 and C1=3, INDIRECT() returns B3 and the summation is 2+8=10, just as desired.

    It takes, as you see above, cell addresses for forming the address it returns, just as you wish here. So it would seem to do everything CHOOSECELL() would.

  17. 17 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  18. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  19. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Roy supported this idea  · 
  20. 1 vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    An error occurred while saving the comment
    Roy commented  · 

    You are nasty and abusive. I shall not offer any "stupid" solution, just flag you as being inappropriate.

    Your precise statement has a simple answer which I am not in the least inclined to give. It is also readily available in "the community" so your lookup skills must be non-existent. And you don't have an Excel spreadsheet that is "infinitely" anything as Excel offers no infinite capabilities and certainly not an infinite number of cells. Just a wee bit over 17 billion at best, nowhere near the 10,000 billion you seem to suggest you have.

    So... whatever dude.

    Also, not that it matters to this question (in a feature suggestion forum of all places), but if you give an example of something, the "something" ought to be in the example...

    You must be a treasure at home.

Feedback and Knowledge Base