0
votes

I have created a form in which the user enters values, then clicks "Add". This then creates a table in a Rich Text field on the form.

This is done by creating a temporary document with a richtextitem on it, expoting this via DXL, inserting the table in DXL into the richtextitem, and importing in back. Then I use uidoc.ImportItem to copy the table from the temporary document into my uidoc.

This works just fine, and I'm rather pleased with myself. In addition, the user can "Add" further rows. This is done by deleting the table (using Call uidoc.FieldSetText("table", "")) and recreating the table from the new values, as above.

However, each row of the document has two buttons, "Edit" and "Delete", so that the user can either edit a row, or delete it, after the table has been created.

So far, I am concentrating on coding the "Delete", and it works. However, when the code reaches any uidoc action, e.g. Call uidoc.FieldSetText("table", "") or Call uidoc.EditGotoField("Table") I get the dreaded "Error - Script is Busy" message in the status bar, and Notes crashes when I close the document.

I presume this is caused by the button thinking it's in a different document, so when it moves focus to a field in what it considers to be a different uidocument, it causes a problem.

I've tried a few different approaches, e.g. having the button set fields on the NotesDocument, and then refresh, using a hidden value to trigger the updateTable Sub. I've also experimented with triggering an agent, but as the uidoc has not been saved, I can't get a session.documentcontext, and of course I can't access the UI in an agent.

One thing I haven't tried yet, is making the Delete button trigger an formula command that would cause the uidoc to be refreshed, and set off the updateTable Sub from the PostRecalc event.

If anyone has any other suggestions, I'd be very grateful as this is the one niggle that is preventing me improving the performance of one of our legacy forms by about 1000%.

1

1 Answers

1
votes

OK, so I tried using Formula language instead of Lotusscript in my DXL-created button in a rich text table in a rich text field in an unsaved uidoc. And it worked :-)

@Setfield("deleteRow"; 1);
@Command([ViewRefreshFields])

Obviously, the LotusScript that creates the DXL document subsitutes the approriate row number in each button's @Setfield. Also, I now have LotusScript in the QueryCalc event that checks the value of doc.deleteRow(0), and calls the updateTable subroutine if it's greater than 0.

This process has been yet more evidence that explaining one's problems to someone else can often trigger the thought that leads to the solution.