I’m working on an interesting little project at work right now. We use SharePoint to facilitate some workflow around our sales orders and purchase orders. But there’s currently no link between AX and SharePoint, so the sales and purchasing reps have to copy & paste information from AX to SharePoint forms. Not a huge deal, but a bit of a waste of time for everyone. So the idea was to add buttons to various forms in AX that would open a new SharePoint form, with certain fields pre-populated. I might write up some stuff on the SharePoint side of this later, but this post is going to be about the AX side.
The first (obvious) idea was just to launch an URL in the default web browser. And that works fine. Except that everyone is accessing AX through terminal servers. And, while IE is installed on those servers, the internet connection on those servers isn’t filtered the same way it is on end-user machines. So clever users could launch IE from AX, then navigate to restricted sites and possibly infect the terminal servers with malware. Which would be very bad.
My first thought was that there ought to be a way to launch IE on the end-user’s actual PC from the terminal server, but if there’s a way to do that, I can’t figure it out. (And it makes sense that there isn’t, really.) So my next thought was to launch the SharePoint site in a web browser control hosted in an AX form, with no address bar and no way to navigate away from that SharePoint site. Simple enough, right?
After a bit of web searching, I found this article on hosting an instance of System.Windows.Forms.WebBrowser in an AX form. I got pretty far with that, including preventing new windows from opening (which would allow them to break out of the control and into IE), and also preventing them from following links to other sites. But there was one key issue I couldn’t get past: the tab key and control keys wouldn’t work in the control. So the user wouldn’t be able to tab from field to field, or copy & paste information with Ctrl-C and Ctrl-V. I found a few references to this issue on StackOverflow and elsewhere, but no solutions that would have worked easily in Dynamics AX. (They mostly relied on doing things that would work in a real Window Forms app, in C++ or C#, but that I wasn’t going to be able to do in AX.)
So I punted on that, and decided to try just adding the ActiveX web browser control to the form. I’d never actually added an ActiveX control to a form; there’s a good overview about how to do that here. The most important thing I picked up from that is the “ActiveX Explorer” function that can be accessed form the context menu after you add an ActiveX control to a form. That’s how you hook into control events.
I managed to do everything I needed with the control:
- Prevent navigation outside the SharePoint site, which I can do by setting a cancel flag in the BeforeNavigate2 event handler.
- Prevent opening new windows, which I can do by setting a cancel flag in the NewWindow2 event handler.
And it handles the tab key and control keys normally, without any workarounds.
So that’s about it. ActiveX is a twenty-year-old technology, but it still works. As much as I would have liked to do something fancier, I can’t complain!