1,406 votes89 comments · Excel for Windows (Desktop Application) » Editing · Flag idea as inappropriate… · Admin →
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]
MS needs to correct Excel such that it follows normal convention for importing and exporting CSV data.
When importing a quoted CSV field, either text or a number w/leading zeroes, then those quoted fields should be formatted as "Text" in Excel. That way you can import numbers containing leading zeros w/o losing the leading zeroes. Conversely, all text formatted cells should be saved as Quoted text in the CSV regardless of if it looks like a number or not.
An extension to this would be a column that has a number format which adds leading zeros could also be saved in the CSV as quoted text with the leading zeros.
This would also solve the problem of importing/exporting cells that look like they could be in Sci Notation; if it's in quotes, then it's text, period bottom line, and it shouldn't be treated as a number, not now, not ever.
Importing CSV's has always been a very weak point for Excel. It never get's it right. But I do understand why excel strips the leading zeros, because that's the normal convention for displaying numbers. But I too have been burned by Excel ALWAYS converting the data to numbers (if it looks like a number). A good start would be if Excel simply honored a Double-Quote as text and always text, even if the data looked like a number.
I've also been burned by Excel converting my data to Scientific notation. ie. importing "20E3" converts to Scientific Notation ==> 2.00E+03 . Come on MS, what's the deal with that. Do you really think I intended it to be Scientic Notation. Expecially if it's in a column with other text data like "20K3".
Best solution would be to ALWAYS popup an import dialog (when opening a CSV) and allow us to select the column format we want. And being that it starts as a CSV, break it down to it's constituent columns for us, not the normal column based import dialog. And while you're at it, let us apply/create a number display format for a column while we're importing it.
I'd also recommend the same dialog for exporting CSV's, so we can specify Double Quotes on a number column if desired.
2,642 votes654 comments · Excel for the web » Collaboration and Sharing · Flag idea as inappropriate… · Admin →
Thank you for your continued feedback and responses. We are glad to update that the work for this feature has started.
We’ll share more details as we progress.
@Roy, It's easy to use both the desktop and web versions. By default, SharePoint and Teams both open spreadsheets in a web version. You need to go out of your way to the files in the desktop app. If only there was a 3 way toggle that allowed you to pick from Always open in Desktop app, Always open in Web version, or System default.
I'm guessing that they're pushing it to Excel for the Web exactly because no one uses the Web version except as a last resort, so it'll affect the fewest number of users when it doesn't work right. (I'm an optimist, can't ya tell :) )
I'd expect that it'll eventually it will make it to the Desktop app. Hopefully sometime before I retire 20 years from now. :(
@Philippe, That all sounds great except that Excel for the Web is, well shall I say, not the best tool and any toolshed. It's only got about 5% of the functionality of full blown Excel.
Excel for the Web simply does not work for the co-authored spreadsheets we're using. And I have tried.
Need this functionality in the desktop app as @Todd Edwards said below.
Our team is currently using several shared spreadsheets. In general, the shared workbooks work well for our purposes. But we find ourselves yelling over the cubicle walls every time we want to change table filters. Kind of defeats the purpose of a shared spreadsheet.
Allowing personal filters would be greatly appreciated.
I see that MS says they have started working on this feature. But unfortunately they seem to have given up on staying actively engaged in the entire UserVoice forum. That's a great way for MS to lose the support and confidence of it's most skilled and knowledgeable user base. MS, It's time to re-engage with UserVoice. Don't alienate us.
440 votes45 comments · Excel for Windows (Desktop Application) » Collaboration and Sharing · Flag idea as inappropriate… · Admin →
Hello, we are working on this request for Excel Online – https://excel.uservoice.com/forums/274580-excel-online/suggestions/8192445-allow-for-personal-user-views-filters, more updates are coming later for Win32.
1,682 votes568 comments · Excel for Windows (Desktop Application) » Editing · Flag idea as inappropriate… · Admin →
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.
- Urmi [Msft]
@Roy, You're right on the mark... Double thumbs up to ya.
One of the main problems with the importing CSV files is that Excel does not follow all the rules of a proper CSV file import. CSV's are supposed to always treat quoted text as text. But even if you have a number in quotes, Excel will still treat it as a number, not text as desired. So as @Corin Dennison said, "01200E05827005" would still get imported as a "Scientific Notation" number.
In addition, a Text formatted column should always export to a CSV with Quotes, but Excel doesn't unless there are special characters embedded that require quotes, like a space character.
Opening CSV files never open the Text Import wizard because the file extension implies that it's columnar data. .TXT files, however can open with the Import Wizard depending on how you open it.
Bottom line is that the only way to have a long number imported w/o potentially translating it to Sci. Notat. is to have the data in a TXT file and use the File Import wizard to convert the number column to text.
This is less than ideal for sure. An option to not convert to Sci Notat would certainly help especially if other data in the column is not in Sci. Notat.
The real problem is not limited to importing text data. Lets say you're entering a 15 digit (all numeric) part numbers into a cell. Excel will automatically reformat you're part number into scientific notation. Why? It needs to stay as 15 digits. And sometimes, you might even want leading zeros retained.
@Anonymous, Let's see, what can we expect from a Monopoly.
Go to Jail
Go Directly to Jail
Do not pass Go
Do not collect $200
Sounds about right huh?
Why does that not surprise me!!! If MS wants to support CSV, they really ought to do it right. Thanks for trying.
Double Quotes in - Format as Text
Formatted as Text - Double Quotes out
Should be simple. Lets get it done.
If only Excel would save Text Formatted fields with double quotes around them in the CSV file (a csv standard), then the problem would be solved.
If only... sigh...
773 votes213 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →
Thanks to Graham for starting this conversation. If you would also like Excel to maintain named range references and structured table references in the “applies to” field for Conditional Formatting rules, please add your comments and vote this one up. We will prioritize accordingly.
Steve (MS Excel)
@Jan, you are right, there is a lot of shouting at deaf ears. Unfortunately the selectively deaf ears don't want to hear what we're saying. And it's not just this topic.
Is anyone aware of any recent MS response to any topic??? My guess is that MS has completely abandoned this forum. But they leave this out here to make us feel like they are listening. So sad that a perfectly good tool is going to waste.
I'm not trying to make excuses for MS here, but maybe they don't know how we want excel to work.
For example, when we copy a cell that is formatted using named ranges to another cell in a different column, in the same table, how should the formatting be copied? Should it make a new rule? Or should it abandon the source formatting and assume the formatting of the new destinations column. I'm for the later.
What about if you have a format spanning 2 or more columns and I want to insert a column in the middle, should it be excluded from the format, or should it assume the formatting of the columns it was inserted between. And what about moving a column with unique formatting between the two spanned columns? Once again, how should that be handled?
Let's give MS some ideas how to fix this existing disaster instead of just complaining about their lack of action.
I agree with you 100%. I think the difference with my previuos note and what you are describing is that I was applying the conditional formatting to columns in Formatted Tables; ie "Applies To:=Table1[Column1]". I'd guess that you weren't using Formatted Tables.
To me, a Formatted Table is any table where "Format as Table" was applied.
For a formatted table, the normal way of adding a new row by simply starting to type in a new row at the end of the table. All call formats and formulas will automatically be applied to the new row. Conditional Formatting will also get applied to the newly added row. Looking at the Cond Format rules will show that the "Applies to" range will be extended to include the new row.
But as you said, "copying" a cell to a new row will still make a mess. But when it did, the new rule it added was unnecessary.
Table1 = is C2:D11
Headers for Table1 are in Row 1
Col C ($C$2:$C$11) formatted for cell = 1
Col D ($D$2:$D$11) formatted for cell = 2
Copying C5 to C12 creates a new new row in the table. So the Cond Format for Col C (and Col D) changed to to $C$2:$C$12 (and $D$2:$D$12) in order to accomodate the new table row. But it also added a separate rule just for $C$12. The rule for $C$12 is not needed because the table range was extended. This left 3 format rules; 1) $C$21 2)$C$2:$C$12 3) $D$2:$D$12 . #1 is not needed because it overlaps with #2
I hope this makes sense.
I think whats happening is that because you're doing a copy / paste (not paste special values), it insists on copying the Cond Format too even though the format is exactly the same as table column format.
Bottom line is that this still makes a mess. MS needs to allow us to put "Applies To:=Table1[Column1]" w/o out converting it to a fixed range. And if the Cond Format matches the table columns format, then drop the Cond Format.
By the way, I do agree with you about paste-special-values. Thats just about the only way I ever paste data. It keeps the formatting rules neat. Unfortunately, a lot of the sheets I create get shared with others that don't understand the intricacies of conditional formats and how copy / paste can mess them up.
And I too am on O365 V 1804 Monthly Channel
@Sbasu, you are correct. MS does seem to have fixed some of it. It appears to be adjusting the "Applies To: range when you add / delete / move whole rows and columns. Or even if you copy/paste within a single "Applies To: range.
But alas, the problem still exists when you copy/paste data that crosses more than one "Applies To" range.
Create a table with a conditional format in Column A and different conditional format in column B. If you copy a single cell from a row in column A and paste into a different row but also in column A, it will work as desired without breaking up your rules.
However, if you copy row data from columns A:B and paste that in a different row, then your rules will get broken, even though the data always stays in the same columns. Same thing would happen if column B did not have any conditional formatting.
You could MOVE the whole row (shift drag row) without breaking the rule. But sometimes you only want to copy a few cells from a row, not move the whole row.
So in summary, your rules will get broken/split-up when you copy/paste and the data you are copying spans more than one conditional rule or non-conditional formatted range.
Clear as mud, right?
PS, I haven't tried the =OFFSET trick from @JOUKE
This is a major pain in the back end. Come on MS, it's time to get this fixed.
2,407 votes642 comments · Excel for Windows (Desktop Application) » Viewing / Navigating Workbooks · Flag idea as inappropriate… · Admin →
Thanks everyone for all of the passion about this suggestion! The number of votes has increased greatly in the last couple months and we’re taking notice! We’ve got a bunch of other Excel endpoints behaving this way already and we’re evaluating getting it done in the Windows versions sooner based on the number of votes it gets – so keep the votes coming!
Eric Patterson (Program Manager – MSFT)
@NegaEric - Well said.
Dr. MS, How about giving us a pain remedy.
@Thomas, I forgot to mention that with a laptop, you need to put it upside-down and stand on your head while working. That's what MS would want you to do. :D
All joking aside, yea I can see where there is a problem with my suggestion when you don't have a mouse.
@NegaEric. Basketball??? ROLF...…. You just made my day.
There is a less-than-ideal form of smooth scroll already built into Excel. Just click the Mouse Wheel button. You should see a 4-direction pointer appearing on the screen. Then moving the mouse will smooth scroll up, down, left and right. Unfortunately this is a poor implementation of smooth scrolling.
IMHO, Smooth scrolling should work like this:
1) If moving cursor by arrow keys and not editing a cell, scroll by cells.
2) If moving cursor by arrow keys and you are editing a cell, smooth scroll if needed.
3) If scrolling by mouse wheel, give option for one of 3 scroll options. Note, this option should have it's own icon so it can be added to the menu bars and changed on a whim. Don't hide it in the Excel Options section.
Scroll Option 1 - Always cell scroll (just like today)
Scroll Option 2 - Always smooth scroll
Scroll Option 3 - Hybrid - Cell scroll unless scrolling thru a large cells that wrap off the screen, Then smooth scroll till the large cells are no longer visible, then revert back to cell scrolling.
@NegaEric, Thanks. Still on for the Packers v Seahawks game in 2023? :D
My apologies to you for accusing you of being all the other artists too.
As an explanation for my position; I work for a business that constantly promotes careful communication. As part of that, we are taught to be aware of how others might perceive messages, emails, documents and the like. Doodles would certainly be included as a form of communication. Perception is everything. And while most people would not have any issues with the doodles, some might. Personally, I liked the doodles, but none the less, that is what our company teaches us to avoid.
I find it very disappointing that I come under personal attack from multiple people for simply pointing out that the doodles could offend some people. Very disappointing indeed.
To that point, this will be my last post in reference to the doodles or any future personal attacks on me. I am just saddened that we can't keep this thread professional and constructive. C’est la vie.
@Brent / Bill Gates / Patrick / Sundar (probably all the same person)
You may have intended satirical lighthearted comic relief from the daily stresses of our lives. But you also need to consider the hypersensitive society that we live in. In today’s world you can't just go expressing death wishes on people without the possibility that someone somewhere might just take you seriously. Now that person is not me. I understand your intent, and I know the doodles are just a form of stress relief. But I am saying that other people out there might not understand it the same way. We need to be a careful of what we say and how we say it.
And [Deleted User] is right, If we continue to just "Bash M$", they'll never pay attention to this suggestion. Maybe I'm being a "Debbie Downer" but lets try to get this back on topic. And lets stop bashing each other, that's not productive.
Oh yea, thanks for immortalizing me in your comics. I can't wait for the book. :D
Drawings of people killing Eric, or anyone - Not appropriate. If you're gonna do graphics, don't be so violent.
Want to catch a Packers vs Seahawks game? Oh yea, they don't play this year, bummer. But I'm sure they'll play each other before we get better scrolling. And Seattle's going down....
Just thought I'd start building our community. LOL
It's pretty clear that MS has given up on reading the entire Excel UserVoice forum. I follow numerous highly voted topics and every one of them say the same thing; that MS isn't listening to the UserVoice. I'm sure everyone here can agree with that.
On the bright side, it gives us a place to vent... :)
@Roy, They manage to get IE and Word and numerous other software to do a reasonably smooth scroll. Why not Excel. Laziness I presume. Or perhaps ignorance and selective blindness toward of how people actually use Excel.
65 votes14 comments · Excel for Windows (Desktop Application) » Editing · Flag idea as inappropriate… · Admin →
1,008 votes111 comments · Excel for Windows (Desktop Application) » Charting, Mapping and Visualizations · Flag idea as inappropriate… · Admin →
Thanks for this suggestion! We are evaluating this for a possible future release. Please continue to vote on this idea.
24 votes3 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
Unfortunately MS is no longer actively developing VBA. It is as far along as it will ever get. The Excel libraries will probably be updated as new features are added to Excel, but I don't expect to see any further enhancements to the VBA IDE itself. Fortunately, MS has no plans to discontinue VBA either. There are too many millions of lines of customer VBA code written for MS to just kill it. Killing VBA would probably be the death of Excel. Here's a short little writeup written by a MS Excel MVP that explains the future of VBA.
On a positive note, I have also read that MS is planning on replacing VBA with something a little more robust. Perhaps, and this is just a wish list item for me, MS will integrate VBA like development into Visual Studio, which is capable of supporting many different languages, including 3rd party languages. Just imagine the possibilities if you could pick the language you wanted to write your macro in.
I'm keeping my fingers crossed for a more robust environment than VBA provides.
1,176 votes908 comments · Excel for Windows (Desktop Application) » Viewing / Navigating Workbooks · Flag idea as inappropriate… · Admin →
Thanks for all of the votes – the team has definitely taken notice of the activity around this issue. We moved to SDI as a result of customer requests, but it looks like we’ve got work to do to really nail the use cases people care about. From a read over the comments, I see a number of cases that we will want to investigate further as we think through MDI vs SDI. We’ll get someone from the team to take a deeper look, and we may reach out to some of you for more clarification as we go. Thanks again for all the voting and passion here!
I didn't mean to hijack this thread to be a VBA discussion, so this will be my last post in this thread about VBA. But I did want to clarify a little.
VBA is simply the programming environment and it's associated language. VBA is the look and feel of the VBA IDE as well as the core language components of VB (IF-then-else, Do While, Case, etc.).
But VBA is NOT "Activecell.select" or "Selection.Cut". Those belong to Excel Libraries which are automatically added into your VBA project. This is what allows VBA to talk to Excel.
MS never said it will discontinue development of these Excel Libraries. In fact these libraries are probably exactly the same libraries that Excel itself uses to do virtually everything. If MS stops developing these libraries, then all changes (good, bad, or indifferent) to Excel would also stop.
So what I'm trying to say is that the VBA IDE and core VB language may no longer change, but the functionality within a VBA macro will continue to change and grow as Excel (and its libraries) change. This should include new MDI functionality (if we ever get that back) because Excel itself will be using the same libraries as VBA does.
Roy, I know what you're saying about using VBA to connect to other office apps. It's a major pain in the back end. But I've done it multiple time. I've used Excel VBA to pull data from Access databases based on user entry. I've even done that to MS SQL Server databases. I have also created macros that save the current worksheet (tab) to it's own separate workbook and then attached that workbook to an Outlook email and automatically sent it. All invisible to the user. And I've seen many other examples of people doing similar things.
So while it might be a PITA to accomplish inter-application functionality, I wouldn't rule that out as something thats never being done.
There, no move VBA discussion for me, at least not in this thread.
IMHO the real reason MS killed MDI, is for security / stability reasons (actual stability improvement is debatable). Anyway, one bad acting spreadsheet or VBA module gone awry was able to lock up or bring down all spreadsheets running under a single Excel MDI instance. I believe their intent was to prevent one spreadsheet from crashing them all and losing their associated changes. But in todays day, improved containerization of code and data should easily allow MS to fix the original problem, thus allowing them to bring back MDI. This is basically the same way bad acting web pages no longer bring down the whole browser, but rather just the bad page.
Mats Samuelsson, regarding Visual Studio, it is not a replacement for VBA, nor is VBA a replacement for Visual Studio. They are completely distinct entities with very little overlap except for the "Visual Basic" part of the name. One cannot create a simple VBA macro using Visual Studio, nor can one write code for an Arduino using VBA.
For those interested in the history, VBA is based on ancient Visual Basic 6. VB6 was discontinued 20 years ago. Visual Studio continued to advance VB.net into a very modern language today, but it's almost completely incompatible with old VB6 code. And with VBA being a derivation of VB6, there is almost no crossover available. Fortunately MS has no intention of dropping VBA because of the countless lines of code written in it.
Richard Laycock and Anonymous, there is no reason to accuse Daniel of not knowing how to use Excel. He has his preference just as you have yours. He simply doesn't want SDI to go away. I'm certain he'd be OK with being given a choice between SDI and MDI, just as you are.
Thanks Roy. I'm still stuck back at Version 1902 (Build 11328.20158). I'll need to wait for corporate to push the change to my PC. So it must be new functionality in 1903.
Roy, Thanks for the info. What Version / Build do you have. I don't seem to have this change yet. Thanks.
5 votes0 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →
3 votes0 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →
3 votes0 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →
7 votes2 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →
Under the Date Category (in number formatting) , there is already a mm/dd/yyyy hh:mm PM format which might work for you instead of creating a custom format. Same in the Time category.
57 votes11 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →
519 votes82 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →
Ditto on Lubomír Tosek's comment. Lets see Left Across Selection and Right Across Selection too. And add vertical across selections too.
42 votes4 comments · Excel for Windows (Desktop Application) » Formatting · Flag idea as inappropriate… · Admin →