This example uses a button and code behind the button to prompt the user if they have selected a category instead of a document within a view to edit. It tells how to error trap and refocus the user on the correct behavior. 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...
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]))
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.
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".
Note: make sure your users are all right with this before simply implementing it. Having buttons appear/disappear may be bothersome to users, which could end up causing more headaches than it solves. This feature will also have a performance hit (you'll see why in a minute) which may be too much for your users to take. 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))
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.
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.
