Feedback by UserVoice

Feature Requests and Feedback

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Make VB6 programming part of Office

    VBA programming is already part of Office. It's sister language VB6 should become part of the Office family and be updated to the same standard as VBA7.
    VB6 should allow compiling to standalone .Exe files, but otherwise it should retain compatibilty with VBA.
    There is still a large volume of legacy Visual Basic 6 code that needs supporting.

    105 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    29 comments  ·  Add-in: General  ·  Flag idea as inappropriate…  ·  Admin →

    We want to thank everyone for their comments and votes on this thread. This is not the first time we’ve received this sort of request. We’ve also heard this feedback on the Excel UserVoice forum. You can read our full response at https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/8843113-bring-vba-into-the-modern-world.

    We’ll summarize the key points here.

    VBA will still continue to be supported in Office, and as we add new features in the Windows desktop versions of Office, we will add object model APIs for those features. You can find more details about feature improvements here: https://aka.ms/odevblog-vba.

    However, the VB runtime was built a long time ago, before today’s cross-platform world. Moving forward we need to provide the ability for folks to take advantage of opportunities with cloud-centered, cross-platform, and cross-device development. Our strategy moving forward is to use cross-platform JavaScript APIs that are available to developers in Office 2016. We are continuously working to…

  2. Don't ignore displayInIFrame on Desktop

    UI.displayDialogAsync supports Options argument which can use displayInIFrame flag to define if IFrame is used for showing the contents.

    What I would suggest in case of Desktop is to use this flag (or enhance the option) to change the styling of the used system dialog to be as seamless as much as possible.

    Right now if you create some nicely styled page and show it in this dialog it looks ugly on Windows 7 (and probably on W8 as well) because of the borders, title bar, etc.

    9 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Add-in: General  ·  Flag idea as inappropriate…  ·  Admin →

    Thank you for the suggestion. We really appreciate it! We currently use the same visual styles as the rest of the Office dialogs for a given platform. The goal is that add-ins are as consistent as possible with their host. We do not have plans to change this behavior on the dialog API, but perhaps what you need is a different UI container? For example, a flyout card or similar?

    Thanks,
    Office Extensibility Team

  3. MS Office Add-in location (URL) reset

    MS Office Add-in (web) doesn't save URL destination inside. For example 1. you add content Add-Id in your document 2. change URL inside (click the link inside it) 3. save it

    After you will open your saved document website inside your add-in will be default, not that you have reached before saving

    3 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Add-in: General  ·  Flag idea as inappropriate…  ·  Admin →

    Hi Alexey, and thank you for the suggestion. We really appreciate it! You can achieve the outcome you are looking for by using document settings. Automatically saving the location of the webpage would unfortunately break several other add-ins that rely on the current behavior.

    Thanks,
    Office Extensibility Team

  4. Allow Office.JS Add-ins to be deployed VIA plain HTTP/S (without Sharepoint)

    I would like the new Office.JS add-in framework to have the ability to publish add-ins via plain HTTP, without the use of Sharepoint server.

    The Office.JS framework has been beautifully designed in it's use of HTML/JS for add-in development. Unfortunately, it's usage in in Enterprise environments is strongly limited by the inability to deploy add-in manifests via simple HTTP (barring the use of Sharepoint, which is very expensive and not worth buying simply for the purpose). Since the manifests can be published via simple file share, it feels as if this is an artificial limitation that goes against the entire…

    18 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Add-in: General  ·  Flag idea as inappropriate…  ·  Admin →
  • Don't see your idea?

Feedback and Knowledge Base