Spanky's Place

I know it is a day early for a SNTT post. If that really bothers you, come back tomorrow. I'll wait.

This post was inspired by two posts pointed out to me by Nathan, and a few phone calls with the Domino Guru himself, Mr. Chris Toohey. This is also an example of how well our community can collaborate to find a solution to a thorny problem.

The first post, Embedded Windows Explorer/File Browser for remotely-stored file resources in the Lotus Notes Client UIM, gives a basic explanation about the business need for using some form of an embedded file browser. The second, Sorting Hat - Embedded File Browser in the Lotus Notes Client UI - Flash Preview, gives a really good demonstation of the cutting / pasting & drag and drop capabilities available when using an embedded file browser.

I immediately got in touch with Chris, because this is something I can use right now, to solve business problems today. However, putting this to use is not really as simple as it should be.

The core of the solution relies on using an embedded control within a form. The embedded control has the official name of "Microsoft Web Browser"; with a class name of "Shell.Explorer.2". The primary purpose of the control is to allow a developer to embed a web browser control into an application. Savvy Domino developers (such as Tommy Valand, Tim Tripcony, or Nathan Freeman) will quickly realize that such a control should be able to pull double duty as an embedded file browser. And it can, (with a little bit of tweaking).

The control will, by default, work perfectly for local system files. The problem however, it that we need to use it to access mapped drives / network shares. Microsoft sees this as a security problem, and the February 2005 security hotfixes (and subsequent service packs) include security changes which effect embedded Microsoft Web Browser controls when interacting with mapped drives / network shares. The purpose of these changes is to disable drag-drop and cut-paste operations for such embedded controls. However, these security changes are not design or code changes; but rather changes to configuration settings. (Which, IMHO, is how it should be).

If you search the web for documentation on how to set the control to work with mapped drives, you will (as did I) find a whole bunch of solutions which involve custom log in scripts, registry changes, and even some (really scary) VB code samples which make real-time, undocumented changes to the registry. This is absolutely unacceptable to me.

Here is a fun idea! Tell a customer (while keeping a straight face) that in order to provide them with the functionality they want you are going to need code which can run with unrestricted access on all of their employees desktops which will modify the registry settings in real time. With no back out capability. And no documentation. Oh, I'm sure there are some folks who see this as a reasonable solution, but I'm not one of them.

So I set about the task of testing every single custom security configuration setting option (with restarts between tests) in order to find out what the settings need to be.

I'm happy to say, I figured it out.