Welcome to MSDN Blogs Sign in | Join | Help

Microsoft Excel

The team blog for Microsoft Excel and Excel Services.
Tables Part 3: Using Formulas with Tables

One of our goals with tables was to create a set of features that reduce the overall maintenance required to keep a spreadsheet functioning well over time.  This involves making spreadsheets less prone to error, as well as making them more understandable days, months, and years after the spreadsheet was created.  Rethinking the interaction between tables and formulas proved to be an important part of meeting that goal.

As many readers have presaged, Excel 12 provides some new ways to reference tables and parts of tables.  We refer to our work in this area as “structured referencing” (that is a working title, so it may be called something else when we ship the product).  In a nutshell, the structured referencing feature allows you to reference a table and/or subsets of the table directly by name as opposed to by cell coordinates.  The feature is similar in concept to named ranges with a few crucial differences.  First, the names that can be referenced are automatically generated when the table is created.  Specifically, this includes the name of the table itself (which by default is something like “Table1”), and the names of all the columns.  Also, the names are automatically removed as columns are deleted or the entire table is deleted.  Finally, and perhaps most importantly, the names automatically adjust as the table grows and shrinks.  As a result, the majority of the headaches of maintaining named ranges go away with structured referencing.

So how is all this manifested in the product?  Structured referencing represents an addition to the syntax for formulas in Excel.  Here are the basics of how it works.

  • A reference to a table looks like this: =Table1, so if you wanted to sum the values in a table, you could use =SUM(Table1).  Note that =Table1 returns all of the data in Table1 without the headers – this is because many of the common functions that work on ranges, like VLOOKUP, assume no headers. 
  • A reference to a column looks like this: =Table1[Column1].  Again, this reference returns just the data.  So, for example, if you wanted to SUM a column, you could type =SUM(Sales[2004]).


(Click to enlarge)

There’s more to the syntax than that, but first I want to talk about something I personally love – integration between structured referencing and Formula AutoComplete.  The Formula AutoComplete feature I talked about a week ago is fully integrated with structured references – meaning Formula AutoComplete for tables names as well as columns within tables is possible.  For example, here is what it would look like to build the structured reference pictured above.  First, let’s start with just a table.


(Click to enlarge)

Next, I type “=SUM(S”.  You will note this lists everything starting with “S” in the Formula AutoComplete drop-down, including formulas, named ranges, and my table, “Sales”.


(Click to enlarge)

After I select my table “Sales”, I can now see all the columns in the table.


(Click to enlarge)

And with a single click or keystroke, Excel 12 completes the reference.


(Click to enlarge)

All I need to do is close the parenthesis and press enter and I am done.  We believe this will improve accuracy and efficiency.

Structured references can be used inside tables as well, and here Excel has even more new behaviors.  Say I’m looking at some sales figures and I want to calculate the percentage change in sales over the last few years for each row in my table.  My table looks something like the screenshot below.


(Click to enlarge)

The formula I want is something like: =(FY05-FY02)/FY05.  The first thing I want to do is add a column, so I start typing “Percent Growth” after the last column in my table.


(Click to enlarge)

When I press enter to commit the change, Excel adds another column to my table – the appropriate formatting is applied to the rows, the border around the table adjusts, etc.  So far so good.


(Click to enlarge)

The next step is to write the formula.  I might do something like type "=(" and then use the keyboard to move selection over to the cell I want to calculate – in this case FY05.  Excel gives me the following reference: [FY05].


(Click to enlarge)

As you can see, when referencing a table from within the table itself it is not necessary to prefix the table name.  As I use other columns in my formula, they get similar references.


(Click to enlarge)

When I am finished with my formula and press ENTER, Excel automatically fills that formula down for all rows in the Percent Growth column. 


(Click to enlarge)

This is another new feature of tables called calculated columns.  Any time a formula is entered into an empty table column it will automatically fill.  We think this will help reduce errors introduced by manual filling or copy/paste.  Not only does it fill, but it continues to fill down as you add or delete rows in the table.  This is another one of those “sticky” properties I mentioned in my previous post.  As with other table features, the user does have control over its behavior – at the time you enter a formula in a cell in a calculated column, the auto-fill can be undone using on-object UI (which you can see in the previous screen shot).  Further, if you really do not want columns filling down ever, the feature itself can be turned off.

If the calculated column ever needs to be updated, it is only necessary to edit one copy of the formula and the change will propagate to all rows.  In addition, it is possible to change any single row (e.g. enter a static value or custom formula) so that it is not consistent with the calculated column.  Such cells will be flagged visually so that inconsistencies will be easy to spot.  For example, if I enter =RAND() in the middle of my column and choose not to fill down, I see a green triangle in the upper left-hand corner of the cell.


(Click to enlarge)

Furthermore, once a calculated column contains inconsistencies, subsequent edits to cells in the calculated column do not propagate because Excel does not want to overwrite custom values.  However, the same UI shown above will appear allowing the user to opt-in to the behavior.

The last feature I want to talk about is the table totals row.  (For those that use Excel 2003 Lists, you will recognize the totals row, but we have made some nifty improvements since 2003, so please read on.)  The totals row is another special area of the table, like the header row.  It lives at the bottom of the table and its purpose is to calculate totals for the columns in a table.


(Click to enlarge)

The total row can be enabled via the table tab in the ribbon, right-click on the table, or by using the existing AutoSum functionality.  The nice thing about having a special area for totals in the table is that it participates in the table’s activities.  It grows and shrinks properly with the table, it gets special “total row” formatting when you apply a style to the table (more on table styles in a later post), and the formatting behaves appropriately as more columns are added to the table.

The total row cells can contain pretty much any kind of formula (the formulas don’t have to reference the table at all but we don’t expect that to be the common case) as well as text labels.  The cells in the totals row also contain a dropdown that shows you some of the most commonly used functions, lowering the bar for the new Excel user to write formulas. 


(Click to enlarge)

The total row can be toggled on and off, and any functions that exist in the total row will be “remembered” until the next time you turn it back on.

So now let’s finish our discussion of syntax, since some of you are probably asking questions like “how do I reference the entire table, headers and all?”  Referencing the entire table can be done this way: =Table1[#All].  Or if you just want to reference the headers: =Table1[#Headers].  To reference the entire column: =Table1[[#All], [Column1]].  To reference just the header value of a column: =Table1[[#Headers], [Column1]].  The special keywords can also be combined: =Table1[[#Headers],[#Data],[Column1]].  At this point I think you get the idea. 

Some other points about structured references: table names are globally unique to a workbook and do not require a sheet reference like Sheet1!Table1.  Table column names must be unique within the table itself.  Table names co-exist in the same namespace as named ranges, meaning you can’t have a defined name with the same name as a table, and vice-versa.  If the table name or any of the column names change then any formulas that reference those names will automatically update as well.  Structured references can be created using selection with the mouse (and yes, there is an option to turn this off).  In fact, structured selection (I talked about it in my last post) is one way to very quickly generate structured references when writing formulas. 

That’s it for now.  For my next post I will delve into the work we’ve done around the area of autofilter.  Multi-select anyone?

Posted: Friday, October 28, 2005 10:25 PM by David Gainer
Filed under:

Comments

Rob van Gelder said:

David,

I would likely upgrade for this feature alone.

A big "well-done" to the Excel team!


A few questions:

1. When a new row is appended to the Table and formulas/formatting is copied down, is data validation also copied down?
On that topic:
1a. Has the Data Validation dropdown had any work in Excel 12?

2. Is it possible to have the column reference dynamic?
By that I mean to sum Table1's 2004 data and A1 contains 4
=SUM(Table1[2000 + A1])
Is that possible?

3. Is it possible to detect (by formula) whether a Table's formula column is in a non-consistent state? eg. Someone put =RAND() in the middle cell! :)
I'd allow overwriting formulas but in some situations a non-consistent formula column is dangerous - usually when a user forgets to replace the original formula once their "exceptional problem" is dealt with.
I'd like the option of more highlighting (eg. a VERY BIG Red cell) than just the little green triangle.
# October 29, 2005 2:39 AM

Hazz said:

This sounds great! This WILL reduce the user support required for inconsistent formulas, and newbie’s trying to use formulas with tabular data. In short it should reduce the time I spend helping Excel users by about two thirds, so I can spend more of my time on more productive tasks. It means that a newbie will be able to do (with dynamic ranges) what it currently takes an expert to do with defined names and offset formulas and so on.

Questions.

Where is the table name specified? In screenshot one the table name is Sales, but the name does not appear on the canvas, and the screenshot of the create table dialog from you blog 25 Oct. does not have a place to specify the table name. Oh wait, I’ve spotted it in the Table Tools/Properties Chunk in the new UI (5th screenshot in your 25 Oct. post on Tables Part 1). Could it also be included in the create table dialog?

Can the table name be referenced by a formula? For example in the first screenshot the name of the table is Sales but it is not exposed on the canvas. Could I put a formula in say, cell B3 something like (using .NET paradigm) =Sales.toString, or = Sales.name or Sales[name] or some such and have the name of the table appear. This would help with table names on the canvas actually matching the tables 'structured reference' name and staying that way if it is changed.

Is there a way in structured reference formulas to control whether the formula will return the complete sum of a column or only the sum of the visible rows when the table is filtered? (I have read all of your posts but not every comment from every post so this may have already come up). If so then a conditional format based on a formula that compared the cell value to the complete column sum could be used to highlight values that are/aren't the full set.

In rows other than the summary row will formulas auto fill the row like they do for columns? I’m thinking of subtotals here (but not particularly grouped by some value in a given column, so that the automatic subtotals feature can’t be used). For example a balance sheet, where columns A contains the line items for the sheet and you want subtotals for the Fixed assets, Current assets, Total Assets but you cannot subtotal by Column A ‘cause the Fixed assets are line items like ‘Land’, ‘Buildings’, ‘Plant’ etc. (and using a hidden column with grouping values is a kludge!)

Finally, not related to the current topic, is there a gallery table format that alternates row shading by 2, 3, 4 or 5 rows at a time. Or will this still require some (easy to be sure) custom conditional formatting? Alternate row shading is great on small table, but once the table goes over about 12 rows, blocking the alternate shading by groups of 3, 4 or 5 rows improves readability, especially when the report/table is printed. We use this type of shading very frequently at work (probably by 3’s the most, but I’m partial to 4’s for larger data sets!!!).

Thanks for the great post and screenshots, but even more thanks for the excellent work the Excel dev team is doing. I can’t wait for 12!

Mmmm… multiselect autofilter mmmmm!

Hazz
Business Analyst.
# October 29, 2005 3:35 AM

Charles Williams said:

David,
that looks like the biggest single advance in Excel in the last 10 years.
Cant wait to get my hands on it to try out all the wrinkles.

Have you made any extensions to row referencing?

Charles
# October 29, 2005 4:11 AM

Jean-Marc Decouleur said:

David,

Awesome! This is really great work.

I second Charles' question: what about row referecing?

Jean-Marc
# October 29, 2005 8:00 AM

SteveA said:

Never sure where to post off topic ideas. Forgive me

With the dramatic increase in columns and rows, and now proper cell colouring rather than just index colours, I could imagine some quite beautiful pictures appearing if you can zoom out far enough (ie really small percentages).

So who will be the first person to write a macro to read jpegs in with each cell representing 1 pixel.

# October 29, 2005 9:35 AM

Orion Adrian said:

A few questions? Is Excel in charge of the List portion of SharePoint? If not, who can I direct my questions on SharePoint to?

Now a few points:
1) I am loving all the new advancements, but it still beings up my question about the differences between Excel and Access, though I have no particular need to see them kept separate.

2) Can we get some subtle changes to VLookup or a new function that will work with tables more efficiently? Like:
=VLOOKUP("My Value", Table1, Column1, 0)

