Microsoft Office Developer Advisory Council

A load of us are off the Seattle in a few weeks to discuss the next version of Office (official codename: Office 14 I think). This is a follow up event to the one I went to in March.

Its a great event where we look at whats coming up and give our views on how things might work. Its good to see MS including a wide variety of people in their thinking/prioritising. The specific focus of the program is on the developer story for Office. Its all under NDA of course, but I can certainly pass our views on to them.

So from an Office developer perspective,

  • whats good and needs continuing
  • what needs improving
  • what needs adding
  • what needs to just go away?

What I would like to see in OfficeNext is:

    1. Improved/updated Integrated Development Environment – either the VBAIDE (at least to VB6 standard) or preferably VSTA (with single file solutions as an option (ie not forced to split code and grid))
    2. Improved external data management
    3. Introduction of performant User Defined Functions.
    4. decent level of .net integration (preferably including distributing a recent framework)
    5. Improved compliance/auditing features, including decent workbook compare functionality.
    6. Fix the UI or bring back commandbars (same thing??).
    7. make range.dependents/precedents include off sheet ranges as well.
    8. Don’t know about collaboration features – what do you think?

      So thats me, what sort of stuff would you like to see?



      17 Responses to “Microsoft Office Developer Advisory Council”

      1. Nick Hebb Says:

        Here’s my wish list:
        1. Add events for shapes:
        – an AutoShape_Click or AutoShape_SelectionChanged event
        – an TextFrame_Changed event for shape text changes
        – perhaps Move, Resize, and MouseOver events as well

        2. Shapes randomly change the reading order to right-to-left if it is not explicitly set when text is added. Even explicitly setting it does not always work.

        3. Extend ShapeRange to acct like a collection, with Add and Remove methods.

        4. Allow hyperlinking directly to other shapes.

        5. Add a Textbox to connectors for annotated lines.

        6. Allow ribbon tabs to be pinned so Excel doesn’t automatically change the current tab.

        7. Expanded macro recording (a lot of things were dropped in 2007, including anything to do with shapes).

        BTW, did I miss something or did they leapfrog Office 13?

      2. Harlan Grove Says:

        Starting w/your list,
        2. Improved external data management
        –> How about a BUILT-IN version of SQL.REQUEST?

        3. Introduction of performant User Defined Functions.
        –> You mean XLL-like speed from VBA-ish code? Be nice, but wouldn’t it require more heavy duty compilation?

        6. Fix the UI or bring back commandbars (same thing??).
        –> Good luck!

        7. make range.dependents/precedents include off sheet ranges as well.
        –> Boldly taking Excel into 3D functionality territory Lotus and Borland/Corel staked out almost 2 decades ago? If MSFT had meant Excel to become a true 3D spreadsheet you’d think they’d have managed it already.

        8. Don’t know about collaboration features – what do you think?
        –> Redundant. Don’t SharePoint and/or Groove already all the collaboration any sane human could handle?

        My own ideas. I’ll be brief.

        i. An IEEE-compliant MOD worksheet function that doesn’t choke after 29 binary mantissa bits. I.e., one that would return 1 from =MOD(2^30,3), as damn near all other software capable of floating point arithmetic can manage. [This one proves MSFT has no shame.]

        ii. REAL data validation without code, including number format-like input masks a la Access, isn’t bypassed by pasting into cells.

        iii. Long shot – a more refined macro/VBA security model, e.g., one that would distinguish between method/property/organic VBA that isn’t dangerous/can’t alter anything from that that is dangerous. For example, allow udfs wrappers around simple property-get operations, e.g.,

        Function IsFormula(r As Range) As Boolean
        IsFormula = r.Cells(1).HasFormula
        End Function

        Point here would be providing for a macro/VBA security setting that would allow ‘safe’ udfs (and ‘safe’ macros, e.g., those that change print properties then print ranges/worksheets) WITHOUT prompting users to enable macros generally. Off limits would be Declare, Shell, Name, Kill, Open…For Output, and those methods that alter objects in ways Undo can’t undo.

        iv. More worksheet information functions, e.g., a work-alike for OpenOffice Calc’s SHEETNAME worksheet function. Fine by me if they’d just make XLM’s GET.* functions standard worksheet functions.

        Guess my worksheet-centric bias shows.

      3. Stephane Rodriguez Says:

        Proper maths.

        1) Proper calc implementations. My product has to emulate Excel bugs due to its market ubiquity. Perhaps they could introduce a “proper maths” mode.

        2) Proper calculations. That sounds like 1) but it’s not, I’m talking here about the numeric results as saved in the new SpreadsheetML file format. They are doing all kinds of weird truncations (to save place or something like that), whereas BIFF kept the numeric results (IEEE double) as is.

      4. Ross Says:


        >> decent level of .net integration (preferably including distributing a recent framework)

        Wont they have to install framework X when Office (with VSTA) is installed – Going forward, office 14 will say have to work against DNFW 3.5, and then office 15 against DNFW 4. Be interesting to see how this pans out – might be a worst situation than we have now with different office versions.

        >>BTW, did I miss something or did they leapfrog Office 13?

        Unlucky for some!

        >>7. make range.dependents/precedents include off sheet ranges as well.
        –> Boldly taking Excel into ….
        Is Excel not 3D then? I’ve never worked with 123 or quttopro(?), I would love off sheet ranges, what about into other workbooks too?

        >>8. Don’t know about collaboration features – what do you think?
        –> Redundant. Don’t Share Point and/or Groove already all the collaboration any sane human could handle?

        From what I’ve seen of SP and Groove v’s other Excel colab stuff I would say no they don’t. (Groove look like total pants to me, BTW) I’m not sure about the whole area anyway.

        >>ii. REAL data validation without code, including number format-like input masks a la Access, isn’t bypassed by pasting into cells.

        Hell YES!

        >>Long shot – a more refined macro/VBA security model…
        That is part of the VSTA plan, not sure they would go and do it in VBA now too.

        For me charts!
        I’d like better rendered charts – and proper 3d charts please, or and command bars obviously

      5. Dennis Wallentin Says:

        In short:

        # Add Ribbon APIs to allows us more control of the Ribbon UI

        # Add a Ribbon Visual Designer like in VS 2008.

        # Add a built-in modern general “SQL tool” to easily interact with databases. (that goes beyond the SQL.REQUEST suggestion from Harlan.)

        # Add a Design Tool for creating designed worksheets with.
        (Different tasks requires different designs needs of worksheets.)

        # Implement a new security model based on .NET.

        That’s it for 14.0

        Kind regards,

      6. Harlan Grove Says:

        Ross: Excel is not 3D, e.g., 123 has an @INDEX function that takes an optional 4th argument for sheet index into a 3D range. In 123 and QP, 3D references *ARE* ranges, so everything that can be done with 0D (since cell), 1D and 2D ranges can also be done with 3D ranges. Try =MODE(A:B!A1:B200) in Excel. FWIW, OpenOffice Calc provides relative and absolute worksheet names in references to other worksheets.

        It’s Excel’s unchanging 2D nature that screws up nearly everything involving multiple worksheets. The problem is this is cemented into Excel’s object model – Range class is child of Worksheet class. What’d be needed would be a different Range-like class as child of the Workbook class. It’d be a BIG project changing everything else in the OM to use workBOOK Range objects instead of workSHEET Range objects, but that’s what it’d take to make Excel a true 3D spreadsheet.

        Dennis: as long as there’s a BUILT-IN WORKSHEET FUNCTION to process formula expression-generated queries as part of normal recalculation, fine w/me.

      7. sam Says:

        I would be very happy if in Office 14 they dont add any new feature… but just fix known issues….and of course fix up things that they broke in Office 12…meaning the UI….

        Heres my list of 14 things to be done in Office 14

        1. From a Developers point of view – re-introduce a “Developer” version of Office 14 just like in Office XP…. give back the ability to create COM addins and XLL just in the same way as XLA’s…Save As…com addin…wouldnt that be nice

        2.Improve limits : 8192 areas, no of elements in a Validated list – Currently 32 K, etc to match the new grid size…

        3.Make Indirect function recognise Dynamic names..

        4.Bring back XLM functions (may be as an Addin)

        5. Include possibility of opening a password protected file via SQL just as in a normal database. Include possibility of Deleteing a record via SQL just as in a normal database.

        6.Improve data validation : Autocomplete list, Sort list, prevent paste on validated cells, trigger validation when pasting….

        7.Give us a bug free – Lastused Cell function

        8. Improve Names : Built in Dynamic names + a decent NameManager – Just integrate the one from JKP

        9. More powerful calulated fields and calculated items in Pivot Tables …ability to use Range formulas / names in Formulas….

        10. When doing large task…automactically swith to Calc = manual mode…example when deleting 1000’s of filtered rows….

        11. Improve the encryption of worksheet , workbook and VBA password….It should be possible to break only through Brute force method…

        12. Upgrade the VB IDE

        13. Some new chart types…..Real 3D contour…

        14. Get Rid of the Ribbon….or implement the Classic UI option, Implement customisation of Task panes, Right click , Cell Drag drop menu and all other menus which cant be directly customised in 2003….
        Also steer clear of .net, VSTA, VISTO and a host of “improved” technologies…just stick to VB….

        However all this is just going to fall on deaf ears…. here is a list of what I think we are going to get in Office 14

        1.14 New fonts.
        2. 14 new colours
        3. 14 new bugs that arent there in Office 2003
        4. 14 less features that are pretty useful now….Because their market survey showed that only 2% of the users use them….


      8. Harlan Grove Says:

        sam: how would worksheet/workbook/VBA internal encryption work? Unlike File > Open passwords/encryption, workbooks need to function when opened even if users don’t provide worksheet/workbook/VBA passwords. That means the workbook would need to include its own decryption keys in order to be able to decrypt itself in RAM. If it includes its own decryption keys, how secure is that?

      9. sam Says:

        Harlan: thats for the “experts” (if any) at MS to figure out…but I am sure they can come up with something better than storing a worksheet password as a 16 bit hash …so that a password as “test” can be opened with a host of other passwords including “zzyw”

        So I hope in Office 14 issues like the one posted by every one else takes precedence rather than adding 14 new shades of blue….to chart colors


      10. Harlan Grove Says:

        sam: my own suggestions are things for which I have a clear idea how to change/fix. As long as worksheet/workbook/VBA project passwords are included as part of their files, those files won’t be secure.

        Do the XML file formats encrypt cell formulas in worksheets with password protection?

      11. Simon Says:

        Sam – I like your list of what will be in O14, I too have noticed a focus on style over substance.
        Harlan – I don’t think ws passwords are used to encrpt cell contents, certainly not in biff so prob not in xml. Its just a flag to tell Excel to ask for a password. If saving xl2003 to xml it doesn’t let you if a sheet is protected (I think?)

        Personally I don’t want to see improved security, I think the openness is one of spreadsheetings strengths, and what has speeded its adoption over other technologies.

      12. sam Says:

        “Personally I don’t want to see improved security, I think the openness is one of spreadsheetings strengths”

        Simon : I dont think Excel will be persued as a serious development platform if at the end of the day you know that your VBA code or Formulas are not secure. enough…Hence my suggestion to either beef up the security or allow for creation of a complied addin – exe/dll/xll etc from within Excel


      13. Harlan Grove Says:

        Spreadsheet files will never be as secure as compiled code. Ever. Excel developers need to understand this up front. If you have IP you want to protect, don’t use spreadsheets.

      14. sam Says:

        “Never……..Ever”……Well over the last 15 years there certainly has been an Improvement….

        The file open password in Excel 95 was a joke….it was as easy to break as sheet level password is today ….it got better in 97 and MS started using a RC4 encryption from Office 2K onwords.. even though the experts in the field say it was wrongly implemented …….
        ….may be by O2015…..things would have fallen in place……


      15. Harlan Grove Says:

        There’s still that fundamental difference between File > Open passwords and internal passwords: no one expects a workbook to open without the user providing the File > Open password, and the password doesn’t need to be stored in the file – it’s sufficient for part of the file to be encrypted with it. OTOH, open workbooks ARE expected to work even if the user provides NONE of the internal passwords. You can’t use internal passwords to encrypt other contents in workbooks without making it possible for Excel to decrypt those parts while loading the workbook into memory, and if there’s a decryption key in the workbook, how long before someone figures out how to use it?

        As for File > Open passwords, no big deal they were improved between Excel 95, 97, 2K. There’ve been 3rd party encryption programs since the mid 1980s. And while File > Open passwords may have improved, I doubt the same could be said for internal passwords.

      16. Ross Says:

        Ar Ok Harlan, thanks I see now.

        Sam, lol spot on i think.

      17. Charles Says:

        Here is my top list of VBA things to fix/improve:

        – fix the bug that makes each execution of every instance of a VBA UDF refresh the VBE titlebar.

        – get Range to variant and variant to range execution speed back to where it was in previous versions (matching Excel 2000 would be OK).

        – provide a sensible way of adding UDF parameter descriptions for the function wizard

        – add Application.caller.LastCalculatedValue for UDFs (the only thing you can currently get is last formatted value which is of limited use)

        – workbook level calculation as well as the existing methods, and the ability to specify persistent workbook calculation mode properties

        – integration of .net to the same level and same performance as VBA.

      Leave a Reply

      Please log in using one of these methods to post your comment: Logo

      You are commenting using your account. Log Out /  Change )

      Twitter picture

      You are commenting using your Twitter account. Log Out /  Change )

      Facebook photo

      You are commenting using your Facebook account. Log Out /  Change )

      Connecting to %s

      This site uses Akismet to reduce spam. Learn how your comment data is processed.

      %d bloggers like this: