I have a custom TaskPane in Outlook. When the user toggles the visibility, I record it in the settings object so that the next time Outlook starts it will be shown/hidden as the user left it.
CustomTaskPane.VisibleChanged is raised in each of the following scenarios
The user clicks the X in the top right corner of the task pane
TaskPane.Visible is set in response to the user pressing a toggle button in the ribbon
The user presses the File menu button on the top left
The first two ways, the user clearly meant to hide the task pane. The third way the user was just trying to go to the menu screen (perhaps on their way to hit the Exit button).
Question
Is there anyway to determine that the event was raised because of the File Menu? Any way to programatically determine if the File Menu is currently open?
Here's what I mean by the File Menu Screen:
The Backstage UI provides two callbacks that can be used for tracking when the File menu is open and closed:
onShow - The Backstage view is displayed which triggers the OnShow callback procedure.
onHide - when the Backstage view is not longer visible.
The onShow attribute and the onHide attribute of the element can point to code that performs that kind of action.
<backstage onShow="OnShow">
See Customizing the Office 2010 Backstage View for Developers for more information.
Related
I have a custom task pane and now I am trying to catch the close event of the custom task pane. I have seen that there is no such event, instead there is the VisibleChanged event with does exactly the same, it is raised when visibility changes or it is closed.
When user clicks on close button or select close from the context menu, I would like to display a messagebox saying it is not permitted to close it and not allow user to close it.
I have seen an approach here or this user a thread but this is causing flickering when showing it again (you can see that it is hidden and then make visible again quickly). Is there any other way to achieve this? Also where is the best place in those approaches to show the messagebox?
Custom task panes don't provide any event which is fired when the pane is about to close. There is no trivial way to get the job done, you need to implement workarounds described on forum threads. Also you may consider using Advanced Outlook view and form regions instead.
Note, Outlook form regions provide the following events out of the box:
Event
Description
FormRegionInitializing
Occurs before the form region is initialized. You can check conditions in this event handler to determine whether Outlook should display the form region. For more information, see How to: Prevent Outlook from displaying a form region.
FormRegionShowing
Occurs after an instance of the form region is created but before the form region appears.
FormRegionClosed
Occurs before the form region is closed.
I have a custom button that I place in the ribbon menu but what I observe is that sometimes the button is visible and sometimes not, it depends on the size of the explorer and compose windows. If you resize to a smaller size it is not visible and if you resize to a bigger size it is visible. It only happens in simplified view but not in classic. So in simplified view it seems Outlook decides which buttons are being shown and which not based on a criteria that I don't know, maybe on the space available in the ribbon menu which in turn depends on the size of the window?
Anyway, If I click on commands bar button ("..." three dots button) at the end of the ribbon menu and then from that menu I do a mouse right click on my button and select "Pin to ribbon" for it, then my button is always visible in the ribbon menu regardless of if the view is classic or simpified or even if window is resized to any size.
Is there any way programmatically to indicate Outlook to always show my button in the ribbon menu?
No, the Outlook extensibility model (nor the Fluent UI) doesn't provide anything for that. You may try using RegMon for Windows to track windows registry changes in case if Outlook keeps such preferences there.
all.
I'm trying to do the following, using standard windows menus. I have a menu with a sub menu attached to it. I need to perform different actions when user clicks the menu item that opens a submenu, and user hovers over the menu item and submenu opens without a click.
As far as I could see WM_MENUCOMMAND is only sent when user clicks on a menu item that does not have a submenu attached. Also no mouse click messages are sent when I actually click an item that contains submenu.
So is this even possible?
Thanks.
I believe you can tell when the mouse moves over an item by watching for WM_MENUSELECT. You would then have to start a timer, and if the timer expires before the cursor moves again, you'd have to manually pop open the submenu. I'm not sure how to accomplish the second part.
And it's pretty non-standard behavior that might confuse users. What are you trying to accomplish? And how do you expect it to work for users with only keyboard access?
My task is to implement a file upload form in a popup sub-menu panel. I am using XmlHttpRequest, so it's important to keep that popup opened until I receive an event status that file loading completed/failed. Onmouseover and onmouseout events are used to show/hide the popup.
On "hide" the popup panel is detached from the DOM, and cannot be used anymore as a listener for XHR events.
When I click form's "Browse" button, a system dialog window is opened above the browser. In IE, Chrome and Firefox in Windows the system dialog disables events handling by page. Which means if you move a mouse cursor out of the dialog window on one of the page element, the page won't do anything like reacting on mouseOver/mouseOut events. Unfortunately, in case with Chrome/Firefox on Mac (Safari is OK) the page elements do react on mouse over/out. And my popup menu becomes closed (due to mouseOut event handler for the popup) -> XHR response is not managed properly.
Assuming having an upload form in a popup is a must, what are the possible ways of keeping that panel/form visible while system Upload File dialog window is up? Probably a Mac specific solution.
Sample code can be seen here http://jsfiddle.net/xqvXG/
Solved this by freezing popup panel and covering the whole page with transparent div ('glass').
In case if user chooses file(s) and upload starts, I remove the glass and unfreeze the popup using the XHR function readyStateChangeHandler (or may do that in handler of load event).
If user clicks Cancel in system dialog window or closes it with "X" button - no events passed to the page and 'glass' remains on screen. Then any click on the 'glass' causes its removal and unfreezing (or simple hiding) the popup menu.
'Glass' is required to make a single one-click point (panel) for unfreezing the popup in case if Cancel/Close were pressed.
I wouldn't say this is a perfect solution (sometimes required extra action), but very close to what I was looking for.
Is it allowed by Windows Phone application certification rules, to only have users be able to return to a previous screen with the use of a hardware back button?
In my scenario, a user clicks on a setting button and lands at a settings page. He changes settings if he decides to, and all the changes get saved automatically, like in iOS.
But currently, the only way for the user to get out of the settings screen, is to press a hardware Back button on the phone.
Will such implementation of navigation functionality pass the Windows Phone certification?
Yes - leave the back button as the navigation method to get back to your main page after visiting the settings page. Not only is this allowed, but it is the desired method of back navigation, and it is what Windows Phone users expect. Here is a great article on the subject: http://blogs.msdn.com/b/ptorr/archive/2011/10/06/back-means-back-not-forwards-not-sideways-but-back.aspx
As far as I understand the terms of the navigation guideline is your usage the right way to go.
Back button
Pressing the back button from the first screen of an application must exit the application.
Pressing the back button must return the application to the previous page.
If the current page displays a context menu or a dialog, the pressing the Back button must close the menu or dialog and cancel the
backward navigation to the previous page.
You should only implement back button behaviors that navigate back or dismiss context menus or modal dialog boxes. All other
implementations are prohibited.
See this cheat sheet for more informations on the design guidelines.