Posted by: Pedro Quaresma | April 17, 2008

Dynamically loading subforms

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.

Responses

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 …

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.

HTH
Thomas

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! :-)

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).

Thanks.

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 response

Your response:

Categories