Currently, where Column1 is you have to put an index, but that's hardly fun. And if you really want to impress, make it so "My Value" is a simple query.

3) And, lastly, if you do introduce datatypes don't introduce things like 64-bit int or float versus double. Don't make people think about stuff like that since we know Excel can handle that all by itself.

Again what would be cool is when I type in a date in a table column, it would make that cell a date picker and copy that datatype to all the lower cells, making them date pickers too. You would of course have to add a smart tag, or whatever you're calling them these days, for undoing the action.
# October 29, 2005 10:52 AM

Orion Adrian said:

Just had another thought after re-reading row referencing.

What would be better than explicit row referencing in my mind is row referencing based on criteria. That's what people are really looking for anyway. Something that would return the highest profitability. VLookup for rows essentially.
# October 29, 2005 10:56 AM

Orion Adrian said:

What would a running total or any other formula that looks at other rows look like in this system? I take it, it would still use cell references.
# October 29, 2005 12:31 PM

Jean Martineau said:

Right on David. Table concept is going to help everybody using Excel.

|When I am finished with my formula and press
|ENTER, Excel automatically fills that formula
|down for all rows
That is exactly what I wanted when I was speaking about "Header Formula".

Will it be possible to have more than one Table totals row ? This is practical if you want Total and Average and ... at the same time.

