Another year gone in the twinkling of an eye. It's time again for the second annual Yellow Day!
Again, I've something useful, not absolutely new, but useful (Fun with $FormulaClass, Dan Velasco, DominoPower Magazine, August 1999, that's exactly 10 years!):
Notes views showing design elements instead of documents
The "trick" is to change one special item of the view: $FormulaClass. Usually it is always 1, and this means: show documents. Other values cause other elements to be shown. Valid values and their meanings are documented in the file include\nsfnote.h, which belongs to the IBM Lotus C API Toolkit for Notes & Domino.
|Note Class Type||Hex Value||Decimal Value||Comments|
|NOTE_CLASS_INFO||0x0002||2||notefile info (help-about) note|
|NOTE_CLASS_DESIGN||0x0020||32||design note collection|
|NOTE_CLASS_HELP_INDEX||0x0080||128||Notes product help index note|
|NOTE_CLASS_HELP||0x0100||256||designer's help note|
|NOTE_CLASS_PRIVATE||0x1000||4096||Private design note [...]|
|NOTE_CLASS_DEFAULT||0x8000||32,768||MODIFIER - default version of each|
|NOTE_CLASS_ALL||0x7FFF||32,767||all note types|
|NOTE_CLASS_ALLNONDATA||0x7FFE||32,766||all non-data notes|
Since there is no way to modify the
$FormulaClass item directly in the Domino Designer, we need a small LotusScript
elements\0x7FFE all design elements")
' adopt view title
' shows all non-data
The version, I've used to modify all
views in the demo database, is stored in the "Configure design elements
So many types, how to tell them appart?
To show sensible types in the views,
I had to try a lot. I've started with the following article in the Lotus
Domino Designer Wiki by Andre
a Notes view list design elements (using LotusScript or Java).
But I had a problem: some of the formulas
work only in a given note class - especially the formulas for forms, views
and agents don't work well in a view with all design elements. With some
other design elements, the note class is unique, so there is no formula
In these cases I tried to identify the
type of the design element using the $Flags, $FlagsExt and other items.
But to be honest: I don't think, the current formula works correctly in
all cases. If anyone encounters such a case, please notify me.
Since the resulting formula became quite
big, I don't insert it here, but reference to the Type column of all views
(and starting with Domino Designer 7 there is a shared column named "Design
What can I do with these views?
In the "Design elements\0x7FFE
all design elements" view I've added some useful columns.
Have you ever spotted an error in server
log, referencing only a note ID or unique ID? There you are...
Have a quick overview for all design
elements, if they inherit from other templates (and which templates), or
if a design refresh is prohibited for those elements. Did you have the
case that in a Notes client some design elements didn't show? Perhaps somebody
has set up a language for them?
And in some cases it's useful to quickly
discover, who has changend something, when were the last modifications,
why is the empty database so big etc.
Recently I had to create a configuration
form with a field, in which the user should be able to select a public
folder - no views, no private folders. I started using session.CurrentDatabase.Views,
iterated through it, collecting only public folders in a list. This list
should be stored in a "Computed for Display" field, but since
there were many public folders, it didn't fit into a text field.
But using the "trick" and
a fitting selection formula, I created a view showing only public folders.
Then I created a action hotspot with a @PickList to let the user select
Using single category lookups you can
even use the "general purpose" views in the demo database (for
And that's all?
By far not! When you see something,
you can modify it (more easily). Think about an action or agent, which
clears the references to other templates in selected design elements. It
has just to delete the $Class item. Or another agent could remove the $Language
item. Or it could clear the "don't refresh the design" flag by
removing the upper "P" from the $Flags item.
You can easily create more specific
views showing - say - only agents. Then you could add other columns for
the agents' details. You can get a lot of details from the $Flags and $FlagsExt
items. Valid values and their meanings are documented in the file include\stdnames.h
of the IBM Lotus C API Toolkit for Notes & Domino. I've extracted the
most important lines and put it into a table, which I've added to the download