SnTT: Open the Database Containing a Doc Link

This probably belongs on Alan Lepofsky's site - and maybe it's already there - but I thought it was pretty handy when I figured it out.

I've had lots of occasions where I get a doc link, open the linked document and then want to open the database to see other related documents. I had always gone to my workspace, located the icon for the database I just opened and clicked it to open the database. I figured there had to be an easier way and I finally found it:

Click View | Go up to Parent View.

This opens the view that contains the linked document. Action buttons can execute @Command([GoUpLevel]) to achieve the same effect.

This is probably not news to a lot of people but I just learned about it. Now, if only you could right click on the open document and see the option there...

Technorati: Show-n-Tell Thursday

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: Show-n-Tell Thursday