I'm developing a VSTO add-in, I need to re-active(open) Outlook when its "MinToTray" is enabled(by the context menu in the tray of Outlook icon).
I use Process.Start("Outlook.exe", "/recycle") to do this. And it works. Except, for the first time when Outlook is re-open, its Title bar, Ribbon area, and Command bar become white, unless I resize the Outlook window.
Image [https://i.stack.imgur.com/VuKOZ.png]
Does anyone know how to fix this? It is very appreciated.
Thanks!
Try to call Application.ActiveExplorer.Activate instead.
Thanks #Dmitry Streblechenko. Application.ActiveExplorer.Activate will not work when Outlook is minimized and hidden (Check on the context menu of the Outlook icon in system tray);
I fixed it by myself. Needs to expand my VSTO panel until Outlook is completely recovered from minimized and hidden state.
Related
I work on an add-in for Microsoft Outlook, and we’ve noticed that in the Outlook Web App our Add-in cannot open at all when we attempt to open it from the “More Add-ins” button. The menu that lists more add-ins will open, but then clicking our add-in closes the menu with nothing happening.
We used to have our Add-in’s ribbon menu open when it was clicked here. We first encountered the broken behavior yesterday (7/28/22).
We’ve checked if this is happening to all Add-ins with a list of ribbon commands, and this seems to be the case for all Add-ins. To reproduce this error, we’ve implemented Microsoft’s example for Add-in commands (https://github.com/officedev/outlook-add-in-command-demo) by uploading to https://officeapp.s3.amazonaws.com/command-demo-manifest.xml and installing from URL.
Clicking the “Add-In Command” closes the menu, and nothing happens.
The expected behavior is a list of commands should show:
Additional Note: The ribbon command menu correctly appears if the Add-in is pinned to the toolbar via Settings->Mail->Customize actions->Toolbar. This is how we were able to take a screenshot to demonstrate the expected behavior.
Thank you.
Thank you for reaching out. This is a known issue within the Outlook web client. We are working on a fix for this issue, but do not have a timeline to share at this moment.
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.
How do I find which Windows process is displaying a given taskbar system tray icon?
I've just realised that in Windows 7 the 'Select which icons and notifications appear on the taskbar' menu helps a bit here. Find it by right-clicking the taskbar, go to 'Properties', then click the 'Customize...' button in the 'Notification area' frame.
Each row in that window represents a taskbar icon that Windows Explorer has seen. Of the left two rwos, I believe the top one is the process's description as shown in Task Manager, and the bottom one is the window title for the window showing the taskbar icon.
This would've helped me track down my original problem! VisualSVN was popping up a 'Register me!' nag window in the system tray, despite no obvious VisualSVN processes running. Eventually I noticed that this nag window disappeared when I closed Visual Studio, so it was clear that the VisualSVN add-in DLL loaded in Visual Studio was creating the nag window.
Shell_NotifyIcon works by sending a special WM_COPYDATA message to the taskbar, if you inject into explorer and subclass the taskbar you could catch this message, you could then get the process id by calling GetWindowThreadProcessId on COPYDATAstruct.NOTIFYICONDATA.hwnd.
...and of course, this is a hack and relies on undocumented information that could change at any time!
I don't believe this to be possible. Certainly Spy++ reports that the Notification area is a single window named "User Promoted Notification Area". This window is ultimately parented with the desktop window and has no obvious association with the process that created the notification icon.
Well, by possible I mean possible without resorting to hacks like Anders suggests which is no doubt feasible, but not what I imagine the OP is looking for!
In a custom toolset I have installed for Visual Studio, there is a popup window that should appear to me so that I can manipulate one of the lists (an in-built editor). The component is Telerik, but I don't think that has anything to do with it (maybe).
The popup window is no longer popping up to me. I wonder if it got minimized or it's a z-index thing, where the window is behind VS? But this locks up VS, and I can't do anything within it until I cancel the window. But I can't cancel the window because I can't see it... and so that is really slowing me down and is really frustrating.
Is there a way to get around this? A key press to bring this to the front or give it the focus?
Thanks.
You should be able to cancel it with ESC. You can also test if you can find the window with CTRL-TAB. If this not help then an uninstall, boot and reinstall seems the only possible solution.
This might be a z-index issue indeed. Try using FireBug or IE dev toolbar to get a hold on the popup and its container and check their styles and z-indices.
Dick
We are experiencing this annoying problem where we have a context menu on our tray icon, if we display this context menu we have to SetForegroundWindow and bring it to the front. This is really annoying and not at all what we want.
Is there a workaround, I notice that Outlook MS Messenger and other MS apps do not suffer this, perhaps they are not using a standard menu and have had to write their own ... why dont they release this code if they have?
This article describes the 'as design' behaviour: Menus for Notification Icons Do Not Work Correctly
EDIT
We are using C++/Win32 not forms, so we use TrackPopupMenu.
Are you using ContextMenu or ContextMenuStrip?
Your saying that opening the ContextMenu on a trayicon focuses all app forms?
I have not experienced that, though I use the newer ContextMenuStrip class, not ContextMenu for my trayicons.
EDIT: Would be nice to know if you are using Windows.Forms or WIN32, or MFC or what.