Friday, June 1, 2007

SnTT: Update to Single-View User Interface

I know it's Friday but this was so cool I just couldn't wait until next week.

About a month ago I posted this in which I explained how I got around some limitations with embedded views that are displayed in framesets. It is, admittedly, not the most elegant solution because it requires the user to click a button to update the embedded view. It also requires some inter-frame communication, for which I used an environment variable. I had thought about using JavaScript (and actually saw another post that might have been useful for that) but didn't get a chance to do anything about it.

But that was before Slawek Rogulski posted to say he knew how to make this work using a single frame and form. Read the comments on the first post and you'll see I was a little skeptical. Well, I got it to work. And it's really pretty simple.

1. In your form that contains the embedded view, set it so it has a Form Header with a height of Fit to Content. You may also want to set a border of 1 pixel to ensure that everything you want in the header is actually there (you can turn that off once you get the header content correct).

2. Select everything on the form that is above the embedded view and cut it.

3. Move the cursor to the top of the form and paste the cut content back in. That should place it in the header area.

4. Save the form.

Now you can just compose a document with that form or place it in the top frame of a two-frame frameset (if you want the bottom frame to be a preview frame). The scroll bars on the embedded view will appear when necessary and will display both the scroll up and scroll down buttons. Plus, there is no need for inter-frame communication or for the user to click a button after selecting field values - once you select a value in the "trigger" field, the embedded view can be updated automatically.

Apparently the rendering engine can account for the height of a form header when displaying the embedded view. If you don't use a header, it does not know the height of form content above the embedded view; as a result, the scroll bar is not rendered correctly (documents in the view can exist below the bottom edge of the application window and there is no way to see the view entries, although you can press PAGE DOWN to move the highlight to them and press ENTER to open the documents).

Thanks a lot, Slawek. This provides a great solution for simple interfaces and is a lot easier than what I initially came up with. He also said he's used this in cases where the embedded view is computed (I didn't need that capability). And it's another great example of the "power of community".

Technorati:

1 comment:

Paul Gagnon said...

Whoa, this is slick and it works.

What I need is a view to list the customer docs, a target to preview that doc, and then struggling to get another frame to show all the different response docs. Needless to say it was not working. With this it got simplified and streamlined. Got rid of that extra hideous frame that wasn't working anyways.

Now the view of customer docs is in one frame for quick navigation as a list, the preview on the right shows the doc updated with a header, embedded single category view below it, and presto, it achieves the correct effect, all sized properly with one scroll bar if needed. Also it allowed me to make good use of screen real estate from left to right and no wasted white space.

Thanks again!