|More Functions... (for the Table totals row)
Will these include Median, Percentile,...

I am also interesting to have more details on Orion point 2), especially is "My Value" argument. Right now, if I have more than one column as key fields of my "table" (let saw [Product] and [Region]), I typically create a calculated column ([Link] = [Product]&[Region]). When I am referencing to get a value from that "table", I use [Link] to find the right row. I would not have to do all this if "My Value" could be define as ([Product]="ProductValue", [Region]="RegionValue").

Looking forward to read on autofilter,

Jean
# October 29, 2005 1:43 PM

Harlan Grove said:

This should be useful.

Finally a new bit of formula syntax. The example showing how to sum a column is helpful. How do you sum a row? Given the sample table in the screen images, how would one sum sales in all years for each product? Presumably

=[2001]+[2002]+[2003]+[2004]+[2005]

would work, but hard to see what would happen when the user adds 2006 as a new column in the table.

My point here is that SQL.REQUEST run against a dynamic named range as a database table would provide the same functionality as XL12 tables with respect to formulas, though perhaps not as simply for most users.

Now I'll give you the benefit of the doubt and anticipate that your next posting will show us that you've included intelligent multiple row and multiple column referencing syntax like

=SUM([2001]:[2005]) [inside the table]

=SUM(Sales[2001]:Sales[2005]) [outside the table]

to give the same result as the previous formula. If table references resolve to range references, this should be the case since : is an operator on ranges that returns the smallest single area range containing all its operand ranges (e.g., (A1:B8):(C6:F6) resolves to A1:F8). So, will table references resolve to range references?

Next, additions to the name space: #All, #Data, #Headers. High time. If only there were new #Missing or #Blank tokens to represent the same value as blank cells (which appears to be the same value as VBA's variant value Empty), but they'd require that Excel propogate such values. Anyway, if [#All] gives the same result as [#Headers],[#Data], what's the point of allowing [#Headers],[#Data] if these are the only new keywords since [#All] plus either or both of the other two would be pointless. Which begs the question whether there are other new #-tokens.

One operation outside tables that would be natural against tables is VLOOKUP. Given the sample table, would

=VLOOKUP("Product10",Sales,[2005],FALSE)

or

=VLOOKUP("Product10",Sales,Sales[2005],FALSE)

or even

=VLOOKUP("Product10",Sales,COLUMN(Sales[2005]),FALSE)

do the right thing? If not, then it's time to add a 4th argument to LOOKUP similar to the 4th argument to VLOOKUP so that

=LOOKUP("Product10",Sales[Product],Sales[2005],FALSE)

returns the expected result.

With regard to COLUMN(Sales[2005]), would that return the column number relative to the table or relative to the worksheet? Actually, if Sales[2005] returns a range reference, then it'd seem it must return the column index relative to the worksheet.

If table references return range references, will INDIRECT be able to generate dynamic table references? For example, if the defined name YR referred to 2004, would

INDIRECT("Sales["&YR&"]")

be interchangeable with

Sales[2004]

(net of function nesting and formula length limits)?
# October 29, 2005 2:14 PM

Harlan Grove said:

Jean Martineau...
...
| . . . Right now, if I have more than one
|column as key fields of my "table" (let saw
|[Product] and [Region]), I typically create a
|calculated column ([Link]=[Product]&[Region]).
|When I am referencing to get a value from that
|"table", I use [Link] to find the right row. I
|would not have to do all this if "My Value"
|could be define as ([Product]="ProductValue",
|[Region]="RegionValue").

Which would get us most of the way towards Lotus 123's @DSUM's criteria expressions. Note that if all you're doing is summing, counting or averaging fields in tables with multiple criteria, the new SUMIFS, COUNTIFS and AVERAGEIFs functions will handle this, so

=SUMIFS(Sales[2005],Sales[Product],Prod,Sales[Region],Reg)

