Update a field on a Open doc from another open doc

Maybe easy enough: communication is possible, because the parent of the newly opened form can use the uidoc of that form.

See ws.editdocument, how it kan return the uidoc of the new form

Is this a web application?

No this is a notes application

Then read the Help about the EditDocument method of NotesUIWorkspace. It makes it possible that a LotusScript function on a parent form interferes directly with the newly edited form.The other way round is not possible, the child form cannot set values in the parent form in any way. Some examples of using this technique:

Edit the child document, use the returned uidoc to set the name of an Environment variable that contains the UniversalID of the current document. If both forms are to be open at the same time, this won't work, because only the database document will be updated, not the parent form on screen.

Edit the child document, use the returned uidoc to set a (hidden) field with a state, the states being
NOTATTACHED (default state): if the form is used without having been opened by the parent, there is no data exchange required
ATTACHED: requests the child form to set the state to UPDATED whenever the content of some fields have been changed
UPDATED: signals the parent form that fields have been updated, to be copied to the parent form; the state could be reset to ATTACHED afterwards
QUERYCLOSE: the child form is not permitted to close without the parent form's consent
CLOSE: the child form can close now

The parent form has to verify regularly the state of the field and act accordingly. The only way to do this is to use a NotesTimer (my favourite!).

Totally different and more difficult approach, albeit using the same technique but only possible in R6: use the universal-ID of a profile document that can be used to Lock and Unlock critical sections. The ID can be passed to the child form using the uidoc of the child, as above. The child form will then open the profile document created by the parent form, even data can be exchanged using the profile document.

There may be other ways to accomplish what you want, but what's the approach you prefer? Or do you have one of your own?

HI

Here is what I was thinking


If I grab the UNID of the parent and set it in the child

The child uses the UNID as a handle back to the parent

Scenario
Create a Parent Doc (Not Saved at this point)
Push button to open child
Push button on child to send mail and to set field on parent then close (Not Saved)


I can set the Parent UNID I see it on the form

I seem to be unable to write back to the parent


Set Parent = db.GetDocumentByUNID(doc.ParentUNID )
            Parent.CertSent = Now


THanx

James

imjamesw,

> The child uses the UNID as a handle back to the parent
OK
 
> Push button on child to send mail and to set field on parent then close
Setting a field on the parent won't work, that's what I said above! The parent can set a field on the child document, not the other way round. By the way, if you don't save the parent document, it will not have a Universal-ID.
 
> I can set the Parent UNID I see it on the form
Nope
 
> I seem to be unable to write back to the parent
Correct
 

Sjef

HEy Sjef


What if we wrote the value I need to a Env variable and then after the child close refresh the field to look up the env if it is there

Yes, you cold do that, but I ALWAYS try to avoid env. variables. If all else fails, then use them. But still, that value can only be set if the parent is saved.

I might have a better approach for you! What if you create the child document by means of a DialogBox, and let the parent update itself using the appropriate mechanism (RefreshParentNote)? You might wonder, but it is possible to save a document from a DialogBox!

Will the dialogbox send mail when the button is pushed

I do not thinkso as I do not think I can use form buttons within a dialogbox

Ah! Did you succeed this way? Using a DialogBox?

yes