Feedback by UserVoice

Roy

My feedback

  1. 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  · 

    I agree as to the "changing data is never OK" point. Not fond of the auto-formatting though. Maybe in 1912 when they were new and thought people would use the program for quick, two minute, off-the-cuff calcs, when five columns by 20 rows was all you got, well, maybe THEN not having to format something in your quick, off-the-cuff and then forget it forever approach, not having to format a date, say, might've made the user less aggravated. ("Ugh! I just want the answer! I don't want to format something! It's a calculator for gosh sakes!" The current generation has and has had NO monopoly on people for whom "you" is too much effort and "u" is barely sufferable.)

    But in any other use? Freaking no. If I have something that trivial, I use a calculator. Anything I put into a spreadsheet is worthy of 20 seconds of my time to format the output's date (and five seconds more to copy the format to the input date if I want).

    But in no circumstance on God's green earth is losing material from actual data EVER acceptable.

    Roy supported this idea  · 
  2. 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  · 

    There are TWO concerns, and therefore TWO places, of interest for this problem and considering both solves most instances.

    Seldom thought of is that Excel must realize an entry is a date before it will ever automatically format an entry as a date. Similarly, it has to do so in order to decide WHAT date it is before it can apply your own chosen formatting to it. If it doesn't realize a thing is a date, it looks like a string or a strange arithmetic operation.

    It does this by taking the entry, realizing it might be a date, then comparing it to Windows's setting for how a date should look. NOT to Excel's setting... to WINDOWS's setting. Before all else, it must pass this test or it stops thinking it might be a date and moves on in how it wants to treat the entry.

    So your computer's settings must include, or be, depending upon the settings you have available to you (Windows version, corporate IT policies, various things affect this), compatible with the way you wish to physically type the entry. If you want to type DD then MM then YY, you have to set Windows for that default style. If you do, Excel will be told yes, it could be a date.

    Then Excel looks to format it using any set formatting you did first, and choosing its own if you haven't set that cell to a date format. This is the place most people make fruitless changes... they WOULD work, if only Windows had told Excel it could be a date... but Windows did not, so no change could work as one wants and one thinks Excel is the failure point.

    To check your settings, you can follow the new, from the Start Menu, Settings pathway (the icon that looks like a gear, or whatever), but often that does not give full access to all the things that ca be changd. So if that is fruitless, try using the old Control Panel (click the Start button and instead of selecting that "I look like a hip-hip phone even though this is a boring old computer" icon, type "Control Panel" and press Enter. Choose Region and go from there to set your computer date format default to "DD/MM/YY".

    THEN Excel should do nicely. As nicely as it ever does.

    By the way, Excel itself gives a hint as to the default from Windows: in the built in date formats, one or more may start with an asterisk: *3/14/25 might be an example, and it would mean the Windwos default for the "short" or "long" date is "m/d/yy". But that's a little non-detailed sometimes, since it is a computer program trying to give you a quick and dirty idea of something that really does have more nuance than that. But it's a hint, for what it may be worth.

  3. 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  · 

    While waiting, you can use the following Custom Format to achieve the "August 2022" display:

    mmmm yyyy

    Don't think they'll change things so that entry would mean month-year rather than month-date since almost everyone would always want month-date. But you never know, they might build in a format for you.

    Also, the converting a two digit year into a four digit year thing... you can adjust the window it uses so that 2030 is no longer the cutoff for you to get the four digit date you mean. You do it in Regional Settings in Windows itself, not in Excel:

    https://support.microsoft.com/en-us/office/change-the-date-system-format-or-two-digit-year-interpretation-aaa2159b-4ae8-4651-8bce-d4707bc9fb9f

    Then do this: (a short scroll downward)

    Windows 10

    In the search box on the taskbar, type control panel, and then select Control Panel.

    Under Clock, Language and Region, click Change date, time, or number formats

    Click Regional and Language Options.

    In the Region dialog box, click Additional settings.

    Click the Date tab.

    In the When a two-digit year is entered, interpret it as a year between box, change the upper limit for the century.

    As you change the upper-limit year, the lower-limit year automatically changes.

    Click OK.

    VERY VERY important: Do what they say to get the old Control Panel!!! I cannot find this setting under the new "Settings" pathway.

    My window is set for 1970 thru 2069. I'll be dead before then so that's a good range for me.

  4. 223 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  · 

    Eh... (sigh...) actually, I guess that test would be pointless since if it is something like Live Preview looking in for a moment, that moment would be over by the time I'd do my little experiment so it's probably pointless. Maybe if I'd open something, get ready for Ctrl-V, Right-click to maybe see a context menu if the test bed offers such and hover over Paste, then hit Ctrl-V and see (if the menu doesn't interfere with that) if it pastes properly. Seconds vs. nanoseconds... probably not a worthwhile experiment. Oh well.

    An error occurred while saving the comment
    Roy commented  · 

    I'm gonna have to remember, next time I get this message, to immediately fire up something like NotePad and try the Paste there, before even acknowledging the message.

    Why? Well, Office doesn't precisely (as in doesn't really) rely upon the Clipboard, rather it uses its own effort. More than one if you consider "the Spike" in Word. After all, why would MS's headliner software use MS's operating system's clipboard service instead of its own? This, by the way, is the "why" for all the oddities people complain about, vis-a-vis cut/copy/paste in Excel. Oddities, not failures. It's because Office ISN'T using the Windows Clipboard so it doing these things gives rise to people noting differences in behavior and characteristics between Office and the rest of the world.

    But something and another does make me wonder if pasting in a different program, which ought to work once I copy something to "the Clipboard", ought to anywhere, would fail while this error is in place. Basically, if the precise wording of the message actually means that things will still be fine in Excel, go ahead and do your work without worry, that what has gone wrong only affects other things... like everything else that is. Or if it's just me finely splitting meanings and realizing 2+3 might equal 34,587.22.

    Something Dan (May 2?) said makes me wonder it in particular. Live Preview would certainly be reading the Clipboard now and then so as to be able to do so when needed, or to do so on current command, right now, "do so" as in provide a real, live preview. If Excel/Office were making a read right about then of the Clipboard, maybe that would be a common "snooper" interferer like MS sugegsts. Their own snooper, mind you, not some stupid not-MS crud you bought instead of buying only software gold from the only supplier of software gold in the universe, but a snooper nonetheless. It would presumably only affect things intermittantly, so even a lot of paying attention might never show an effect from its good work, thereby giving the impression it is not at fault, but who hasn't at some time either clicked somewhere and ordered Excel to paste, then swung the mouse out of the way to see what's going on, and maybe run it over an icon that triggered Live Preview that moment? Or some other trigger.

    I like Live Preview so I won't be disabling it, but I do wonder.

    Half the point of that would be how you'd almost never likely do that, so it would be the infrequent, always perplexing, thing I myself observe. (I don't see it as much as UweC does, clearly!) So it wouldn't crop up too, too much, just enough to be annoyed and irked at its absolute pointlessness.

    Which wouldn't be pointless at all, actually, if it really does mean "We do pasting differently in Excel so it's all good but that crud software from not-MS that you might also be running won't paste this stuff so be warned" then MS would actually be (in a pointless, almost impossible to understand and so use in any meaningful way) performing a "service" for you, letting you know. Lol, that's MS in a nutshell. Give you a long explanation of something but from a stance understood and realized by three people in the world and the knowing of how they viewed things is the only way one has any chance of understanding what they could possibly mean. Can you say "half their online help"? Anything opaque always makes sense once you realize just what bizarre, obtuse a starting point they took. O course, it might take 27 years of using the product and not using the item in question, but once the stupidest thing you eventually ever imagine occurs to you, it's amazingly clear. Maybe this is one of those.

    Roy supported this idea  · 
  5. 2 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  · 

    @Anonymous:

    Every column of your spreadsheet has the data you see on the screen PLUS one extra character (the " " character). So your numbers are considered text by Excel, not numbers, and they have the value of 0. Therefore, summing a column, like column J, sums 500 zeros and gives the result of 0.

    That character is NOT a "space" but rather some blank character that looks like a space. In this case, it is Unicode character 160 which is a character websites especially like to use in the data they present on-screen, though usually not in data they allow downloads of. There are quite a few other characters of the same kind that websites, and others (like documents one might receive) use to:

    1) Help them form the display of their data, and
    2) Give you the hardest time they can if you "scrape" the data from their web pages for use in your own program, thereby encouraging you to NOT do this.

    The way you can tell is not just the fact that, if you have not changed Excel's horizontal formatting from "General" to, well, anything else, then things Excel regards as numbers will be aligned to the right edge of a cell while things it regards as not-numbers will be aligned to the left edge of the cell. Though true, it is not always useful because formatting frequently IS changed before import, so by the time you begin setting up formulas, it is too late to notice easily.

    How you most easily tell is you see strange formula results and then look into the cell for signs of this kind of thing. (Or do so before working on formulas.) In your case, if you hit F2 to edit a cell, say J2, you fine the value you expect PLUS one more character, the offending one. From Exxcel's point of view, "300 " might as well be "300Q" or "300š"... it will be treated as text.

    The way to fix simple versions of this, from, for instance, websites that are really only concerned with reason 1), above, is to simply press F2 on the cell, then Shift-Left Arrow to highlight the blank space, then "Copy" (with Ctrl-C perhaps), and Escape, and finally, fire up "Find and Replace" (with Ctrl-H perhaps) and in the "Find what" box, paste the character you copied. Tell it to Replace All and see what happens to Excel's treatment of the data.

    Bear in mind that there may even be more of these things in a cell. At the beginning as well as the end, in the vlaue itself, and even unseen to the eye. Really, unseen to the eye. Characters used for these purposes can actually take up NO SPACE either on-screen OR in the F2 edit box. The only way to directly see evidence of them is to arrow past one character after another, slowly enough to see clearly if the insertion bar moves one full character at a time. If you hit Left Arrow and it moves past the first 0, then you hit it again and it seems to stay put, you have found one of these characters, one that takes no space, but does exist. You can copy it the same way as above and "Find and Replace" to get rid of it the same way.

    Another is to use a formula to find all of them and remove them. Excel has one called CLEAN() that removes some (ones common 73 years ago when the function was created, but almost always, none that are used now). Another approach is to use a formula that extracts the characters one-by-one and only keeps those on a list. The difficulty there is being careful not to lose things because you didn't anticipate needing them on the list. But a list is not hard to make. You can create a list of characters and see if any are useless to you (because they are blanks, for instance) and delete those from the list, letting all others stay.

    If your data is all numeric (like column J, almost), you can even make the list very short: numerals and characters like "-", ".", ",", and so on. Arithmetic operators too perhaps, if appropriate. Whatever short little list seems to suit. Then perform the above comparison character-by-character (easy formula) against it, and the result should be a column of numbers.

    In your case though, easy-peasey. Just do the F2-highligh-copy-Escape-F&R-paste the copied character-Replace All and you're done.

    There are also ways to scrape web page data that either do not capture this kind of character (um... often do not anyway) or act upon the data being imported before it is dumped into your spreadsheet. (Power Query, which comes with Excel, is one of these latter kinds of things.) Might be worth looking into if you do this a lot, or try some of the above first.

    An error occurred while saving the comment
    Roy commented  · 

    If you mean the copying is of an image of the data, a picture if you will, then Excel cannot help. You may be able to render it as editable text using an OCR product, then inspect the result and import it into Excel if the result looks like the original information, not a corrupt version of it.

    If you receive it in a PDF, and copying it to Excel, or anything really, fails to work as hoped for (your data is all over the place, divided weirdly, has a lot of dreck in it), then there's a trick one can use if using Adobe's Acrobat product.

    If you mean you can copy the material as editable text but numbers come formatted as text which, when the format is changed, stays as text, there are workarounds to force the change to take place. Of course, that is exactly what I am asking them to fix up.

    1) You can use F2 to edit the cell, then immediately hit Enter and it forces the conversion to a number. Tedious, to say the least, when there are many of them to do.

    2) You can use Paste|Special to multiply the cell or cells by 1, or to add 0, and the operation forces the conversion to a number to happen. Annoying to do, and still hard if there are thousands of rows/cells, and especially if the cells are not in one neat (no matter how small or huge) set, like a single column.

    3) You can set up a helper column in which you multiply each cell by 1 or add 0 (or other operations that don't really change values, even using functions or the "- -" trick one uses converting TRUE/FALSE to 1/0), then copy and paste the results overtop the old values. Same as the last, in that you force the conversion to happen, just not in the original place, then paste over the orginals. Tedious, prone to error, some people hate helper columns, and as in the other two, get a phone call, or whatever else might interrupt you, and... ruination.

    4) Anything one can do by hand, one can automate with a macro too.

    Note, they really are still text after the format is changed. If you format as text, enter a number, change the format to General or some other number format, then check the cell with ISTEXT(), it reports TRUE. After forcing the conversion as the above workarounds would, or any other workaround you've heard of would, it reports FALSE. So it really IS still text until the conversion is physically forced upon it.

    Sidenote: Mentioning the forcing of TRUE/FALSE values to literal 1/0 values for further use in formulas makes me wonder if the reason this is an issue is tied to that exact issue.

    Excel is always talked about as if it regards TRUE/FALSE as 1/0, BUT... as those who do the talking always move onto telling you how to force Excel to regard them so, one trick or the other (like the unary multiplication ("- -") or multiplying by a matrix of 1's or what-have-you, they are implicitly admitting that Excel is WILLING TO regard them as 1/0 values, but does NOT do so on its own. And maintaining that situation may be tied into this formatting issue. Solving this might require actually regarding the TRUE/FALSE returns as 1's and 0's in actual fact, rather than just being willing to if forced to.

    Would love to see that happen too, I believe. I'm not aware of a single time in 30+ years of using spreadsheets that I ever used TRUE/FALSE returns as text by choice, only as such when I needed to IF()-test the returns and I would have been happy to use "=1" instead of "=TRUE" instead!

    Make it go away!

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

    We’ll send you updates on this idea

    1 comment  ·  Excel for Windows (Desktop Application) » Other  ·  Flag idea as inappropriate…  ·  Admin →
    An error occurred while saving the comment
    Roy commented  · 

    Just to add data, there is no crash using Version 2006 (Build 13001.20384 Click-to-Run).

  7. 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  · 
  8. 17 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  · 

    For those situations needing to import data and preserve the leading 0's, or for that matter, import dates, or NOT import date-like data as dates, I just posted something on the much older and therefore more voted for, but just as ignored:

    https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/10374741-stop-excel-from-changing-large-numbers-actually

    which I shall paste in a second (though I suggest voting there as well). This will NOT help with entering data or pasting data, only with data import.

    And so:

    I've lucked across the Dead Sea Scrolls of opening a CSV in "the old manner" in the second answer in a Stack Exchange (Super User) answer:

    https://superuser.com/questions/1574847/how-to-import-external-csv-text-file-without-table-formatting

    —— Slightly modified, just the last step ——

    (This is different from the version of the old wizard that is presented in the Text to Columns feature in that it still works to do the actual importation, not just to break up already imported or existing data. Same tool, just allowed to act at the moment of importation instead of only after the damage is done.)

    Basically, go to Options and make sure that in the selections under the Data heading (at the bottom of them in the "Show legacy data import wizards" section and make sure the third one (at least, required for this... but I've always checked them all, eh?) is selected.

    Then, to use the old import wizard the way we all remember it working, go to Data in the Ribbon, choose the first choice on it: "Get Data", and choose "Legacy Wizards" from the dropdown menu.

    Here's a nasty foolishness on their part: Pick "From Text (Legacy)" from the dropdown new menu. The foolishness comes from how many people won't know that isn't just .TXT files, but several types of such including .CSV files (and, well, literally anything you think you'd like to try this on for that matter). Anyway, pick it and use the file browser that pops up to find your file and select it.

    NOW you finally have the old wizard, functioning precisely as we remember it, and BEFORE it opens the CSV file so BEFORE it destroys information forever. Do like you always did, select "Delimited" and move on, make sure "Comma" is a selected delimiter (really, make it the only one to avoid hassles), and then the magical step... click "Next" to get to the step in which you tell Excel how to import the various columns: as General (it will hammer you if it can find a way), Text, Date (for various layouts), and Skip. (If you are using a different delimiter, you can do a couple other things, but they are not germane to CSV importation.)

    Finally, click "Finish" and you're... well, almost home free.

    Here's where you'll probably diverge from the Super User answer which assumes you want a continuing connection and a Table. If you do, just choose options as you wish, or don't change anything, just click "OK" and you have a nicely imported Table from the CSV which keeps leading 0's and so on (if you marked that/those column/s to import as Text).

    If you JUST WANT A FREAKING BLOCK OF IMPORTED DATA, do one last thing: Uncheck the "Add this data to the Data Model" checkbox (just above the lower left corner's "Properties" button). Now your import will truly be like the old days, just a slick import of the CSV's data with you having had the ability to force the importation approach for any column you wished to do so for. Had date-like data but they weren't dates? You marked them Text and now you're a WINNER! Ruined data is your fault only, like it should be!

    I always knew Super User was good for something other than providing cowardly passive aggressive sniping at people's answers and being adolescent t*rd-eating Nazi mountebanks drunk on their internet "power"! Thank you Super User!

    Roy supported this idea  · 
  9. 3 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  · 
    An error occurred while saving the comment
    Roy commented  · 

    Yeah, that'd be nice.

    For now, the following will reverse a cell's string. Assuming the string is in A1, use:

    =TEXTJOIN("",FALSE,MID(A1,SEQUENCE(1,LEN(A1),LEN(A1),-1),1))

    and that formula (minus the initial "=") can be use in any other formula if one wishes to use the reversed string as a portion of a larger formula.

  10. 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  · 
  11. 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  · 
  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  · 

    Sure, Word will do simple sorting, though you might need to be careful with it until you've learned its foibles.

    Notepad++ will do a fine job by reading what others say about it though I have no experience with it. Free too, and safe it seems.

    Excel can do some pretty decent sorting. It could even in the days of sorting by no more than three fields. And as Thomas K notes, the new sorting functions can ease even that.

    If sometime you post a small but representative set of data, someone might be able to give you an answer much more relavent to your exact situation.

    But that could be slow in coming... as Thomas K notes, this is not a support forum. BUT a site like StackExchange, Super User subsite, IS a fine support forum in which giving example data, stating how it doesn't work out for you, and what you've tried will get you fine responses and very quickly. Even if this is solved for you, it's something worth remembering for the future.

  13. 2 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 could even achieve a greater than or less than approach more directly by adapting something like the following to suit where input and data are:

    =XLOOKUP(SEQUENCE(1,Table1[[#Headers],[10]]-$B$11,Table1[[#Headers],[10]]-$B$11+1),VALUE(Table1[#Headers]),A4:J4)

    An error occurred while saving the comment
    Roy commented  · 

    if you consider that they are treated as Text by Excel in the context of a lookup function (for which the difference is often critical, while they are NOT treated as text for a simple " =C6-Table1[[#Headers], [200]] " formula: Excel is quite prepared to realize most are demanding that formula only consider the "number-ness" of the header value), a way forward presents itself:

    =XLOOKUP(J11,VALUE(Table1[#Headers]),Table1[@],,-1)

    in which I've simply wrapped the headers expression (2nd parameter) in the VALUE() function.

    And it works, producing an ansswer of "625".

    This is a longstanding "thing" and unlike most Excel hassles, on the actual surface of the problem, you can see how it really has to be this way. (Most times, the "why" (for how it ever happened in the first place, or for the compelling reason for it once you realize it) is pretty hidden, but not here.) ANY lookup function MUST be able to distinguish text data from numerical data, or else a tremendous amount of material could never be searchable given Excel's built-in 15 significant character limit for numbers. So this will always have to be worked around when one has "the opposite" problem.

    But wrapping the lookup range in VALUE() is quick and easy, natural (sort of) given the siutuation. So I seriously doubt they will change this behavior.

    But again, VERY EASY workaround which hopefully ameliorates the pain somewhat, downgrading it to simple obnoxiousness. And speaking of simple obnoxiousness, who couldn't use another little sister?

    Seriously, now you're thinking of it, it may explain some difficulties you've has in other lookups over the years, and a solution for them like the following:

    =IFERROR(VLOOKUP(A1,B1:F2,3,FALSE),VLOOUP(VALUE(A1),B1:F2,3,FALSE))

    especially if receiving data from others or scraping from the internet.

  14. 5 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  · 
  15. 14 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  · 
  16. 1,077 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  · 
  17. 594 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. 36 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

  19. 45 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. 83 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  · 

Feedback and Knowledge Base