should return total sales in 2005 for product Prod in region Reg. But that begs the question how to produce the same conditional sum for the range of years 2001 through 2005. The formula

=SUMIFS(Sales[2001],Sales[Product],Prod,Sales[Region],Reg)
+SUMIFS(Sales[2002],Sales[Product],Prod,Sales[Region],Reg)
+SUMIFS(Sales[2003],Sales[Product],Prod,Sales[Region],Reg)
+SUMIFS(Sales[2004],Sales[Product],Prod,Sales[Region],Reg)
+SUMIFS(Sales[2005],Sales[Product],Prod,Sales[Region],Reg)

is one way, which hopefully could be condensed to

=SUMPRODUCT(SUMIFS(INDIRECT("Sales["&{2001,2002,2003,2004,2005}&"]"),Sales[Product],Prod,Sales[Region],Reg))

but it'd be very nice indeed if there were new useful new syntax like

=SUMIFS(Sales[2001]:Sales[2005],Sales[Product],Prod,Sales[Region],Reg)

This leads to obvious questions about interaction between tables and pivot tables: can tables feed pivot tables, and can pivot tables be defined as tables (presumably under the restriction that there be only one header row)? Then data in pivot tables could be referenced like XL12 tables.
# October 29, 2005 2:35 PM

Harlan Grove said:

Will tables work in external references into closed files? That is, if C:\foo\bar.xls contains MyTable which in turn contains the column MyField, will

=SUM('C:\foo\bar.xls'!MyTable[MyField])

return the expected result?

