I have encountered a "quirk" in Outlook 2013 when attempting to have Outlook open a new window for a search (when a button is clicked in my Outlook add-in). The search does not initiate; the search term appears in the box but only the inbox contents are displayed (albeit with highlighting of my search term if relevant to Inbox items). If I then change anything in the search box (e.g. add then remove a quote) it kicks off correctly (i.e. filters the Output to my search).
I cannot reproduce this issue in Outlook 2010, nor if I call the same code via a standalone EXE. Also, it works correctly if I launch the search to an existing Explorer window.
Here is my code (simplified):
OutlookApp := GetActiveOleObject(OUTLOOK_APPLICATION_CLASS);
OLNameSpace := OutlookApp.GetNameSpace(MAPI_NAMESPACE);
OLNameSpace.Logon;
objFolder := OLNameSpace.GetDefaultFolder(olFolderInbox);
objExplorer := OutlookApp.Explorers.Add(objFolder, olFolderDisplayNoNavigation);
objExplorer.Search(sSearchText, olSearchScopeAllFolders);
objExplorer.Activate;
...
While debugging, I have tried:
Changing the display options for the new Explorer window (olFolderDisplayNormal)
Calling ClearSearch before searching
Performing an alternative search beforehand
Even sleeping between calls :-o
I would like to hear of any suggestions for workarounds, or anything I have missed...
Thanks
Resolved by delaying objExplorer.Search() (by creating a new explorer and posting a message to the window, which then enacts objExplorer.Search). Ugly, but works :-(
Related
I'm developing a JavaScript addin for Office applications, e.g. Word, Excel and PowerPoint. At some point it should open a file that resides somewhere in SharePoint.
I want the url to open the correct Office application right away and for this purpose I'm using Office URI Schemes (see https://learn.microsoft.com/en-us/office/client-developer/office-uri-schemes?redirectedfrom=MSDN).
Depending on the logic in the app, I'm using two different techniques, which work perfectly when the addin is running in Word, Excel or PowerPoint on Windows.
Technique 1 (normal link)
Open Me!
Technique 2 (programmatic)
// Js pseudo code
button.onclick = () => {
window.location = 'ms-word:ofe|u|https://foo.sharepoint.com/path/to/file.docx'
}
As I mentioned, both these techniques works flawlessly on Windows. But when running the addin on e.g. Word Desktop on Mac, absolutely nothing happens. I've debugged the addin, by using "Inspect Element" to open up the console, but there's no errors or anything. It seems to me that the internal browser on Mac silently refuses to open the link.
However, if you paste the link into e.g. a word document, it will open the document if clicked.
Some thoughts:
is this related to the manifest.xml for the addin? (still works on windows without modifying the manifest)
do I need to enable something on Mac for this to work? (the Office URI Scheme page states these links should work on Office for Mac 2011)
Any input is greatly appreciated.
I found a workaround that works on Mac as well by using window.open(url).
My Outlook web add-in saves emails to an external application.Upon save, it will also write some custom information to exchange server using Office.js's customProps.saveAsync();. So next time the user open the same email, the add-in will look up the properties and if it is not null will remind the user the email has been saved.
Work like a charm in web browser(Office 365).
However in Windows Outlook desktop, the function performs strangely. If I save the email and then immediately move the email to another folder. The customProps.saveAsync(); will fail(nothing saved to exchange server). However, if I re-launch the add-in on the email before moving out to another folder, the custom info will be saved successfully.
Seems to me on Outlook desktop the custom properties will not be written to the exchange server immediately, instead, it will wait until it is being triggered(re-launch add-in etc I do not know the exact mechanism). However, if the email being moved to another folder right after being saved in an add-in, the pending function will be lost.
I found this describing seemingly similar behavior. So I then turned off the "cache" mode in outlook but the problem persisted.
I also tried using EWS's API to perform the "save custom properties", but the problem still persisted.
Am I missing somethinghere or it is Outlook desktop's bug?
You are not missing something - this is definitely a bug in Outlook Desktop. Thank you for reporting the issue. We are investigating and will work on a fix as quickly as we can.
As a workaround in the interim, you can switch messages within the same folder in order to trigger a save. The workaround you found of re-opening an Add-in may also work.
I'm trying to run some automation tests in my application but the UFT Hidden-mode notification tooltip is coming in front of the objects in the screen, preventing my tests to run.
I know I can un-check the option "Display hidden-mode notification tooltip" in Remote Agent Settings to fix this issue and it works fine on my machine after I do this, but these tests are executed in other machines, by other users in my company, and it would be a real effort to tell each and everyone of them to change this setting on their machine.
Is it a way to disable this checkbox programmaticaly instead?
EDIT:
Here is a little more detail on where this is affecting me:
I'm testing a Web application and in some of my test cases I need to download a file from this application. I do that by clicking on "Save As" in the context menu which is displayed on a notification bar at the bottom of the browser.
Following is the portion of code to perform such operation:
Dim brwBottom
Set brwBottom = Browser("brw_Bottom_Save_As")
If brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Exist Then
brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Click
brwBottom.WinMenu("wm_Selector").Select "Save As"
End If
This works fine on my machine because UFT notification is not being displayed, but in other machines where the UFT Notification is displayed, it overlaps the menu and my script is unable to select the "Save As" option. So, in case it is not possible to programmatically close this notification at runtime, is there any alternative solution to click on the "Save As" button, even with this notification overlapping it?
I managed to identify the UFT Notification tooltip and close it. With this, there is no more objects in front of the button I need to click and my script can be executed successfully.
Following is the code used. I'm not marking this as the acceptable answer yet because I am still waiting for my team to accept the solution, but this works.
Dim brwBottom
Set brwBottom = Browser("brw_Bottom_Save_As")
' To close UFT Notification Tooltip, if exists
If Window("regexpwndtitle:=NotificationWindow").Exist(2) Then
If InStr(Window("regexpwndtitle:=NotificationWindow").GetROProperty("nativeclass"),"UFTRemoteAgent") > 0 Then
Window("regexpwndtitle:=NotificationWindow").Close
End If
End If
If brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Exist Then
brwBottom.WinObject("wo_Notification").WinButton("wb_Selector").Click
brwBottom.WinMenu("wm_Selector").Select "Save As"
End If
Create UFT GUI test and include these three lines:
extern.Declare micLong, "WritePrivateProfileString", "kernel32.dll", "WritePrivateProfileString", micString, micString, micString, micString
extern.WritePrivateProfileString "RemoteAgent", "ShowBallon", "0", Environment("ProductDir") + "\bin\mic.ini"
systemutil.CloseProcessByName "UFTRemoteAgent.exe"
From ALM, run it on all your UFT machines.
Notes:
This will switch the flag that controls such tooltip to be off, so next time Remote Agent launches will read it and won't display the tooltip anymore.
The third line will kill UFT's remote agent for GUI testing which is in charge of the communication between UFT and ALM Client and this will cause an error in ALM's Automatic Runner (The RPC server is unavailable)... just ignore it. We need to kill it so it is re-launched next time we try to run a test from ALM (as mentioned above, new value for tooltip will be read)
EDIT:
I just found something interesting: this flag is actually saved in two locations:
mic.ini
RemoteAgentGUISettings.xml
but the one that actually makes the change effective is RemoteAgentGUISettings.xml (it seems they're switching from .ini files to .xml... which makes sense). In this case, the code will change a little, but the idea is the same:
filePath = CreateObject("WScript.Shell").ExpandEnvironmentStrings("%appdata%") + "\Hewlett-Packard\UFT\Persistence\Dialogs\RemoteAgentGUISettings.xml"
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.load filePath
Set nNode = xmlDoc.selectsinglenode ("//SettingsViewModel/IsShowBalloon")
nNode.text = "false"
strResult = xmldoc.save(filePath)
systemutil.CloseProcessByName "UFTRemoteAgent.exe"
This time I made sure it works ;)
I totally understand your pain because my projects also need to interact with IE download bar. Usually, I use SendKeys to handle download activity in different projects.
When download bar comes out, you can send ALT+N first to set focus on download bar, then send some tab keys to select on Save, and some Down Arrow key to select SaveAs.
In this way, you don't need to bother handle UFT notifications...
Sample SendKeys codes can be easily Googled.
Can you activate the desired browser with the following, and then try to do Save as
hwnd = Browser("title:=.*").GetROProperty("hwnd")
Window("hwnd:=" & hwnd).Activate
I am getting the error that appears in the title and I already check the security settings, I have everything enabled and the Add-in is signed. I put the screenshot of how I have the options. If I have everything enable why it can give security problems?
I am using windows 8 and office 365. And the add-in that is not working is a powerpoint add-in. I try also some solutions that appears in this thread but no one works for me: http://social.technet.microsoft.com/Forums/office/en-US/0b385af0-9856-4cfb-bc48-3369c3ce2ace/when-opening-ms-word-the-macro-cannot-be-found-or-has-been-disabled-because-of-your-macro-security?forum=officeitproprevious
I had the EXACT same problem with an addin which I developed for Powerpoint many years ago and now ran on some computers at my new company, but not others.
The support couldn't help me and Google couldn't really help me, but this thread came closest to describing my situation.
The only common denominator I eventually found was that 32-bit Office could run the addin, but not 64-bit.
So my solution was to go through the VBA source code and replace my declaration variables according to this Microsoft post:
https://msdn.microsoft.com/library/gg264421.aspx
Maybe that could help you as well?
Create a simple PowerPoint presentation and save it as pp_HelloWorld.pptx
Add the following VBA procedure
Option Explicit
Sub sbHelloWorld()
MsgBox "Hello World!"
End Sub
to a module in this presentation and save it as pp_HelloWorld.pptm
Close and reopen this presentation pp_HelloWorld.pptm and the macro will work from the Developer > Macros > Run option
Put the following custom ribbon code
<mso:customUI xmlns:mso='http://schemas.microsoft.com/office/2009/07/customui'>
<mso:ribbon>
<mso:qat/>
<mso:tabs>
<mso:tab id="mso_c1.2A492F1" label="New Tab">
<mso:group id="mso_c2.2A492F1" label="New Group" autoScale="true">
<mso:button id="sbHelloWorld" label="sbHelloWorld" imageMso="ListMacros" onAction="sbHelloWorld" visible="true"/>
</mso:group>
</mso:tab>
</mso:tabs>
</mso:ribbon>
</mso:customUI>
into a file called PowerPoint.officeUI
and put this file in the folder
C:\Users<username>\AppData\Local\Microsoft\Office
(this may be hidden initially)
Close and reopen this presentation pp_HelloWorld.pptm and the macro will work from the Developer > Macros > Run option
The macro will not work from the macro button New Tab > sbHelloWorld and gives the message -
"The macro cannot be found or has been disabled because of your Macro security settings"
Next Clear the Trusted Documents -
Developer > Macro Settings > Trusted Documents > Clear
The macro now works from the macro button New Tab > sbHelloWorld.
This works on Windows 10 with Office 365
I found that this happens when normal.dotm has become corrupt. So the best and quickest solution is to restore the normal.dotm from a recent backup.
I've just built an MS Outlook Add In using Visual Studio and Office 2010. I've installed it ok on 4 machines, but one user is getting the following error -
Error found in Custom UI XML of "...."
...
...
Failed to find Office control by ID
Everyone is running Windows 7 and Outlook 2010 - not sure why this person is having a problem. Can anyone suggest how to diagnose this?
For those having similar issues, you don't have to remove any add-in.
What is happening is: Outlook will try to load all ribbons (found in your ribbon xml) into any window the user goes to. Then it'll complain about not finding ID x or y.
Just make sure your GetCustomUI method in Ribbon.cs does not load the entire ribbon XML at once but rather loads it per fragment.
If you're not sure what IDs you need to target, use a breakpoint in GetCustomUI then start Outlook, surf different views (main, new email, new appointment, calendar...etc) in order to gather the IDs for the views wherein you need to show you add-in.
In my case, I needed Microsoft.Outlook.Explorer, Microsoft.Outlook.Mail.Compose and Microsoft.Outlook.Appointment.
Therefore I changed my GetCustomUI to:
public string GetCustomUI(string ribbonID)
{
switch (ribbonID)
{
case "Microsoft.Outlook.Explorer":
return GetResourceText("MyAddin.RibbonsForOutlookExplorer.xml");
case "Microsoft.Outlook.Mail.Compose":
return GetResourceText("MyAddin.RibbonForOutlookMailCompose.xml");
case "Microsoft.Outlook.Appointment":
return GetResourceText("MyAddin.RibbonForOutlookAppointment.xml");
default:
return null;
}
}
Of course, I had to break down my Ribbon.xml into the three XML files mentioned above. The result: Outlook will ONLY load the fragment needed for a given screen (appointment, new email ...) and will not complain about "not finding an ID on screen X or Y".
Finally, for those who are not sure why some users get that error while others don't: it's because of "Show add-in user interface errors" option (in Options -> Advanced). If that is unchecked then Outlook will ignore the malformed ribbon XML errors. If it checked, users will get related errors about your add-in (if any exists) and also about other add-ins.
If it works for everyone except one user. As #Brijesh Mishra mentioned check if the user has got any other addin and if he is having own quick access tool bar customized.
If he has got any of this then, remove the other addins and try to install or reset the quick access tool bar customization.
For all of you that use a Designer-based VSTO plugin, and not the XML solution.
I searched all the web for this problem, but only found XML-based solutions.
There's nothing for Visual Designer on the web, because in this case you don't have to override the "GetCustomUI" method.
Ribbons designed by using the Visual Designer return a RibbonManager by default.
This RibbonManager object represents all Ribbon (Visual Designer) items in the project and is automatically handled in background through the active window inspector.
So you don't have to write any special code to handle different windows.
To configure it correctly you just have to:
Add one extra Visual Designer Ribbon for every window the user goes to
in the Ribbon Object go under "RibbonType", open the checkbox list an only activate the corresponding window, where the ribbon should appear.
If there is more than one window checked in the list, Outlook trys to insert the ribbon in all the marked windows. Even if the corresponding window is currently not opened. That's the reason, why the error "Failed to find control ID" appears.
the actual fix for me was to separate the ribbon XML files containing the customUI and redirecting to the correct one in the GetCustomUI method (implemented using Office.IRibbonExtensibility)
in example:
public string GetCustomUI(string RibbonID)
{
switch (RibbonID)
{
case "Microsoft.Outlook.Mail.Read":
return GetResourceText("namespace.type1.xml");
case "Microsoft.Outlook.Mail.Compose":
return GetResourceText("namespace.type2.xml");
default:
return null;
}
}