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).
Related
My custom Windows shell context menu handler works like a charm, for all Windows versions from XP to 7, but on Windows 8, 8.1 and 10, installing it breaks the Win+X menu (sometimes called "Power user menu", or "Quick Access menu", or "WinX menu"): when hitting Win+X, the menu is displayed as expected, but its items do not work anymore (nothing happens when I click on them), except for the last four items at the bottom which still work as expected ("Search", "Run", "Shut down/Sign out", "Desktop"):
I quickly found out on Google that it was a well known issue for a great number of shell extensions that were not "compatible" with Windows 8/10. But sadly, I only found application users talking about this issue and its "solutions", and no developer talking about this. And the two "solutions" proposed by these users were:
Unregistering this shell extension
Uninstalling the app that registered this shell extension (which leads to solution 1...)
See for example this, this, or this to read people talking about this issue.
Note: my shell extension is applied for the * file type, which means all files.
Several days later, I found the cause of this issue in the shell extension source code, so I thought it would help other developers to share it on StackOverflow, as a self-answered question (I didn't find this question). See answer above.
I first looked at the shell extension sample code provided by Microsoft (which doesn't cause this issue), compared it with my code, and progressively replaced parts of my code with Microsoft's code and testing it after each replacement.
I found out that what prevents power-user menu to work is what you return in method InvokeCommand() from IContextMenu interface: if your extension cannot handle the given verb, it shall always return E_FAIL so that Windows tries with other implementations of IContextMenu (see Microsoft documentation for more details). It seems that when a power-user menu item was clicked, Windows first called my extension (* file type), then since it didn't return E_FAIL for this unknown verb, Windows thought that my shell extension has processed this event, so it didn't process it through the nominal power-user menu callback.
By the way, three things seem very weird to me:
Why does Windows even try to process this power-user menu event with a shell file extension? Is this menu coded using the same design/mechanism as any other Explorer's file contextual menu?
Why does this bug didn't produce more side-effects yet? I mean this should have broken the whole shell extension system right from the beginning, no?
Why do so many applications has this bug? (meaning why so many applications do not return E_FAIL as expected?). It's been a while now that I've written this code, I can't really remember where it comes from, but I guess it comes from a Microsoft sample or any Microsoft employee tutorial (far too Microsoft-oriented to be coded by yourself). If it's the case, that may answer the question why so many shell extensions cause this issue...
I would be interested if someone has some ideas to share about this subject!
By the way, I hope my post can help other developers. When looking at the new Microsoft example that works like a charm, I was first afraid having to rewrite all my shell extension from their sample without knowing what was wrong in my code!
I participate in development of a site that has a significant number of users who view our site through the AOL Desktop v9.7 for Windows - which spawns browser windows inside itself. When debugging, I don't have the tooling I would normally be able to invoke (for example Chrome's Developer Console; Firebug; MSIE's F12 developer tools).
When inside AOL Desktop, I don't appear to have any of these, or anything similar. Is there a developer mode or console I can invoke, unearth?
What I meant in my comments, you could just use a very decent JavaScript debugger with manual DOM inspecting features, which comes with Visual Studio ([EDITED] including the free edition). With some tricks, it does work for AOL Desktop, too (what an amusing piece of software that is, BTW :) Of course, this is not the same as IE's F12 Tools, it lacks the interactive features like visual DOM tree, CSS tracing etc. But it still allows to step through the code, watch locals and objects, evaluate expressions and access DOM elements. It's an invaluable tool and I use it a lot for projects where we host the WebBrowser control. After all, that's what AOL does, too. Anyway, if you're already familiar with this, just give this post a smile and disregard it. Otherwise, read on :)
I tested the following under Win7 SP1 VM with IE9, Visual Studio 2012 Pro (Update3) and the latest AOL Desktop 9.7. [EDITED] It also works with the free edition, Visual Studio 2012 Express for Desktop, Update3.
The only major obstacle was that in about 20 seconds upon entering the debugger, AOL Browser used to restart itself, thus disconnecting from the debugger. A workaround for this was to close AOL and delete the following files:
"C:\Program Files (x86)\AOL Desktop 9.7\"
shellmon.exe
shellmon.ini
shellrestart.exe
Then, I used the following basic HTML file for debugging purpose (as "debug.html" in the root of localhost):
<!doctype html>
<html>
<head>
<title>Debugger Test Page</title>
<script>
function debugPrompt()
{
if (confirm("debug?"))
{
debugger; // breakpoint
alert("after debugger");
}
}
document.onkeydown = function()
{
if (event.altKey && event.ctrlKey && event.keyCode === 'D'.charCodeAt(0))
{
event.cancelBubble = true;
debugPrompt();
return;
}
}
</script>
</head>
<body>
<button onclick="debugPrompt()">Debug</button>
</body>
</html>
Here's what I did exactly:
Made sure Script Debugging is enabled in IE settings for both Internet Explorer and Other:
Made sure [x] Script is checked in VS2012 Debugging Settings, Just-In-Time section ([EDITED] this feature is missing from VS2012 Express, but it isn't really important):
Ran AOL and navigated to localhost/debug.html.
Ran Visual Studio and attached to the aolbrowser.exe process (with Script as the target kind of code), via Debug/Attach to Process menu:
Went back to AOL and hit Ctrl-Alt-D (invokes the "debugger" prompt in my JavaScript listed above). The next thing, I'm in the VS Debugger right at the debugger; line of code. At this point, all usual debugging features are available. Note the Immediate Window panel and the Watch1 panel. Also, instead of hard-coding breakpoints with debugger keyword as I did, it's possible to use Visual Studio Solution panel (once the debugger has been attached) to select one of the JavaScript files loaded by the page and toggle breakpoints interactively.
Right now, I don't have Visual Studio Express 2012 to verify if the same is possible with it, although I assume it should be. I'll give it a try a bit later.
[UPDATE] Almost all of the above applies to the freely available Visual Studio 2012 Express for Desktop w/ Update3, with one exception: Just-In-Time Debugging option appears to be absent. This is not a show-stopper though, as it is still possible to attach to the running AOL process and debug the currently loaded page the same way.
PS. And thank you for your voluntary bounty offer on an unrelated question of mine, that is a really nice gesture.
Just in case anyone comes here looking for information: the newest 9.8 version of AOL Desktop now includes Chrome's developer tools, which open in a new window when you press F12.
I have a COM DLL, coded in Delphi. It should be invoked via an Active X control when a web page loads in MS IE (via soem JavaScript on the page).
Btw, this all works fine with an existing serial port interface, but I am recoding teh DLL to read from USB; all else is unchaged.
It works fine in the Delphi IDE, but not "in the field". The active X control should request it to read some input from a USB port and should then send that to the web page.
Reading from the USB device works, as I can open Notepad and see the value being written there.
The DLL will display a form, and a dialog box, and will write to the system debug trace. Since I am seeing none of these when loading the web page in MS IE, I think we can assume that Aective X control is not calling into the DLL.
In MS IE I have enabled all Active X options.
in c:\Windows\System32 (which is equivalent to c:\Windows\SysWOW64), I have regsvr32.exe -u my_dll.dll and then regsvr32.exe my_dll.dll both of which the system announced to be successful
I searched, and there is only one copy of my_dll.dll under c:\Windows
and it has the correct size and date/time
my %path% is %SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem; for system and empty for user
Any idea what I am doing wrong? Or how I can go about tracking it down?
If you are loading the ActiveX control in webpage through javascript, you will have to package the control for web deployment. See this example for how to do this in your javascript and check whether you have done properly it or not:
Calling Activex Control 's Functions from javascript
Once you do the above thing correctly and open your website in IE, the web-page will at least "load" the ActiveX control. Beyond that, you can display message-boxes or write logs in your Delphi code to track down the actual coding issues.
As the title says, I've got a word template with macros that does not run properly in the new Word version from Office 2011 for MAC.
The thing which seems to not work properly is the following code:
Sub Document_New()
myForm.Show
End Sub
The same is with Document_Open()
It doesn't seem to run this code on the Mac version.
Does anyone know why this won't work on the Mac, or if there's another way around to emulate the document_open/document_new function?
EDIT: The document is in the .dot format. And I tried to save it to .doc, then the Document_open() worked just fine, so it seems to not be working in the .dot format.. And Document_New() is not running in .doc since its not a new templatefile based on a document..
EDIT 2: Seems like it was a once only with the Document_open on .doc files. I cant make it work again. So weird! The only event I get working, and this is only when using the .doc file format, is Document_Close() - this works everytime...
EDIT 3: This is just getting weirder. I made a new .doc document with the following code:
Private Sub Document_Open()
MsgBox ("BlaBlaBla")
End Sub
The code only runs if the Visual Basic Editor is open BEFORE I close the word file and try to open it again. If I close the Visual Basic Editor and then the word file, and then open the word file; The code is not run.
??
All VB application events are suppressed if you have the VB-editor active, and the current project is not running. It is an intentional behavior, to prevent unwanted code execution, hence not debuggable.
I have used Workbook_Open() (in Excel), and I can only see it working on newly open Excel Xls (xlsm on 2010), from a non-open VB-editor Excel application.
It will work if you have other doc/xls already open, but not if vb-editor is up.
Have you checked whether Macros are allowed? Do you have generated a certificate and setup your application as a trusted source?
I'm having similar issues. It seems that MS removed support for the Document_New and Document_Open functions in the Word object model for Word 2011. See http://mac2.microsoft.com/vb/1033/Word/html/womscChangesBetweenWord2010and2011.htm
I get the infamous "Dialogs must be user-initiated" Security Exception when I try to print some stuff in Silverlight. As you can see, the dialog is as user-initiated as can be:
John Papa couldn't help me much out neither, because I don't have any breakpoint set. Mr MSDN thinks it could also be that I'm just taking too long, but this is a demo application just as simple as can be.
Any ideas? I guess it's a Visual Studio quirk, maybe some extensions interfering, as things seems to work when I launch the application outside of it. I first thought maybe the Code Contracts are interfering with their IL weaving, but they are deactivated for this project.
Update: This is just a simple Silverlight application that runs locally from the file system. When I do "Start debugging", Visual Studio creates a hosting HTML file containing the Silverlight app in the Debug resp. Release folder of the project, launches the Internet Explorer with that HTML file and attaches the debugger to it.
Update 2: I also get the same error when I create a web project to host the Silverlight app and create a virtual directory for it on IIS.
I might also want to add that I don't have problems with printing in other Silverlight projects regardless of their hosting scenarios.
Update 3: I downloaded FireFox and it works, I don't get the error when I debug with it. So it seems to have to do with my IE8. I uploaded the solution:
http://dl.dropbox.com/u/10401470/Code/Demos/PrintingDemo.zip
I wonder if anyone can reproduce?
Anyone got an idea to which team I should file a bug report? Silverlight team? IE team? VS Debugger team?
I'm able to reproduce this. You have handled the Click twice, once in XAML another time in code. See your MainPage.xaml
<Button x:Name="PrintButton"
Content="Gotta print 'em!" Margin="8"
Click="PrintButton_Click" />
Don't feel bad about it. I did it last time through a misplaced Print inside a loop.
I've also experienced this strange behaviour. A standard button click event immediately invoking an OpenFileDialog. It would frequently generate the same error when being debugged but would eventually be coaxed in to working when the button is clicked several times.
However when built as a release (or perhaps simply by running the same Xap without a debugger attached to the browser) the problem would go away.
Try to remove
if(SightPaleceListBox.Items.Count > 0)
I had the same problem and found out that the reason was this following line:
cnvsMain.Children.Remove(PrintPagePlaceHolder);
cnvMain is on the page that the user pushed the Print button on (I was trying to remove it from that page in order to add it to the canvas that I was going to print).
My tip: try to comment rows one by one, until you find what row causes the problem. Than try to work around it.