In this application, we see how the Microsoft Web Browser Embedded Object Control can be used in the Lotus Notes Client to provide programatically-defined File Browsers. Pretty slick for "storage" of large files, as this can allow you to control the target storage directory via application logic while allowing storage of large files on a File Server.

Please Note: There are two (2) "document" Form Design Elements - the hidden "document" showing the initial demo displaying two (2) Microsoft Web Browser Embedded Object Controls and allows Drag-and-Drop between them. The active "document" is used to maintain a full-screen File Browser; it's URL calculated in the "url" NotesItem, which uses the "filestorebrowser" Form Design Element for UI presentation.

For an added bonus, check out the About tab!

Feedback and suggestions are always welcome!

Thanks,

-Chris

So last night I played around with the Embedded Windows Explorer stuff that I mentioned yesterday and came up with the following - which I'm calling Sorting Hat:

View demo in full screen.

In this first really simple demo - we can see the embedded Microsoft Web Browser control, which is "activated" in the PostOpen event on the UI Form Design Element and uses the value stored in the url NotesItem of the NotesDocument. This allows us to not only access remotely-accessible file stores directly from a Lotus Notes client UI, but also allows drag-and-drop from this "widget" into the UI document - pretty slick!

View demo in full screen.

In this (yet again really simple) demo - we can see two embedded Microsoft Web Browser controls, again "activated" in the PostOpen event on the UI Form Design Element and that each use their own NotesItem from the NotesDocument for it's control (url and url2 respectively). The big difference in this example, you can drag-and-drop from one "widget" to another "widget" to move files across remote file stores - really slick!

Now, there are some issues with this approach that I'll get into in the next few days - the biggest being that the UI Document needs to be in Edit mode from what I can tell to run the Microsoft Web Browser control. I'm working around that stuff now and expect to have this example database available for download pretty soon!

Comment here with suggestions, thoughts, comments, and things that you want to see!

I had a request from a manufacturing customer who was asking for a document library, which would be used to store CAD files (read: too-large-for-logic drawings). I immediately didn't want to store these mammoth files in a Domino database container, as 1) the Full Text Index really wouldn't do any good for CAD files and 2) well - duh - there's a long list of reasons not to bring 500MB files as attachments into a Domino database container - and that's not what I'm getting at here... so I'll move on.

After some questions, I found that the customer was asking for a "document library" because they wanted to track specific drawings against specific projects and other categorizations that the standard File Store architecture would no longer facilitate. They wanted to be able to apply category labels to grouped files. All things that you'd want to do in a typical "document library" - but I again didn't want to store these large files in Domino. So I thought about using some sort of embedded, programaticaly-accessible Windows Explorer widget - which would allow me to display the "linked" documents, while storing the labeling information on the actual "container" UI document. Simple enough right? Now to just find a Windows Explorer widget... that I could modify within the Lotus Notes client container... in release 6.5.

Got some good feedback from people via my Twittering the question (thanks Steve and Andrei!!!) but me being the stubborn me, there had to be a simple way of doing it... and possibly with the Microsoft Web Browser Control (which was the closest thing that I could find to a Windows Explorer Object). So I googled "Microsoft Web Browser Object" + Lotus Notes...

Now, I should have known that...

1. I was getting the idea that this was possible from somewhere.
2. That someone like Tommy Valand would already have done it!

The good news? Well, using this approach, I was able to give my customer a quick-since-it-was-already-written solution:

I simply modified their current "project" Form Design Element and added (on a new tab called File Resources) a field called url and am embedded Microsoft Web Browser Object (Control).

Pretty simple right? Yeah - the only this that was missing was the logic to control the embedded object - which I added to the PostOpen event:

Sub Postopen(Source As Notesuidocument)

 Dim browser As Variant
 Set browser = source.GetObject("Microsoft Web Browser")

 If (Len(Source.FieldGetText("url")) > 0) Then

  If (browser.width <> 400) Then
   browser.width = 400
   browser.height = 400
  End If

  Call browser.navigate(Source.FieldGetText("url"))

 End If

End Sub

So pretty basic stuff all around - when the "project" document is opened, I check to see if there's a value defined in the url field. If so, launch my embedded "File Browser" of sorts and show the contents!

If there's an interest in having an example of this "approach", let me know and I'll put one out here.

I find myself using wizards to create or modify documents in my day-to-day Lotus Notes applications - their utilization allows me to drive the user through the applied business logic while providing them with a simple user interface. I think it's both great UI design practice as well as an eye-opener for us Lotus Notes client developers who think that the only way to create and modify the NotesDocument is via it's form NotesItem-designated Form Design Element.

But enough of that, let's get to the goods:

Open this database in the Domino Designer client and we'll see the (app/wizard/wizarddocgen)|wizarddocgen Form Design Element. And that's where the fun begins! ;-)

Author's Note: I'm certain that I will hear about this from people who disagree - but that's what the comments are for I suppose...

I was actually on an interview a few years ago for a rather big-name product development company, when they brought in their lead developer to ask me a few technical questions. One of the things he asked me, was whether I developed common design elements or used individual (per Client Type) elements. In case I lost you there, do I have one Form design element for the Lotus Notes client, Web Browser client, and Mobile Device client types. In horror, I said "No - that's insanity. The only way you could pull that off is with hide-whens or subforms or something just as resource-consuming..."

His repsonse, which added shock to my horror, was that "[doing that] was [his] biggest pet-peeve" and that the products that they developed all had common Client Type design elements. He wanted to cut down on the maintenance of all of these design elements by having single design elements per all Client Types.

While such a thing can work - I don't recommend it. In fact, I'll be a little more stern with my suggestion: Don't do it!

An application that is delivered via both Lotus Notes client and Web Browser client has major environment and usage considerations. Creating multi-client applications (especially when you factor in the Mobile Device client type) requires both an understanding of the application (what it does, and how it's being used) as well as an understanding how the to-be-supported Client Types are going to work.

I can hit my application with a WAP browser, but I can't use the advanced JavaScript that my Web 2.0-based UI uses. Do I take that same design element and play the hide-when game until I've got some "You came in that thing? You're braver than I thought!"-Monster Design Element that no one wants to touch for fear that it'll break everything, or do I hide that design element from Mobile device types and create a WAP-friendly equivelent?

So, to recap. Don't be an asshat Create seperate design elements for your various supported Client Types whenever possible - which should be all of the time.