Feedback by UserVoice

A.C. WILSON

My feedback

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

    We’ll send you updates on this idea

    A.C. WILSON commented  · 

    OssieMac's suggested implementation is a good one.

    A.C. WILSON supported this idea  · 
  2. 4 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  3. 60 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  4. 637 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Great suggestion – thanks again for taking the time to put it on this site and for the thoughtful followup comments. This is pretty related to some other work we’ve got going and already has a fair number of votes, so we’ll work on getting plans in place now and hope to get started on this soon.

    Thanks,
    John [MS XL]

    A.C. WILSON commented  · 

    My primary reason to NOT call this thing "EMPTY()" [nor "BLANK()"] would be that my life is simpler when the same functionalities in Excel and in Access have the same names. But, this would not be a deal-breaker for me.

    What to name this thing is a problem primarily because Microsoft's writings have been very vague about both the vocabulary to describe, and the behavior of, a cell's "state" [my own imperfect term, not Microsoft's].

    It appears to me that each Excel cell has four possible "states":
    1) BLANK [Default null; cannot (yet) contain any value or expression. All cells in a new empty worksheet start out in this "state". A cell can NOT (yet) be reset to BLANK/null via an Excel cell formula. [In Microsoft Access, and perhaps also in Excel VBA, formulas CAN be used to force to "NULL".] Depending on how we choose to conceptualize "value", a "BLANK" cell either cannot contain any value in it, or can contain only one possible value, which we conceptualize as "blank".]
    2) TEXT [Can be of zero length, as ="" , or equivalent value.]
    3) NUMBER
    4) LOGICAL [In many respects, behaves like a variant of NUMBER]

    When any Excel functionality, including a cell formula, "tests" a cell, how that functionality responds depends in part on which of the above 4 states it is in. Therefore, some of us users would find it very helpful to able to control that state, via the proposed function.

    [I note that some programming languages such as COBOL, [but not Excel,] have other special functions to indicate implementation-specific constants. A common one is "HIGH-VALUE()", which indicates a "pseudo-infinity" - the highest value that can possible be stored within a numeric field [variable]; this is immensely preferable to arbitrarily hoping, and specifying in a formula, that one cannot possibly exceed "99", "99,999", or similar.]

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

    We’ll send you updates on this idea

    A.C. WILSON commented  · 

    Sometimes the opposite happens - too few lines per row instead of too many. I suspect that this clumsy behavior varies by font.

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

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  7. 8 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON commented  · 

    Excel is not smart enough about knowing where its last row and column are. And, this fact is poorly documented if at all. Also not documented is the work-around solution (which is to delete all rows a below and all columns to the right of the last cell that you want to keep, and to THEN SAVE the Excel file).

    A.C. WILSON supported this idea  · 
  8. 14 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  9. 38 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  10. 21 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  11. 45 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  12. 10 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Thanks for the suggestion Rolands! I’d be curious to see, in comments, what other constants people are interested in. I’ll check back on this later, and of course the more votes it has the more likely it is to get into the product – so please keep the votes coming if you like the idea!

    Best,
    John [MS XL]

    A.C. WILSON commented  · 

    Another one - unitless, but not mathematical in a conventional sense:
    Some programming languages such as COBOL, [but not Excel,] have other special functions to indicate implementation-specific constants. A common one is "HIGH-VALUE()", which indicates a "pseudo-infinity" - the highest value that can possible be stored within a numeric field [variable]; this is immensely preferable to arbitrarily hoping, and specifying in a formula, that one cannot possibly exceed "99", "99,999", or similar. "LOW-VALUE()" is another.

    See also the "NULL Worksheet Function" suggestion:
    https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/17265644-null-worksheet-function

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

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  14. 5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  15. 7 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  16. 98 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  17. 8 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  18. 17 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  19. 13 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    A.C. WILSON supported this idea  · 
  20. 38 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Thanks for the suggestion Alexander. We’ll be taking a look at how various lookup scenarios work and looking at improvements there. We’ll be sure to deeply consider anything that’s got a lot of votes, so please keep voting for the things you find most important.

    Thanks,
    John [MS XL]

    A.C. WILSON commented  · 

    I believe that implementing the more generalized 2-dimensional look-up "GETMATCH()", as suggested elsewhere in this site, will be a better use of MS's Excel-staff resources than making any further tweaks to the VLOOKUP/HLOOKUP, which are fundementally more limited.

← Previous 1 3 4 5

Feedback and Knowledge Base