Further, dynamic referencing into closed workbooks is, to put it as charitably as possible, a PITA in Excel. I came up with a udf that uses another Excel application instance that calls ExecuteExcel4Macro with a derived external reference to return values from closed workbooks, but I suspect y'all ain't gonna rewrite ExecuteExcel4Macro to accomodate XL12 table references (believe me, I'd **VERY** **MUCH** like to be wrong about this).

So if the formula above does work, I'd need to rewrite my udf to do the following in the other Excel application instance: open a new worksheet, enter the derived external reference formula into a range, return that range's resulting .Value property to the calling formula. I'd also need to run the isolated pathname through VBA's Dir function to check whether or not it exists. If the file exists but the table doesn't, would

rngref.FormulaArray("='d:\foo\bar.xls'!MyTable[Myfield]")

return a useful #REF! error, or would it trigger a runtime error because XL12 wouldn't accept the formula? That begs the question how XL12 works interactively when tokens resembling table references are used in formulas, but there's either no such table or no such field within the table matching the reference in the formula. #REF! error or syntactically invalid?
# October 29, 2005 3:04 PM

Jean Martineau said:

My point was for returning a single VALUE, but Harlan's point
|=SUMIFS(Sales[2001]:Sales[2005],...
is also interesting

Jean
# October 29, 2005 5:40 PM

Murray Shactman said:

Thank you for these new features.

Will I be able to import the TABLE data to a Pivot Table?

# October 30, 2005 1:06 AM

Charles Williams said:

David,

is there a #Totals keyword, or how do you reference the Totals row from outside the table?
# October 30, 2005 7:01 PM

Mpemba said:

RE: Excel Art - Whimsical thought
So who will be the first person to write a macro to read jpegs in with each cell representing 1 pixel.


It's already been done with only 256 columns.
With the new Excel though we can do some serious image analysis - a competitor for PhotoShop?


I've got the link somewhere for jpegs: this one works for BMPs.
http://www.andypope.info/fun/bmpconvert.htm


M
# October 31, 2005 3:00 AM

Tianwei said:

I'd take Multi-select anytime! Thanks for the wonderful work!

Quick Q on stucture naming. How does Excel determin the height of the table if there are missing values (blank cells) scattered around the column? This is the biggest problem in the past when using COUNTA($A:$A)-1 methods. Same question applies to auto fill formula...
# October 31, 2005 10:14 AM

Anonymous said:

Will this all be backwards compatible? What if I create a spreadsheet full of table references and names rather than the current sytem of the alphanumeric cell references, and then share it with a client who's not yet running Excel 12? Can they get the formulas to work? Can they make changes? When they send the file back to me, will it work seamlessly?
# October 31, 2005 11:42 AM

David Gainer said:

Salutations … thanks for the comments; let me try and answer some of the questions posed.

Rob – Yes, data validation is copied down (any ‘property’ you can set on a cell is). No, data validation hasn’t changed. What specifically are you looking for? Dynamic referencing like Table[2000+A1] or even Table[A1] is not supported. There is no new facility to tell by formula to tell if a column is in a non-consistent state, but that is an interesting idea.

Hazz – Table name is on the dialog. Thanks for the feedback on the create table dialog. Currently, you can’t reference a table by name, but that is good feedback. Yes, you can use different arguments in SUBTOTAL to determine whether to include visible rows or not. I am not sure I understand your question about formulas filling in rows like they do for columns, but I think you will be able to do what you suggest. The auto-fill behaivour, though, is only for rows. Yes, you can have alternate by shading more than one row at a time.

Charles, Jean Marc, Orion – The only row referencing available is a [#This Row] tag, which allows you to scope a function to a specific row in a table, mainly for the purposes of implicit intersection. Will try and get in an example this week.

Orion – There is a SharePoint blog. http://blogs.msdn.com/pjhough/. VLOOKUP will accept structured references in the first two arguments but not the “index” in Excel 12 – we would need a new function to enable what you typed above, since the “index” argument expects an integer, not a reference. Thanks for the feedback on datatypes.

Jean – Just one Total Row (and Header Row) at the current time, though have heard the question before. You can type any function into the total row, so yes MEDIAN and PERCENTILE will work just fine.

Harlan – Yes, structured references do evaluate to range references, so [2001]:[2005] will work. Table[[2001]:[2005]] also works. No [#Missing] or [#Blank], this time out, but great ideas. [#All] is different from [#Headers],[#Data] because [#All] includes the totals row. Totals rows are indicated by [#Totals]. No structured reference can have [#Headers] and [#Totals] in it, so [#All] is the only way to get the entire table. See VLOOKUP comment above. INDIRECT will work with structured references. PivotTables can indeed be fed by tables – you may have noticed the UI in the Table Ribbon that said “Summarize With Pivot”. No, PivotTables cannot be defined as tables – as you could imagine, you would need a much richer referencing scheme to handle multiple dimensions and hierarchy. Structured references into closed files will calc to an error value if you attempt to refresh – much like GETPIVOTDATA does in Excel 2003.

Murray - PivotTables can indeed be fed by tables – you may have noticed the UI in the Table Ribbon that said “Summarize With Pivot”.

Charles – There is a [#Totals] keyword, correct.

Tianwei – The difference between a table and Excel’s existing logic to try and determine table height is that the user declares the region that makes up the table, and from then forward rows and columns added by the user (whether manually by the user or automatically through things like query table refresh) are always included in the table unless the user decides not to. Accordingly, there is no determination to be made, since the user has identified the range.
# October 31, 2005 4:56 PM

Harlan Grove said:

For Tianwei,

David confirmed in a response under a different topic that INDEX(Table,ROWS(Table),COLUMNS(Table)) would resolve to the bottom-right cell in the table named Table. That so, ROWS(Table[#All]) should presumably return the height of the table.

Another question. If table size can change automatically upon, e.g., query table refresh, would pivot tables fed from automatically refreshed tables also refresh automatically or will user inteaction still be needed?
# October 31, 2005 5:27 PM

David Gainer said:

Anonymous - Backwards compat of features is a topic that will require a few posts to talk through properly.
# October 31, 2005 5:28 PM

David Gainer said:

Harlan - the PivotTable does not auto-refresh, so user interaction will still be needed. Curious - would you like that sort of "auto" refresh behaviour?
# October 31, 2005 5:43 PM

Harlan Grove said:

David Gainer...
| . . . the PivotTable does not auto-refresh, so
|user interaction will still be needed. Curious -
|would you like that sort of "auto" refresh
|behaviour?

Automatic recalculation is the key distinguishing feature of spreadsheets vs functional programming languages and databases. Anything in spreadsheets that fails to provide automatic recalculation is generally BAD. That includes pivot tables.

I understand why it'd be a bad idea refreshing pivot tables from outside sources, like databases, but on modern hardware refreshing pivot tables based on worksheet ranges shouldn't much worse than recalculating complex formulas that return the same results. So, yes, automaticly refreshing pivot tables based on worksheet ranges would be a GOOD thing.
# October 31, 2005 6:27 PM

Jan Karel Pieterse said:

Harlan, David,

I agree with Harlan on the automatic refresh, with a sidenote:

Why not include an option in the Pivot table options: "Refresh Pivot on recalc".
# November 1, 2005 9:10 AM

Tianwei said:

David Gainer,

"Rob – Yes, data validation is copied down (any ‘property’ you can set on a cell is). No, data validation hasn’t changed. What specifically are you looking for? "

Not trying to answer for Rob. I do have a few requests on validation:

1. Make "List" reference not just on current sheet (I'm still using v2000, not sure about subsequent versions)

2. Add a "Like" option, then a box to specify the format "YR*" or "###-##-####", or a rule dialog box to specify user input must contain "@", "http://" etc.

3. Provide another tab on "auto-scrubbing" feature, such as auto converting to upper case, formatting to a specified format (SSN, phone number etc based on numbers only input)

Since Excel now hosts 1mm rows, I can see Excel more and more used as a pseudo database (DBAs will freak out but I can tell you that will be the realty), more robust data validation is very important.
# November 1, 2005 9:35 AM

Harlan Grove said:

Tianwei...
...
|1. Make "List" reference not just on current
|sheet (I'm still using v2000, not sure about
|subsequent versions)

Define a name for the list, and use the defined name as the source for the drop-down. This works in XL10 (2002) and (I believe) previous versions that provide Data Validation.

This seems to prove that there's no semantic reason why data validation drop down lists can't use ranges anywhere in any open workbook. (Just like there appears to be no semantic reason for the 7 nested function call limit in current versions.) It looks like another shortsighted syntactic restriction serving no clear purpose.

|2. Add a "Like" option, then a box to specify
|the format "YR*" or "###-##-####", or a rule
|dialog box to specify user input must contain
|"@", "http://" etc.

And if Excel would ever provide a LIKE worksheet function (or regular expression support in SEARCH, as OpenOffice optionally provides in its SEARCH function in Calc), then it'd be possible to write data validation formulas using such new functions that would be able to check almost any text pattern that could be defined in prose.

|3. Provide another tab on "auto-scrubbing"
|feature, such as auto converting to upper
|case, formatting to a specified format (SSN,
|phone number etc based on numbers only input)

Adding ever more complexity in the dialogs. Formula (that nasty word!) filters could be added to convert entries (other than formulas) into some specified format. E.g., converting entries to upper case,

=UPPER(#Entry)

converting to standard US SSN format,

=TEXT(--SUBSTITUTE(SUBSTITUTE(#Entry," ",""),"-",""),"000\-00\-0000")

The former should be simple enough for most users to figure out.

Data entry masks that filtered entries and put them into the given format would be OK too, but not as powerful.
# November 1, 2005 1:03 PM

Tianwei said:

Harlan,

- List reference names does not work for XL2000. Good to know it works for XL2002. So I guess it will carry through 12.

- LIKE function will be highly useful. My examples are only a small faction of the wish list I have accumulated

- The auto-scrubbing function I suggested is not to limit users but rather seemlessly convert user inputs without giving annoying error messages all the time. Think of an application using a designed sheet as input source for high-school level temps. They need to input things quickly, not messing with any formula. Also again, my examples is only a small fraction of the wish list. How about auto-triming spaces? auto-add fixed strings to input (and into any position of the input)? auto-deleting any characters? auto-set hi-lo limits for numerics? auto-calculation based on certain formula (a/s/m/d, sqrt, or whatever)? In total, I hope data validation should be more of an "enabler" than just a "disabler".
# November 1, 2005 1:57 PM

Rob van Gelder said:

For Data Validation that uses criteria from a List, I'd like to see an autocomplete feature.

The feature doesn't even need to be a part of Data Validation - it just might be a convenient place to put it.

The standard in-cell autocomplete (Options: Enable AutoComplete for cell values) doesn't always activate so that's why I'd like an autocomplete on Data Validations.


On Data Validation:

I'd like the width and height of the dropdown box to be configurable.


Cheers,
Rob
# November 1, 2005 2:50 PM

Colin Banfield said:

<<On Data Validation:

I'd like the width and height of the dropdown box to be configurable. >>

Since we're opening up data validation here, the one modification I'd like to see is logic included to prevent data validation from being completely defeated by pasting data into cells with data validation rules.

Now back to your scheduled program....

Colin
# November 1, 2005 4:56 PM

Harlan Grove said:

Colin Banfield...
...
|Since we're opening up data validation here,
|the one modification I'd like to see is logic
|included to prevent data validation from
|being completely defeated by pasting data
|into cells with data validation rules.

Let's take that a bit further. Data Validation would be a LOT more useful if it were part of the recalculation infrastructure. Users can also enter formulas which initially return valid values but later return invalid values. It'd be very useful if Excel would return a new error value, #INVALID!, in such situations. Even better if #INVALID! errors couldn't be trapped by IFERROR.

[Which gets back to IFERROR and selectively trapping error values. IMO, there are three classes of error: the expected errors #N/A, #VALUE!, #NUM!, #DIV/0!, the ambiguous error #REF! and the unexpected errors #NULL! and #NAME?. The first set are often returned by built-in functions in fairly unexceptional circumstances (lookup value not found, substring not found in longer string, square root of a negative number, average of a range containing no numbers). #REF! could be returned by INDEX, INDIRECT or OFFSET passed invalid parameters (begging the question whether #VALUE! would have been more appropriate), but could also indicate model corruption (destroyed references). The last set almost always indicate model corruption or incompleteness. I can't see any good reason ever to trap #NULL! or #NAME? errors.]

Back to the issue of pasting, it does seem odd that Data Validation isn't triggered by all the actions that would trigger the Change event handler.

I suspect that back in XL8 (97) someone foresaw that pasting in large amounts of data into multiple cells at once would require a design decision about whether to handle Data validation rules separately in all affected cells (which could take a LONG TIME if lots of cells were affected), prompt to paste without applying rules or cancel pasting (something like issuing a warning and prompt like 'The destination range contains cells with Data Validation rules. Those rules can't be processed all at the same time. Proceed without applying those rules or abort the operation?' but that was before Microsoft came to believe that the user should be in control), or just ignore the rules in silence. So guess which one Microsoft chose?

Myself, being a cynic, I note that if cell A2 has custom validation rule =$A$2<10 and I select A1:A2, type 1E12 and press [Ctrl]+[Enter], Excel enters 1E12 in both A1 and A2, without triggering the validation rule in A2. So I suspect that Excel only applies validation rules when entries are made in *single* cells, and they made the rather breathtakingly simplistic assumption that pasting would always be a multiple cell operation. Thus pasting into single cells doesn't trigger validation rules.

Out of politeness I might accept an alternative explanation, but I'm not sure I'd really believe it.
# November 1, 2005 6:46 PM

Biff said:

I consider myself to be an above average user and I can see a fairly steep learning curve going from any current versions of Excel to Excel12.
# November 2, 2005 1:09 AM

Harlan Grove said:

Re Biff's comment about steep learning curve: we'll all be newbies together!

Seriously, I'll stand by my earlier prediction: IT departments will look back on Office 12 as perhaps the biggest PITA upgrade in history. As I've already mentioned, the XL4 to XL5 transition, the last radical one, was no big deal because XL wasn't so widely used at that time (early 1990s).

Interesting to see whether CIOs view the benefits of Office 12 worth the training and reduced initial productivity costs. I suspect I'll still be using XL10 (2002) at work 5 years from now. However, I'll probably upgrade *one* home machine on my own.
# November 2, 2005 2:34 AM

Microsoft Excel 2007 (nee Excel 12) said:

Guest writer: Eric Patterson.&amp;nbsp; Over the next several posts, Eric, one of the members of the Excel...
# August 10, 2006 2:16 PM

Microsoft Excel 2007 (nee Excel 12) said:

SamRad is back with another guest post.&amp;nbsp; Today Sam is writing about another feature he worked on...
# September 6, 2006 2:13 AM

Microsoft Excel said:

Today’s Author: Joe Chirilov , a program manager on the who has done a lot of work on both the Excel

# November 28, 2007 5:13 PM

Noticias externas said:

Today’s Author: Joe Chirilov , a program manager on the who has done a lot of work on both the Excel

# November 28, 2007 5:20 PM

Microsoft Excel said:

Today’s author, Monica Poinescu, a Software Developer in Test on the Excel team, gives an overview of

# February 9, 2009 8:14 PM
New Comments to this post are disabled
Page view tracker