I have a list of printers stored in a printer keyword section that have fields like the serial of the ink they use for each of their colours and such. I want to make it so when I create a new user form and say that they have "X" Printer, it will grab that keyword form and pull all the ink types that it uses and save itself on the user form.
#GetDocField is the method I know I have to use but I do not know how to acquire the correct form saved from a list of forms based on a selection I make on which printer the user has.
Use #DbLookup to get the data from printer documents.
FIELD ink1 := #DbLookup(""; ""; "viewPrinters"; "XPrinter"; "ink1"; [FAILSILENT]);
The line above reads item "ink1" in printer's "XPrinter" document in view "viewPrinters" in current database and writes it to item "ink1" in current document. You would copy every field this way. The view "viewPrinters" has to to have a first sorted column with the printer names.
It might be more efficient to define all fields you want to grab in a column separated by a special character and get them all at once with
FIELD allFields:= #DbLookup(""; ""; "viewPrinters"; "XPrinter"; 2; [FAILSILENT]);
You can stay with #GetDocField too if you read the document ID of your printer document:
_docId := #Text(#DbLookup(""; ""; "viewPrinters"; "XPrinter"; "";
[RETURNDOCUMENTUNIQUEID]));
#If(#IsError(_docId); #Return(""); "");
FIELD ink1 := #GetDocField(_docId: "ink1");
It might be even more efficient to use LotusScript instead. But i assumed from your question you prefer a formula solution.
Related
I am working on some LotusScript code and came across this syntax to access a text field value: textField(0). I checked this field's properties in the design and it has the type of Text and doesn't allow multiple values. But why do we use the index to access this field value? I need to describe what the code is doing so it makes a difference between "get the value of textField then do something" vs. "get the first element of textField then do something".
The LotusScript expression document.textField is a shorthand form of document.GetItemValue("textField"). As explained in Designer Help, this expression always returns an array of strings for text or text list fields. That's why one has to use document.textField(0), or document.GetItemValue("textField")(0) for that matter, to access the first (and possibly only) element in the returned array.
An important thing to remember is that just because the field properties say that multiple values aren't allowed today, they might have been allowed in the past. Nothing gets "fixed up" in old documents if you change the properties in Domino Designer. Your code always has to consider that possibility.
And for that matter, even when the field properties do say that multiple values aren't allowed, those properties only apply when a user is editing the document using the defined form. An agent or code using any of the Notes APIs can always store multiple values in any text field.
That's why you always access item values through an array. It's not just a matter of "that's how the API works". It's a matter of how the underlying storage works.
And remember: Notes is schemaless. You have to always assume the following:
The item that corresponds to the field might not exist.
The item might be empty even if there's a validation formula that requires it to be filled in.
The item that corresponds to a text field might not actually be a text item.
The item can contain a list even if the multi-values property is not checked.
So in a picker in eWam / wynsure the field usually gets passed directly to some sort of OQL statement.
Hence, if I want to search for a field whose value ends in "asdf", I enter "%asdf" into the picker field.
My question is thus: from the picker, is there anyway to specify 'I want all entries that end in "asdf" OR "qwer"'?
If not, I would recommend that this become a feature as it would be very useful to be able to enter all that right in the text field.
There is currently no way to search multiple strings in a single field beyond using wildcards. One can do this easily by creating multiple fields in the picker.
Alternatively one could customize the picker as follows:
use a presearch string (that the user fills out),
parse that string for some element (like a pipe),
Break the string up and put each part in to off screen search variables.
You are still using multiple fields, but the user get's a different experience. Keep in mind the dangers of parsing out the user input, using something like or would work out very badly splitting up words, & could show up in a company name...
My view is one application and a required form along with few fields are in different application.
Point one: A View's selection formula does not "select a form". It selects documents. These documents are (usually) created with a Form, and they (usually) contain an item called "Form" which contains the name of the Form that they were created with. So a selection formula SELECT Form = "Foo" means that the view will show all documents with an item named Form that contains the value "Foo".
Point two: A View can only select documents that are in the same database that contains the View. It cannot select documents that exist in another database.
Ergo, there is no possible forumla that selects documents in another database that were created with a given Form.
I'm assuming you probably have some keyword documents in a different database, and you'd like to use a key in the main document to pull some matching information from the keyword database. In other words, you'd like to do a "join" in your Notes view.
You can't do this, never mind whether the documents are in the same database. This is not a relational database.
There are options, however.
You could create a "user definable" column and automatically update the column formula in a profile document so that the formula can calculate the keyword correspondences. You would have a periodic agent look at the keyword database and construct an updated formula such as, #Select("a"; "b"; "c";...; ChoiceNo) to convert the number field ChoiceNo to the value "a" (for 1), "b" (for 2), etc. If you can write a formula to display the correct values for the current keywords, this is workable provided the list never gets too long.
Domino servers are capable of accessing a DB2 relational database to construct a view index, using a feature called DB2NSF. So you can actually do a join -- but your NSF data has to be stored in DB2 as its back-end, rather than beinf stored in the NSF, for this to work. This is probably going to be more work than it's worth to you for this application.
If it is an XPages application, you can create your own data set however you like for feeding to a repeat control.
I am trying to simplify an existing Notes Form in an application that I am converting to XPages. The Notes Form has over 240 fields on it and a bunch of logic that I want to clean up. Plus the form has all kinds of display formatting that makes viewing it complex. So what I have been trying to write an agent that will get FormA and cycle through all the fields and copy them to FormB. I will then use FormB to bind my XPage to and trying to track down data issues will be much simpler. If the FormA didn't have so many fields I would just recreate it manually, but I'm sure with over 240 fields I would introduce some new typo errors.
You don't need to do anything with your form in order to create a XPage layout for it.
XPAges don't need a form at all, although it makes development easier, as after creating the data binding all fields from the form are available and can be dragged and dropped to the Xpage. Fields that are not on the form have to be created manually in the source code of the xpage (e.g. copy and paste an existing one and change the binding/name)
If you want to clean up your documents, an agent can do this without even touching the form.
For this task please consider the difference between a "Form" and a "Document".
A form is a design element that defines the look and feel of a document.
Forms contain fields that define what type of data you can put in your documents.
A document is a stupid "container" for items (not fields). It contains items for any field on the form that existed in the form when the document was created / last saved. PLUS items that are created any other way (e.g. Using formula or lotusscript agents) or that have been on the form in an earlier stage of development.
If you remove a field from a form, it will NOT be removed from the corresponding documents, not even by saving them. But If you add a field to a form, the document will have an item for that field after saving (forever, if you don't remove it manually using an agent).
With this knowledge you can simply create a new, "cleaner" form with the same name as the old one and rename the old one. From this time on, document will be displayed with the new Form and you can develop your XPage using it as your data source.
If you need to accumulate the data in the documents, this can be done with an agent without using a form: just manipulate the document DIRECTLY.
Here is an example in formula to put two fields together:
FIELD NewFieldName := OldField_1 : OldField_2;
FIELD OldField_1 := #DeleteField;
FIELD OldField_2 := #DeleteField;
I think, in most cases it's not a good idea to have a form with 240 fields. It looks for me like a form from old Notes 3 or 4 times when no embedded views were available and one to many relations were put into fields with index e.g. 1 to 20.
Maybe, a redesign is a better way to go.
Also, you don't need to create and maintain a form with all 240 fields for developing your XPage. Actually, you don't need the form at all. With a data source definition based on "Domino Document" you define a form name and which way you want to create a new document or find an existing document. That's it. Then you can create your fields in your XPage. Give them a name and a type. You can do this in Designer UI. Just write the new fieldname into "Bind to" for selected "Data source". Select in "Display type" a field type (String, Number, Date/Time). That is not only valid for display but will save the field as selected type to document too. In this example it will create a new field "YourNewField" and will save it as a integer number.
When you submit the page all fields will be created or set in document. You can check the fields and their types in Notes client using the document property box.
A good way though is to create the form with the most important fields. Then you can open the document in Notes client and check the fields set by XPage.
We have designed Lotus Notes forms, where we are displaying the data from the external system in a tabular format. In the tabular display we have editable fields, where user enters amount in these editable fields. Now we need to add the data from these editable fields and display in the totals field at the bottom dynamically.
Could some one please help me in this regard with code.
The current code:
The current editable fields are with name:
PE_TOBEPOSTED, PE_TOBEPOSTED1, PE_TOBEPOSTED3 and the total field is TOT_AMT. So in the field value of TOT_AMT the following code is written
w_postd := #Left(PE_TOBEPOSTED;15);
w_postd := #ProperCase(#Name([CN];#Left(w_postd;15)));
w_postd1 := #Left(PE_TOBEPOSTED1;15); w_postd1 := #ProperCase(#Name([CN];#Left(w_postd1;15)));
TOT_AMT = w_postd + w_postd1 + w_postd2
PS: I am just two weeks old in Lotus Notes development
Thanks.
Regards,
Kishore
To sum values, there is an #SUM formula that works like this:
#SUM(PE_TOBEPOSTED : PE_TOBEPOSTED1 : PE_TOBEPOSTED3);
Here, the values listed within the parenthesis, and separated by colons, are the names of the fields you want to sum. So this assumes there is a number in the PE_TOBEPOSTED, PE_TOBEPOSTED1, and PE_TOBEPOSTED3 fields.
You can add a refresh button to cause the page to recalculate. The code for the button is:
#Command( [ViewRefreshFields] )
Ok as you are totally new at this, there is a number of things you need to take into account.
First if you want the changes to happen while the user is interacting with the document in the Notes Client then you should use the NotesUIDocument object in LotusScript.
If you want the changes to happen when no UI is being interacted with you would use the NotesDocument Object.
I strongly recommend reviewing the Infocenter for the related documentation. Every LS Object reference has matching sample code.
For example here is the one for the NotesUIDocument on how to get a field from the document.
http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/topic/com.ibm.designer.domino.main.doc/H_EXAMPLES_FIELDGETTEXT_METHOD.html
You would get the text from the related fields, then use CINT method to change the strings to Integer numbers, add them and send them back to the document.