Continuing our tips on new features in Notes 6, this one talks about how to have an "Edit Document" button in your views that is only shown when the user is actually on a document (something they can edit). But even if you're not yet on 6, this tip can help you out in your Notes 5 environment.

Most of the time when a view is designed, we put an "Edit Document" button on the view so users can click on the button instead of pressing CTRL+E or opening the document in read mode and then switching to edit mode. If the view is categorized, though, there are rows that are not documents. If you click on the "Edit Document" button while on a category row, you get a "Cannot execute the specified command" error. There is a way to prevent that error from happening. If you check the UNID of the document, Notes will return a string of zeros when you are on a category row. So your "Edit Document" button, instead of having just the formula you would expect...

@Command([EditDocument])

...you add some additional logic to the button...

UNID := @Text(@DocumentUniqueID);
@If(UNID = @Repeat("0"; @Length(UNID)); @Prompt([OK]; "Category"; "Please select a document"); @Command([EditDocument]))

The button now checks what the UNID of the current document is. If that is a string of zeros, then give a message to the user that they are on a category and not a document. If it isn't a string of zeros, edit the document. That makes the error message a little friendlier while still allowing all the functionality that used to be there.

Did you say something about Notes 6?

In Notes 6, you can take this one step further. You can actually have the button not even appear to the user if they're on a category. That's a nice feature to take advantage of. Your users won't even have a button to click on if the "time isn't right".


To implement the showing and hiding of buttons in Notes 6, you need to enable a new view property called "Evaluate actions for every document change". You can see that in figure 1. This tells the Notes client that every time a new row in the view is clicked (or the up/down arrows are pressed, which changes focus), the action buttons should be refreshed. So, you can apply a hide-when formula to an action button and it will be refreshed. Using that same logic as above, if the UNID of the current "document" is a string of zeros, then we are on a category line and should hide the button. The action button hide-when formula becomes:

UNID := @Text(@DocumentUniqueID);
UNID = @Repeat("0"; @Length(UNID))

Now, as you move up and down the view or click around to select different rows, the action buttons will be re-evaluated (if that view setting is enabled) and the button will be hidden if you are currently on a category row.

If you didn't figure out the performance hit already, it comes from the fact that all the hide-when formulas on all the action buttons will be re-evaluated every time you move in the view. If you only have a couple of action buttons, the performance hit may not be noticeable. But if you have a bunch of cascaded action buttons with hide formulas, there could be a noticeable delay moving from one document to another in the view.