I am making an add-in for outlook with dialogues using the displayDialogAsync method.
The problem is that if the main window has a small size the dialog will also be small, because the width and height is a percentage of the main window, and the content will not fit.
Is it possible to know the size of the main window, so I can use that to calculate how big the dialog should be?
I have tried with $(window).height() and $(window).width() but that returns the height and width of the box the add-in buttons are located in.
The display dialog only supports percentages, and the feature you requested is currently not part of the product. We track Outlook add-in feature requests on our user-voice page.
It looks like the feature you want has been requested by others already. Please upvote the existing request. Feature requests on user-voice are considered when we go through our planning process.
Related
I am writing an Outlook Add-In (Web version, Desktop) and so far I was able to add a link to my app in the contextual menu (see screenshot below - highlighted in yellow). This work well, but it is almost impossible to find the add-in and this is resulting in a ton of customer support calls. I was wondering if there is a way to add the button next to "Send", "Discard", or after the "Elipsis" buttons. This way the add-in would be more visible.
I was thinking about directly modifying the DOM if it is not possible, but I would prefer to not do that.
You can add a button there neither from a web based JS addin nor from a COM based addin for the desktop version of Outlook.
How to add button to main menu behind "Mark all as read"
instead of showing button inside email body read document but it doesn't help me to find solution,
You cannot get your add-in icon displayed in any place you like. The add-in controls are defined by manifest and displayed in predefined locations of particular client (Outlook Web, Outlook desktop for Windows or Mac, Mobile). Up to developers (Microsoft team) to define the place where the add-in controls will be displayed.
EDIT:
There are two places where add-ins may appear in the client interface. This depends on what type of add-in you have created. There are command add-in and contextual add-in. Both of them will appear somewhat in the space of the message view anyway. The following are examples of where they appear withing the interface ...
And for web view ...
To read more on Outlook add-ins Extension points got to Outlook Add-ins overview article.
Currently the feature you requested is not a part of the product. However, we track Outlook add-in feature requests on our user-voice page. Please add your request there. Feature requests on user-voice are considered when we go through our planning process.
I am developing Outlook add-in and displaying a dialog with option displayInIframe: true and height and width parameters given. However I have experienced a problem using add-in in outlook.com via browser. Although it works good when screen has a standard proportion (width>height), it looks bad when I resize the window and make it narrow (height>width). Then, the content is resized and pushed to the side of the frame while the iframe itself stays with the same size.
The question is if I can do something with that or its a Outlook issue. If so, I would like to notify MSFT about it.
This is expected behavior of a web application, you cant do much except setting the min-width for your html page so that it does not look that bad.
you can do some css changes to make the page look better for height/width in question.
I'm writing a PowerPoint content addin using Office.js API. I need a way
for each instance of that addin to determine the index of the containing
slide, or, if this is impossible, the visibility state of the addin (i.e.
whether the containing slide is currently visible on screen).
The documentation suggests
no API specifically intended for this purpose, so I've been using
the following method:
Upon addin initialization (inside Document.initialize callback),
request currently selected slide using Document.getSelectedDataAsync
method.
Since addin cannot be initialized until it is visible, we can be almost
sure that the index obtained in the step 1 is the one of the containing slide
(unless the user was fast enough to change the slide while
getSelectedDataAsync was doing its async communication).
However, the assumption made in the step 2 has proved to be wrong. It holds
for PowerPoint Online, but desktop PowerPoint behaves differently.
Specifically, in slide show mode, if the slide next to the currently displayed one
contains an addin, and that addin is not yet initialized, it gets pre-initialized
despite the fact that it is not visible/active. And in all such pre-initialized
addins, Document.getSelectedDataAsync returns the index of the slide that is currently
displayed, which is not the one that contains the addin.
So the question is: is there a way to more or less reliably determine the containing
slide index, the way that works in both web and desktop versions of PowerPoint?
If no, here's the second question: is there a way for an addin to determine whether the containing slide is currently visible on screen in slide show mode?
I've found one that works in PowerPoint Online (checking window.innerHeight in
slide show mode), but it relies on internal implementation details that are
subject to change any time, and, most critically, it doesn't work in desktop
PowerPoint.
Desktop PowerPoint seems to display each addin in a separate window (as
window.parent equals window), and I failed to find an API or workaround that
would allow to tell whether the window is currently visible.
Page Visibility API
seems to fit this purpose perfectly, and it is even implemented in IE11, but
it doesn't work inside PowerPoint (visibilitychange events don't fire,
document.visibilityState always equal "visible", even if the addin is
on a currently hidden slide).
At present, the PowerPoint client seems return the active slide instead of the parent slide since the function “getSelectedDataAsync” is asynchronous.
is there a way to more or less reliably determine the containing slide index, the way that works in both web and desktop versions of PowerPoint?
As far as I know, there is no API to return the slide which contains the content app. And if you want the Office add-in support this API, you can submit the feedback from here.
Whats the best way to create a 'scrollable panel' in MFC (C++) ? In the past I have displayed different windows "attached" or "on top" of my main dialog window as a means of display different pages of an application. What I want to do this time is create a panel of controls that can be scrolled (because the virtual size of the panel is bigger than the size of the panel itself).
Can anybody recommend any good articles or tutorials on how best to do this?
Thanks
You can create an independent scrollbar control on the side of your dialog. Respond to the messages in the dialog to move your controls. Since the child windows will crop themselves to the parent client area, feel free to move them completely off the dialog as they scroll off the page.
If you place the controls in a CScrollView or a CFormView they will be automatically scrollable inside the view area.