Feedback by UserVoice

Roy

My feedback

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

    @Scott McGee: Yeah, if it were worded differently. But it was not so he meant the tobacco kind.

    Also, PQ has its own issues. I like it for handling things that I used to have to do piecewise, and/or repeatedly. And toher things. It's just great, in general.

    But... it still strips the leading zeros from common CSV files BEFORE you can ever interact with the data (and protect it!). It still imports long numeral strings formatted as General even though you put in a step to "Change Type" to Text. Small, but real aggravations, which eahc need their own attention and workarounds: at least it DOES preserve the data for me to then work on dressing up all such things, which, as I said, is soooo much better than data loss before I even get to touch it, but... it's not truly ideal. The simple Import Wizard did apply the Text format to its output so no followup was needed.

    The biggest thing is so many users just really have the ability to just open the CSV file, at least vs. interact with PQ. So while it's wonderful to have so many things now available in an import, I still want to have the basic function so many users take for granted and want to use... I just want it to work right, not work crippled from the get-go.

    It's like I said for many years, when there was a point, computers have to become like toasters for users of them to become ubiquitous. The average user never wanted to HAVE to control and decide on so many things with Windows computers (hardware, for example), they just wanted them to work out of the box, as they expected. And... not have to pay $5,000 extra to Apple for the privilege. Now you buy a phone or tablet and that actually, mostly, happens, and ubiquity is no longer a discussion topic. Same here. They don't want to "do this and that stuff, then it will work like you think, except of course, for the permanently lost data...": They just want to click and it works.

    Which, in this case, is just so insanely not unreasonable and is actually more or less touted as the reason behind what MS does here. So not unreasonable that it seems like it really ought to be.

    Of course, the flip side is job security...

    An error occurred while saving the comment
    Roy commented  · 

    @Gary: Yep, there is always that flip side. But at least it is non-destructive: you can DO something about it afterward on a full, complete data set, not a destructively altered one that simply cannot be reliably restored to its orginial state.

    But absolutely, there is that flip side. Another flip side: there are tons of people who just don't care, or actively like it. Fewer tons than don't like it, I do believe, but tons and tons nonetheless.

    For me, above all the other aggravations about it and all the utter stupidity of it, is the so simple fact that if Excel simply engaged the longtime, basic, no frills Import Wizard, almost all the aggravation would be gone because I WOULD (and have done for decades with other file types) simply tell it to import those columns I know ahead of time to be impacted as Text. And like for years with other file types, the absolute first thing I check is for that issue, and related ones like changes from numerals to dates with the concomittant change from original numerals to the date integers. So easy a thing and it would solve so many people's problems, taking this problem down at least a magnitude.

    Just engage that simple, straightforward Import Wizard. Just that.

    And for those who don't care, they have a simple click of cancel to overcome the change and get a mindless dump and change. A hugely slight extra bit for them solves nightmares for so many others.

    But... they won't even stir themselves to do that little thing.

    And Zak, enjoy the dip. Like ex-running back Walt Garrison used to say as he encouraged millions to court a series of "you-don't-have-a-face-and/or-throat-anymore" cancers with "Just a pinch between your cheek and gum..." (you know, so long as you still have the cheek and/or the gums)... No, forget that. Toss the dip in the trash and skip pushing it on me.

    One eye-opening day in my past, not formative, just eye-opening, was my parents moving to NC, outside Asheville, and one visit sitting in the little valley's bottomland matriarch Ma Huggins' living room gradually meeting much of her extended family and having a 6yo girl and a 7yo boy both, during my time on the same couch, pull out well-worn "tobaccy" pouches (you know, the old zip up kind bigger than a woman's clutch style purse, and pull out wads of new tobaccy to replace the... used... wads they'd just cleared out (cleared, not cleaned, I'm still sure). 1st and 2nd grade and they had their own well-used tobaccy pouches, filled with fresh tobaccy from their drying sheds... That needs to die out, not go wild, so keep the dip idea to yourself or your speeches in the park while families are just trying to have a pleasant picnic in the sun, thank you.

    An error occurred while saving the comment
    Roy commented  · 

    As for "WHY" a person needs it, it JUST DOESN'T MATTER. It is needed and that's the ever-loving end of it. Anyone at MS who thinks otherwise needs a new head.

    In general, I'll point out that I am SICK TO DEATH of one loser after another in the computer world (including a persistent one on this site) telling me "NO MORON, you shouldn't ever do it that way and we won't let you!"

    The worst of the awful situation? When you format it as text, at that moment it becomes literal text in that it is saved precisely as the word "horse" is saved. Because it CAN'Tbe saved the way Excel saves numbers. So there it is, all those lovely bytes, doing what's needed, and Excel actually goes to the work to save it as a number, chooses to work from left to right rather than right to left, and then pads it with zeros. And THEN it saves it into the CSV where each digit is AGAIN bytes like an "h" is bytes, not like a numeral is. Back and forth... apparently when THEY wish to do something with it, it is all just fine and dandy, not "you shouldn't ever" kind of stuff.

    If it is formatted as text, currency, or as a blue helicopter, that's how it should be output into a CSV (or any other format) file. And as to import, Excel should do whatever it must to present exactly what was presented for import after it is imported. If there was a 40 digit number imported and that cannot be handled as a number, then it shouldn't be: it should be handled as text. NOT as "Oh heck, this looks number-y so it's now a number! Hey, Presto!"

    SICK TO DEATH at being told "P*ss off a**hole."

    An error occurred while saving the comment
    Roy commented  · 

    Yeah, there's NEVER a time when I want anything converted to scientific notation. For real (actually rounded to the displayed value), or for display.

    But yeah, the CSV importing is really annoying. Here's a thought I can't make work if regarding MS as a sensible, clever, set of folks: if a CSV field starts with a "0", then it was considered important to save it with a leading "0" and therefore cleverness suggests it ought to be preserved in the import. And yet, it isn't. It is hard to see that as anything but stupid.

    A series of digits with a decimal separator in them? I'd forgive someone thinking without asking that they are meant to be considered a number. A series of digits with appropriate separators for the installed version's national date or time system separators? OK, hard to argue with thinking that you want a date or time format. But it goes too widely for cleverness there.

    And you know? I'd really rather it not do any of that but rather simply import everything as text exactly as it appears in the "it was important to output it like this so it's important to import it like this" CSV file. Or as an absolute minimum, say something like "The following fields seem to be non-textual information. Please follow the opened import wizard if you wish them to be imported as particular non-textual information, or close the wizard for them to be imported as textual information." You know, and actually do what it offers to do.

    Data|From text/CSV IS actually useful and useable, but I shouldn't have to do so to overcome Excel's predelictions.

    By the way, Excel only uses the first 8 records to decide how to import, unless you go to the trouble (and like in the play, that's Trouble with a capital T) to change it. That's why you get formats like minutes:seconds for a time column (or simply 2-3-4 digits with a ":" between them), not hours:minutes:seconds for some imports and similarly other situations. You CAN set it to look at a million if you lke, but not only does that slow things down (or used to, computers are much faster nowadays) because it looks for EVERY field, but it's Trouble with a capital T just to set. I'd have to hunt it down on the internet again to do it.

    In the meantime though, anyone suggesting we use Data|From text/CSV is right about it working well. Just don't need to hear the smugness of their religious feelings for it most times they say it. It's like listening to a vegan. (Though they're not right, either factually, or "in the head," while these guys are, factually anyway.)

    But MS gotsta fix it man! It shouldn't happen to need a workaround, shouldn't happen at all.

    An error occurred while saving the comment
    Roy commented  · 

    It WILL treat them as text, so long as a moment when it isn't being told to exists. Just a wee sliver in the matrix somewhen is all it takes.

    And in that instant, it's over. Just done. That's why it's gotta be handled in that engine that first addresses material in a cell, judges it, passes on to the rest of Excel what the material it just read is and therefore how Excel will thenceforth handle it.

    If I highlight four contiguous cells in a column, and format them " * 0;;;* @ " and fill them with text, OR fill them with numbers, and they all work as expected. More interestingly, one can go a couple cells down (empty cells before you type again) and type more and the formatting is helpfully extended down.

    But format four cells text, then fill them with 20 digit numeral sequences, and the absolute next empty cell doesn't even have that courtesy.

    It's instant, the shift from text to numbers the instant the least, visible or not visible, shift out of the protected zone occurs, unless one took "heroic" measures in formatting and sometimes not then.

    Unacceptable. Undesired. It just can't be hair-trigger even if they keep it not much changed. There has to be some play in it.

    An error occurred while saving the comment
    Roy commented  · 

    Stored as a number, using quad precision floating point binary numbers, takes 16 bytes to store a 33-36 digit precision value. Excel works internally with something at least 27 digits (their own web pages) and that might not include the sign so this is the ballpark and it has surely, yes, been so from the start.

    Because of that premium. Consider that a 27 digit text representation took 27 bytes minimum, and more for ASCII+ work, then upped again for Unicode, and you can see how people with single-sided, 8", 160K floppies might've reacted to them, and all competitors NOT optimizing that way.

    Points though:

    1) No need to have ever forced PRESENTATION to go through a "must display as" engine. It should always have allowed various uses of the values. They were being STORED that way, not necessarily being USED that way.
    2) Um, things change folks, they change... as early as possible, limitations should be programmed away. This should have been done away with by 1990 at the latest. 486's and the hard drives of the day ($1,000 for a thousand MB, but still, we bought them) could have allowed doing away with the optimizing if the presentation engine was too deep or arcane to change, and Lord, folks, they wrote Windows fresh (um, copied freely, but that's ideas, not code), and ten years later, wrote it fresh again, and then ten years later wrote THAT fresh again. So writing things fresh is NOT an insurmountable idea, conceptually or practically, for MS.
    3) Now there is literally no excuse on God's green earth. Not even gonna amplify that.

    Yes, been there since God was in knickers. And been hated by almost everyone the whole entire time. Did we buy it knowing this? Yes Jason, we did. Does that mean we have to like it? I'm sure that's MS's position. But they can suck eggs if it is. THAT doesn't need amplification either 'cause it's so obvious.

    An error occurred while saving the comment
    Roy commented  · 

    Ah, and to be explicit, it does the import just fine, leading 0's and whatever. Sadly, it then feeds that through its "every bit of entry work you ever do" engine to decide how to store each cell produced. So that is where the real problem is, that engine that goes to work when you press Enter or Tab or mouse away after every bit of typing, and before it displays pastings, and so on.

    Not the import itself.

    An error occurred while saving the comment
    Roy commented  · 

    Yes, the issue is multi-faceted and a hassle and annoying.

    Connor's idea and explanation are fine, and actually, most of us are forced to find the capability elsewhere, but it works fine.

    WHEN Excel lets it go into action. Which is does not with CSV files, hence my earlier reply to Connor. You simply never get the chance.

    If I type text into a cell it may widen to take it, but never, no not ever, for numbers. You get the annoying counter-explicit-format change to SN. Leading 0's are dropped. That's an ISSUE folks. Trailing 0's get dropped too. (If they didn't, one could reasonably easily apply one's own approach to the significant figures (religious war) needs, but you simply "can't even" (like the kid who could only speak the odd numbers) because information required for the issue is simply stripped away.

    Yeah, there's lots of "you ought've..." kind of stuff, but you know, if I EXXPLICITLY formatted a cell Excel should absolutely never, never, ever ovverride that and nothing should EVER be stripped from my entry. What if lower case g's were deemed unneeded by Excel? (Just some April Fools joke, hopefully, gone the next day) And "golf" was automatically, it's just GONE, stripped down to "olf"? No recovery, no restoring it while chiding yourself to remember it was to happen and plan ahead next time. Just gone. Zero may be special, but it's largely the same thing. Period.

    NEVER ever, in all the times I've seen this addressed here or anywhere else, have I ever seen a comment like "Um, I actually count on it to do that." Not freaking ever.

    So we have to physically widen columns, then coax the display back to numerals, not SN, we have to live with the lost leading and trailing 0's, we have text entries like Corin mentions that can be nightmares (yes, you see them and make them right, but import 20,000 rows and one's buried in row 13,485, and it creates a number that is not 30 magnitudes out of whack, but just maybe three or four magnitudes and a value calculated from numbers in the column is sudden VERY wrong, but in a "the total was seven times too high, but I never noticed that other than to note things using THAT total seemed a mite high" way, not "it was four billion times too high so I noticed something was wrong" way. "Silent errors" if you like. Who amongst us has a suite of conditional formatting and special auditing sums applied to his data inputs... and the time to check them thoroughly each time data is brought in? Alright, plenty of us make some attempt, but very few are able to make comprehensive checks to the problem Corin notes can kill ya.

    It's just all bad and we'd like it to not be. The Import Wizard had the wonderful feature of being able to tell Excel "nah, you just do it for me" by clicking "Finish" at any point. NOT available in pretty much any other "smart" features.

    No one claims to benefit from any of it and to prefer it. Lots of us have been annoyed or screwed. So why not get to work and fix it all?

    Oh, yeah, the real workarounds for the CSV problem pretty much involve the TXT extension replacing the CSV extension. That's a real good point by someone... could've sworn I saw a comment with that flash by here. Oh well.

    One thing else about Excel's handling of all this is that your settings in the Import Wizard vis-a-vis the delimiters affect a copy from another program, a browser perhaps, and paste into Excel. That's why sometimes you copy and paste something and it goes all into one cell, multiple lined, or it goes into several cells, but all one column, and some other times it goes one word-equivalent or so into lots of cells and rows. So you get a payment card email and usually just copy and paste the email's data into an input area then read the output to perform the charge, but no, today is after yesterday's work which involved importing and today that paste overwrites 12 columns instead of being 23 rows in a single column. And the user calls you, badly describes things, and thinks your spreadsheet is garbage, then is hard to lead through solving the issue. Thank you Excel. They could separate functionalities there too while solving this and I would not complain!

    An error occurred while saving the comment
    Roy commented  · 

    @Connor

    Yeah, see, the thing is... for a CSV file Excel 99.9999% of the time opens it directly without ever going to the Text Wizard.

    At all.

    So, you know, we CAN'T do those things.

    Ball: still in Microsoft's court.

    An error occurred while saving the comment
    Roy commented  · 

    You know, things should just simply be there as entered. Whetehr hand entered, dragged and dropped, imported, whatever, simply recorded as entered.

    Then I write a formula that references it and Excel reads it... and does whatever it can. If I use it as a number and Excel can't figure out how to use the character string as a number — AT THAT MOMENT AND FOR THAT USAGE ONLY — it simply gives an approriate error. And continues to leave the underlying character string, in General format if I didn't choose to apply some other, ALONE.

    Period.

    If it's the equivalent of "82happysanta9" and I try to add it to something, well, my bad. No errors simply because I had to format it as text to keep the whole thing. Simple, straightforward.

    I might also point out a niche advantage one would have here: since all the entered characters would be present, I, or Excel, could easily (relatively easily) calculate correct significant figures, ALWAYS. It would be so easy, they could easily program a format symbol to add to any numerical format it could work with that would literally, not just display-wise, change a result to only keep the proper significant figures. (I guess a second symbol would have to be available to mark some entries as constants so they get used properly in that.)

    With that, everyone could use their own silo's standards about significant figures and rounding to give the results they need.

    It's ridiculous... they say Excel has engineers in mind and then one of the most basic engines in it whacks characters from start and end of entered data with no workable way to prevent it. "Su data es mi data," sayeth the Excel.

    An error occurred while saving the comment
    Roy commented  · 

    And that's a lie. You read it.

    Ciao. Forever.

    An error occurred while saving the comment
    Roy commented  · 

    It wasn't a rant. And it responded to the question raised herein about wasn't the one of the two functions enough.

    Further, just don't comment in a mean way about it then. If someone does, I reserve the right to respond back from a position of having been insulted.

    They taught basic people interaction in kindergarten in my day. Sad you need a reminder or short course on this.

    Also, if someone doesn't care, they can say it. If they find it boring, they can say it. Or, of course, just keep it to themselves. They don't have to imply the issue was there being more paragraphs than they can bring themselves to read on any given topic, or just mine.

    Response from a position of having been insulted is perfectly appropriate when having been insulted.

    Meanwhile, rant on for no real reason since YOU haven't been insulted. I doubt MS minds when we eat our own instead of concentrating on their products.

    An error occurred while saving the comment
    Roy commented  · 

    @i just:

    No problem. No need in this life to read things for comprehension. That's a primary school concern, right? Who cares after 2-3rd grade.

    Gosh... those hopeful "when will..." questions are really complaints? Who knew? (Those 3rd graders I guess.) Wow, that must mean the passive-aggressive epidemic is out of control. Soon it will rival the tl;dr epidemic.

    I'm not sure that as a people we deserve decent product features from MS. (Whew! Just three paragraphs this time!)

    An error occurred while saving the comment
    Roy commented  · 

    @Patrick, et al (should be "et ALL" in this case): Not to be a Debbie Downer, but... remember when they first touted the new Array functions? Ooohhh... "Spill" fucntions... Remember how they went on and on and let websites show them in use... oooohhh... and said only special people had them for now, but they'd roll out soon and change the world?

    Yeah, like at least six months ago, a half year ago. Got them yet? Nay.

    So, (VERY) sadly, even if they told us this was done and would roll out immediately, I a'gonna have to say I'd expect an utter minimum of the same half year Spill functions (oooohhh... Spill functions...) have taken. And EVERY day longer they take, gotta add that to anything claimed about this.

    And...

    Ain't nobody claiming anything here is being taken seriously enough to be, well, anywhere on a path to the day when they can announce it is done and will roll out immediately. Not even six-months-immediately.

    So it looks like I shall die without seeing it happen. (The truth hurts.) So be careful with that name Patrick. Don't get pushed into a stance you have to live with because 'If this be worthwhile spreadsheet programming, golly, I'd make the most of it: Give me the numbers I typed or give me death!' could go badly. Definitely slowly either way.

    An error occurred while saving the comment
    Roy commented  · 

    @i just: There is indeed a SEARCH(), probably because 1-2-3 had it, or had FIND(), and they were stealing everything Lotus did... I mean, they had to have Lotus' version for compatibility or business people whose bosses were paying for 1-2-3 wouldn't even try Excel for free. (That's a chilling thing for the economists... won't even try it for free, really free, not like internet or physical store free. I loved free Excel though till they killed all competitors and begfan to charge a ton. Sigh...)

    Actually, I WOULD value a SEARH() that could search a range of cells. (And that could begin with "instance 4" of the value being searched for!) My problem... I mean "use case" right?... is an idiotic software vendor whose idea of Excel export of their reports is spreadsheets that LOOK LIKE their reports. Not ones with a simple row and column presentation of the data. Worse, they are not in any way consistent about how the material goes into the report. So a value I need that is somewhere relative to another value that is unchanging... find it that easily?... nay... the two values could be in any of 10+ cells in one report, and not consistently either so I can't find the one and move consistently to find the other. Contortions are needed. If I could search a block, I could easily specify the range of cells (3-4 coluumns, 3-4 rows, but easy to define for each block) and get the value I really need. So a real Search function, not just a clone of FIND() would be NICE. Or if one used the "instance number" approach so you could specify, say, the 3rd instance, while the other kept the "starting location" approach so we would be able to do whichever was best suited.

    No, FIND() is not sufficient.

    Imagine my aggravation when the idiots led me on, then showed me their newest idea to create a lot of fake hits on Bing. "We got market share... we do!... what do we call our product again?... oh yeah, Bing... Bing has relavence! It does!"

    And then again a week ago after half a year had passed since I looked at that useless bit of garbage... 'cause I'd forgotten that's what it had presented before... only to find that was STILL the new and shiny special thing to excite us with. So never doing that again, not 40 years from now, if I live that long, 'cause it's just garbage.

    An error occurred while saving the comment
    Roy commented  · 

    @Futski:

    Just tried that, out of some interest, eh? Edited the CSV file, saved it with NotePad, opened in Excel and it completely ignored them.

    An error occurred while saving the comment
    Roy commented  · 

    @orgen:

    Actually, for that problem, the TEXT option is precisely what you DO need.

    Base changing functions for anything "past" Decimal require your input to be text. So being imported with that option set for the column will accomplish exactly what you need.

    Suggestion's point is still very, very desirable.

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

    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.

  3. 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  · 
  4. 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  · 
  5. 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  · 
  6. 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.

  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  · 

    To use LOOKUP(), your data has to be sorted using the column you use for the lookup. In this case, the data must be sorted by column E.

    Given that condition, the function is actually giving correct (though undesired) results.

    If you use XLOOKUP(), the problem goes away (assuming your version has it, of course). If you use VLOOKUP() and use "false" as the last (fourth) parameter in it, the problem will go away. That is, use the following formula in K12:

    =VLOOKUP(J12,$E5:$F10,2,false)

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

    We’ll send you updates on this idea

    Wow.

    Thank you to all those participated in our survey. What an amazing number of responses, many of them with very deep content. We’re processing the over ten thousand responses(!), and already appreciate the time so many of you took to answer with passion and experience.

    Please know this survey is used to help influence various topics – both on Python as well as other related topics that the comments started to bleed into. Given the passion, I want to be clear this remains an area of exploration for us, without any specific timeline.

    We’ll provide updates as we progress on this feature request.

    Thanks!

    Ashvini Sharma
    Lead Program Manager
    Excel

    An error occurred while saving the comment
    Roy commented  · 

    Sure it is. If I want to pay twice for it what I do for Excel itself.

    Not today please.

    An error occurred while saving the comment
    Roy commented  · 

    The absolute chief value to Python as a scripting language would be MS completely surrendering the world of Excel scripting (perhaps including a little more than the obvious macros and UDF's) to an outside agency.

    MS has not updated VBA, except for small fixing and accomodation of the fact of some additional features, for a very long time and actively plans to never do so. This is not a way they intend to spend money or other resources. Period.

    If they do, and one considers the fact that Excel MUST have a macro language, and the fact that they might like to move forward with versions of Excel that actually drop supposrt for VBA itself (though many would still have versions it works in), their obvious role would be to maintain entry to Excel's data, and objects in general, publishing and updating as time passes, and EVERY programming language, open source or owned, that wished to, could build out itself to be a scripting language for Excel, in whole or in part.

    The language owner would then be the one responsible for all the work and cost. It would be responsible for making it work and fixing bugs or deficiencies. For deciding how strongly to support it. For updating for changes in Excel's underlying progrramming and therefore the access into it. For adding functionality in general, or for explaining why only some aspects were being used by the language, not all. For arranging cooperation between it and other languages a programmer/spreadsheet developer might wish to use in conjunction in their workbook.

    Etc.

    Which, for the love of God, is how we should want it. (Always given that MS is clearly absolutely committed to NOT ever spending a dime on a seamless, "internal" solution to the need.)

    This would also permit one to learn and use VBA, as long as it lasted. As changes in Excel broke aspects of it, and no fixes came along, it would be less and less useful, but that seems something MS doesn't mind anyway, so replacements are needed... anyway.

    Python itself? Yeah, today, and for a lifetime for current programmers in it (still have a TON of COBOL programmers collecting consutling fees at the age of 85), strong and popular. But tomorrow, maybe a new language buds off a current one, or is conceived fresh for the future, and it too can be used, if the developers, paid or contributing, care for it to be.

    So basically... it is NOT simply a gripe by lazy nerds to have their own "pet" thing done.

    (Although, sure, there's that too. But it's a tiny component!)

    It's the obvious future and a general, not specific-to-Python, solution, like above, on MS's part is the true gain to be pushed for here.

    Although... it's a stunning number of votes compared to the number for other top suggestions!

    Consider too, the "thousand flowers" that could bloom if suddenly every Python programmer could write add-in's and UDF's, ones that sing, not clomp their ways to the end of the task. Python's been a thing for a generation now, so there are a LOT of programmers using it. Even without MS's cooperation, there's a lot of Excel you can currently do with it. (So it's a better frontman than, say, COBOL or GW Basic.)

    But "way more nice to have than anecessity"? Only if you limit the thought to just implementin Python itself and really changing nothing else. And that's somewhat arguable anyway even if VBA is rock-solid.

    Also, as I say, with the responsibility to make languages work off their shoulders, maybe Excel would attack to "basic core functionality" issues we all want instead of just not doing some because they don't want required parallel work to do like making VBA not just accomodate re-written code, changed functionalities, and the altered object model, but be rock-solid and seamless for even a casual user of VBA (any break in the chain from casual user to competent to skilled vis-a-vis VBA risks permanently breaking movement up in skill).

    An error occurred while saving the comment
    Roy commented  · 

    Indeed... and as MS ignores the idea, more will be created on the Python end.

    MS: that thing you're sucking? It's called "hind ***" and y'all best watch you don't get pushed off that too.

    An error occurred while saving the comment
    Roy commented  · 

    @Ivan:

    Well, VBA is dead to MS. There HAVE been small, small changes after the point they said it was done, would not be advanced further. (That, in itself, wasn't a bad thing as Excel is not chiefly used by programmers but rather by non-programmers so a set, unchanging VBA landscape had and has tremendous appeal to many.) But there is no growth, no new directions to accomodate more recent programming approaches, and no new or updated features. Nor will there be.It is NOT (ever going to be) "evolving."

    For those great many though that DO want an evolving programming language, Python seems to fill the bill. For MS, the workload to accomodate it after the inital accomodation would be minimal and only necessary because the likely don't wish to expose that aspect of Excel... or Python developers would surely get right after doing that for them as well.

    I acknowledge the current "others" but if I wanted to write code inside Excel that could reach out to a program I also wrote, or just use, that will do the real work hidden from users by being, well, a program, yet still be interactive at a very basic (ouch...) level with Excel so it can at the minimum be a front end if I like, well, something a lot like Python might be my choice. For many, many things.

    It literally cannot hurt unless you don't have a grip on the important spreadsheets your organization owns. Which happens, yes, but so does money dropped on the ground and poor registration of organization passwords too. But you'd consider that bag of cash you have to be something that cannot hurt, eh?

    Roy supported this idea  · 
  9. 1,040 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  · 

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

    Yes, for God's sake. What kind of primitive, caveman upgrade installation are you doing MS, where you cannot read the value for an option before upgrading the option, and then set the new option to the same or equivalent setting that you recorded? And if you cannot make the transaltion due to some kind of change in which the option's current value might not fit any of the new options for it, then present that the moment the application is next opened with the ability to set the option from the dialogue box presenting the change.

    Jeez people, this is only rocket science if you make it rocket science. If you don't, it's d*mned easy.

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

    And you can avoid the scrolling altogether if you keep typing until it is unambiguous to Excel, then press TAB.

    Works with functions too.

  12. 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  · 
  13. 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  · 
  14. 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  · 
  15. 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 can even use it and INDEX() in combination in a layered approach to give users PRECISE rights to see and/or edit a larger data set with row and column granularity.

    A less complex version of that can be a terrific filter for data to be in a report, as well.

    An error occurred while saving the comment
    Roy commented  · 

    You can use FILTER() first, to make an actual table you can use further, or to make a virtual table in the formula that can be used further.

    So for all the occurrences, just use FILTER() the first way, to make a table as your result set. You can combine with INDEX() to return ONLY the columns of interest, or by itself to get all columns, or just a contiguous range. That would be what you specifically ask for here.

    Used within a function (well, the real table way too, just not in one step), you can then use functions like SORT() to order them differently for further processing, or LARGE() or SMALL() to get the "nth" one from either end, or a counting function to get how many rows exist and then pick one by number (though that's basically the same as SMALL() picking one n items from the start). You can even use those functions to get the top 10 or bottom 3 or what-have-you. Be an Olympic skating score provider and drop the highest and the lowest scores. Lots of variation here.

    FILTER() is a wonderful new friend.

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

    Wow, used to allow it. Really doesn't now. Bummer.

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

    We’ll send you updates on this idea

    Thanks very much for your votes. And to those who took the time to fill in the survey, thank you! This is a brief update to let y’all know that we’ve started work on this feature request along with the one on changing numbers to scientific notation.

    - Urmi [Msft]

    An error occurred while saving the comment
    Roy commented  · 

    If Excel did not do this to input before one had a chance to format it as text, as mentioned a few time herein and just now, this would not be as big a problem. But…

    Here's the thing: no matter what anyone says, if I enter something, or import it, I want absolutely, positively, precisely, exactly the absolute exact thing I entered. PERIOD. Don't ever bother me about "You should" or some other scummy preachy thing you feel will change it from a need or preference discussion into a moral one and that you own the "high ground."

    When I say "I", I DO mean any user of the spreadsheet as well.

    If YOU have other preferences, say so. Don't LIE by wrapping it into a moral argument that I am supposed to understand I have lost from the start and shut up.

    I won't even say I wish it 100% of the time, but I'd rather deal with the times I don't prefer it, than the many times I do prefer it.

    Lord, Excel used to import data from text files I had as numbers, largely, in a column, but sometimes, and I later learned why only sometimes, any six (not eight) digit number would be converted to a date, even as all the others came in as numbers. At least they fixed that about 15 years ago.

    I will also grant that providers of CSV files often include leading zeros "just because"… on the positive side, maybe they figure I might like the option of having them… on the negative side, maybe they couldn't be bothered to add a small filter that stripped them. Doesn't matter: Excel never lets me benefit from it, only suffer.

    Just great to have to work with Zip Codes that have had their leading zero stripped.

    So… ALL the CSV makers in the world can create CSV files with the first eight lines holding fake data that contains whatever complexity is needed for Excel to understand how to import the column, and Excel can then start automatically stripping the first eight rows ('cause you know they'd never leave that for you to do or not do - CSV provider might not have done it,eh? - and they just HAVE to be able to claim added value was provided) OR Excel can just stop. Just freaking stop.

    The devil is in the details, they say, and every little situation is different from the utterly… similar… next one. Even one data provide to another from the same provider and source material can often have new quirks that must be dealt with. NO ONE can provide a "look, we do it for you" solution, not even you yourself. (In a small way, that's good: you have a job because of it.)

    As to Power Query, as I've mentioned here and elsewhere, it's hugely nice about this and a lot of things. But you know what it just won't do? It won't let me set it up using a current file, then, when running it in the future, have a step at the start in which I interactively give it a different file (and likely, path) for it to use. So it has to either have the same filename and path, or I have to make a new one each time. (If anyone knows how to circumvent that, I'm all ears.) Even when it's just a matter of the filenames differ by dates or what-have-you. Want to use it without starting over? Well, rename the file? Copy it over the old file with that name? People weren't done with the old one? Oh, crud… User isn't up on things like that and old data got used? Oh, crud… And there are a lot more pitfalls here.

    It's great when it's handy, and not so much when it's not. It kind of multiplies the good or bad by a lot.

    But simply allowing CSV's — that's all, just allowing them — to be put through the import wizard (could always just click "Finish" to let Excel choose for you) would solve the CSV side of this.

    And the rest? Well, again, if I enter, on purpose, leading zeros, it's just as easy for Excel to simply keep them as it is for it to not keep them. Well, should be… I'd say it's pretty obvious they made a poor, poor choice once upon a time, and now it's awfully hard to change. And that many have workarounds to handle the currently expected beahvior, ones that would be harmful if they got their end results as input instead of the current crud. Since that's me sometimes, for other things, I don't mind some consideration being given to that which has to complicate a solution.

    Truth is though, it's obvious the product's development efforts are being put heavily into other things, and not basic, simple, hard-to-trumpet-as-"game changing" kinds of things. As has been the practice for 30+ years, things like this are ignored likely because they have no "buzz" to them.

    But to clearly reiterate, take that trash moral stance and pack it with the sand. Express a PREFERENCE at odds with mine and that's cool, even if MS picks your single comment as the sole reason to ignore all the rest of us. But tell me I "OUGHT" to… anything… in a forum for suggestions, not preachiness, and nothing you say has the teensiest value. In fact, it establishes you as a troll, just out to vandalize, and your position as garbage. Pack it all with the sand. Right up your…

    An error occurred while saving the comment
    Roy commented  · 

    Oddly enough, Excel KEEPS the leading 0 (doesn't just display it for the cell, but keeps it, visible in the formula bar and counted by the LEN() function) for a decimal entry:

    0.49 for example

    LEN() gives 4 and the 0 is retained in the formula bar display.

    WHY would it ever do that, rather than simply default a display format of "0.00"? Add a trailing 0 and it strips that...

    Yet entering 0095235 strips the leading 0's for real, leaving only LEN()=5 and 95235.

    The day when memory was so low and CPU speed was so slow that individual bytes mattered is over. About 25 years ago, certainly by 20 years ago. And keeping that leading 0 with a decimal only entry doesn't even fit that excuse to begin with.

    Scientific convention requires that leading 0 with a pure decimal. The engineering folks I work for now seem to despise it. None here see any need for the leading 0's in the other example and I wager scientists wouldn't either... that's a bookkeeper's concern maybe, but who cares about them... So maybe Excel did it once upon a time to satisfy a perceived huge base of scientist using Excel. That would fit, too, the always converting number displays to scientific notation when given the least excuse.

    Hard to believe that a huge portion of the 800,000,000 user community is still scientists or day traders. If 20% were scientists, the world would be extraordinarily advanced today, and if that many were day traders, the phrases "financial meltdown" and "new dark age" would be so-2005. Neither is so, so...

    (By the way, the "Anonymous" entry just be low this (4-1, "No, Mr. Ford,...) was mine, I just screwed up and posted it before signing back in. The other fellow was "tres"-aggravating.)

    An error occurred while saving the comment
    Roy commented  · 

    @Anonymous:

    Indeed you can. WHEN Excel even presents the Data|Import process to you. Some file types, which make up a very great many files being imported, such as CSV, are simply opened as Excel pleases with no opportunity ever for the Data|Import wizard.

    Some, like CSV, are changed to scientific notation when they are opened by Excep, before evn doing the import. Just their opening converts the column of data.

    Though oddly, Unicode CSV files often DO have the wizard presented.

    Roy supported this idea  · 
    An error occurred while saving the comment
    Roy commented  · 

    Yes...

    1) How can I even choose to do their limp-along format it as text solution when they are stripped before I even see them? Yes, I can close work and begin again and import as text, but I may not know the leading zero issue exists for data going into said column on import until after I've done a serious amount of work. Why should I lose that?

    2) Since they can keep track of the zeros when I tell them it is text, they should keep track of them however they do when I tell them it is text — as the default, always. When I apply a number format, they can display it appropriately but keep the full entry (or imported data) in its original condition. It all flows naturally when begun that way.

    That would also help an issue I find with general entry in the cell. Say I enter "=14.30+27.51"... presently it is permanently altered to "=14.3+27.51" no matter how much I wish otherwise (I like things human readable and if my data is usually provided with two decimals, I like to see it that way in the cell. Same with function-laden formulas in which a figure is typed... if I put a "0" at the end of the value, it would be helpful to reading and understanding the work if it remained.

    And yeah... that forced change to scientific notation... NO.

    Keep the entries and data original. If a problem arises, I deal with it rather than have no option at all. That might read differently if their solution solved the least little thing, but it's a bull in a china shop solution so... it's worse than useless.

  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. 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  · 
  20. 1,609 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Hi all,

    We have been working on this, and wanted to get your feedback on how you see this feature fitting into your workflow. We have a quick one question survey for you to give us your thoughts on the look and keyboard shortcuts we have at this time. Please see here for more: aka.ms/datePickerSurvey

    Thanks!
    Blake, Excel Product Team

    An error occurred while saving the comment
    Roy commented  · 

    Consider:

    1) 64-bit, no date picker at all, to the great horror and suffering of many causing quite a few to point out there are alternatives to Excel altogether
    2) 32-bit, on its way out as computers are simply replaced. No, not on Jim's computer at "The Smallest Franchise Chain In the World - Just US!" sandwich shop, nor Nora's Win 98 computer still using my blurry-memory favorite version, Excel 97. But on hundreds of millions of multi-computer organization desktops, yeah.

    So... just what are the alternatives? Gosh, PowerApps can allow date picking with ease. You can write mini-apps for non-major problems, gosh, as easily as making a spreadsheet. (Believe that? I have some sea front property in Nebraska... it was! 65 million years ago or so, so... Oh, and 'cause, you know, making a spreadsheet to handle the company's fourth biggest problem is soooo easy, spreadsheet writing really ought not to be considered a skill on job apps. Hmm... JobApps™...) But golly, guess what else the company that licenses PowerApps out for a minimum of five times the license costs for Excel, which all those licensees will also still have anyway sells as a neat data keeping source, if needed, instead of the horrifyingly tought to use SQL style databases of the world... which become radically easier to use if one is paying for their SQL... Just guess...

    So I ask, just what incentive at all do these slugs have to follow through on any promise, or writing that somehow made many intelligent people consider it a truth and/or a promise? If you do some simple (simple: "easy", not simple: brain-addled) arithmetic (not even mathematics), you find a cash flow of potentially $30-$300 billion dollars if enough folks just get fed up with the eminently useful Excel. That's BILL(Gates)-ion, not MILL(certainly not Gates)-ion. It's stunning, really, and the kind of thing that makes monopolists rejuvenated and starry-eyed.

    I can live without it so I'm good. For everyone else, good luck. Like to see it, but I don't think I will.

    An error occurred while saving the comment
    Roy commented  · 

    Honestly though, it takes longer to use it than to just type a date.

    BUT, it does SO MANY other things. For instance, all the different ways people enter dates, some of those people being obstinate, stupid, careless, well-intentioned but not perfect... and some or all of the rpeceding. I've even had someone tell my boss his peoples' field enters dates a certain way and not doing it his (you know it was really his, not his "industry", talk about pretentious) would surely lead to wholesale mistakes.

    Sure, you can hear that talk to the troops right now, right? "I went to bat for you folks, but the &%#@ won. I warned them massive mistakes would be made..." Yeah, not on purpose as part of a "we'll fix his *ss" campaign, right?

    But just no more date entry mistakes (other than careless wrong dates) so one's dependent formulas and such always work? That's a huge thing, all on its own.

    Looking clean, modern, advanced... not to be sneezed at, though not as big. But then, the TV chefs making big money all say something to the effect that "you eat with your eyes first" and that has an application here. First impressions, feeling like one is using great stuff, not the old trash, that all goes into acceptance and willingness to get on board and make something work. So, really not to be sneezed at.

    Roy supported this idea  · 
← Previous 1 3 4 5 17 18

Feedback and Knowledge Base