Home/ Questions/Q 93743
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T23:23:32+00:00

I’m not a Notes programmer, however, for my sins, have been working on some

  • 0

I’m not a Notes programmer, however, for my sins, have been working on some Notes features for an in-house project recently. I need to enable/disable editing of a field depending on circumstances. It seems to me to be a fairly standard feature, I need, but I can’t find any information on how to do this anywhere.

In form setup (and other field’s onchange) code, something like the following:

if some requirement = true then     textField.enable = true else     textField.enable = false end if

I’ve seen other places where there’s a workaround of conditionally hiding paragraphs based on some code, having 2 paragraphs with opposite hiding conditions, one with an editable field, the other with a computed field. However, I don’t know enough about Notes to see how this is implemented (I can see it done on other forms, but there seem to be some ‘magic’ steps within Notes which I either can’t see or don’t get).

[EDIT] The reply from Kerr seems to be what I’m looking for, but I still can’t find out where the InputEnabled property is located. Should have said in the initial question, I’m using Notes 7.0.3.

In fairness, it doesn’t matter what the circumstances are for when to enable/disable the field, it’s just some boolean condition that is set, in my case only on form loading so I don’t even have to worry about this changing dynamically while the form is displayed.

I’ve got a few issues with Notes, my largest bugbear being that it’s so tied so tightly to the Designer UI, which is utter shite. I can do this sort of thing programmatically in most GUI languages (C#, Java, Delphi, even VB), but I need to open property boxes in Notes and set them correctly.

This would be OK as an optional method, but forcing you to go this way means you can only work as well as the IDE lets you in this case, and the IDE here seems to actively work against you. You can’t open multiple functions/scripts, you can’t swap from one script to another without going back to the menus on the left, you can’t easily search the codebase for occurrences of variables/fields (and believe me, this is a major failing for me because either Notes or the internal codebase in my case seems to make a lot of use of global variables!), you can only work with fields through the property boxes that get displayed, you can’t edit code in Designer while debugging through the main Notes client.

While the Java side of the coding is better than LotusScript, it’s still fairly crappy (why can’t you debug INTO Java code?? Why do you need to re-import JAR files for each Java class, does each class have a different CLASSPATH???). Possibly this was improved in Notes 8, I hear it’s based on Eclipse. Does anyone know whether this is true or not?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. It would help to hear more specifics about the ‘circumstances’, but the most common way to handle this is to use a hide when formula on the field you want to enable/disable.

    Technically you are not enabling or disabling the field, just hiding it, but usually that works just as well.

    Since there are few events to work with in Notes, developers commonly use the document refresh as the ‘event’ to cause the field to hide or show.

    Let’s assume you have two fields called TriggerField and Subject. Say also you want to disable the Subject based on a value in the TriggerField. The easiest way to do so is to set the TriggerField as a Dialog List type and check the ‘Refresh fields on keyword change’ option. This means when the value of the dialog list changes, the entire document will get refreshed.

    Then in your hide when formula for the Subject field, you specify your criteria for when to show or hide that field. Anytime field values change, followed by a refresh of the document (i.e. form), that hide when formula will be re-evaluated.

    There are other ways, depending on your circumstances, to solve this problem. If you want to let the user refresh the form themselves, put a button on the form that calls the @Command([ViewRefreshFields]) command. You can add any other formulas to that button before the refresh command if you want to make other changes to the form at the same time.

    Another option is to make a certain field display-only. Then create a button that runs LotusScript to allow users to change that display-only field. In the script you can propmt the user for a value, set the display-only field, and then call for a document refresh.

    • 0