Dynamically loading subforms

April 17, 2008

I’m sure many Notes developers have gone through this problem before: “I want to load a different subform after the form is loaded”. Unfortunately, Notes doesn’t let you do that, and so ways have to be found around this… layers, hide/whens, sections, programmatic tables, etc.

But let’s say you reeeeaallllyyy want to dynamically load a subform, for example, when the user selects a value from a dropdown box. Here’s a way of doing it, supposing the default subform is “sfm_Default” and the subform you want to load comes from that dropdown box.

1. Make your computed subform take the value of whatever’s on a computed field (called for example fld_WhichSubform)

2. Put the following code on a button that should be called (via JS for example) when the dropdown box (called for example fld_DropDown) value changes:

@SetProfileField( “fm_FakeProfile”; “fld_PSubForm”; fld_DropDown; @UserName );
@Command( [ViewSwitchForm] ; Form )

(Any unique key that will correctly identify the document will do for the @SetProfileField. @Username is but a suggestion, @text( @DocumentUniqueID ) could be used as well)

3. Give the following formula to your fld_WhichSubform computed field:

x := @GetProfileField( “fm_FakeProfile” ; “fld_PSubform”; @text( @DocumentUniqueID ) );
@If( @IsError( x ) | x = “” ; “sfm_Default”; x )

This is but a simple example, and more interesting/complex things can be done with it.

Note: for this method to work, the document has to be saved. A @Command( [FileSave] ) before the ViewSwitchForm might be necessary in some circumstances.



  1. Mt bem, pena que agora não esteja directamente a mexer em LotusNotes, mas certamente aqui às uns 3 anos atrás tinha dado muito jeito, nas alterações das BD’s do SQG.
    Bons velhos tempos …

  2. If the subforms use different fields, you could use a programmable table:

    Create a table with only one column and as many rows as subforms. Make it a programmable table, showing just one row at a time. Give the table a name, e. g. SubformTable. Give each row a name. Create a field $SubformTable. Changing its value to one of the row names, makes the corresponding row – and therefore subform – visible. Finally, create a DropDown or List or RadioButton or … field and make $SubformTable calculated. Its value should be the current value of the DropDown and the DropDown must refresh the form on value changes.

    One of the reasons for calculated subforms is that you cannot hide RichText fields. But using programmable tables, you can.


  3. Hi CR,

    Yeah, those were the days! 😉

    Hi Thomas,

    Yes, as I mentioned, programmatic tables will do the trick as well – most likely even better in most situations! 🙂 I just wanted to show this possibility as well. BTW, looking forward to attending your OOP session on ILUG. See you in Dublin! 🙂

  4. Hi,
    This method works great but what if user decided not to save the document after entering some of the data ( lets assume you already reloaded the form with new subform).


  5. kvr,

    As I mentioned on the end of the article:

    “Note: for this method to work, the document has to be saved. A @Command( [FileSave] ) before the ViewSwitchForm might be necessary in some circumstances.”

Leave a Reply to kvr Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: