How to close a "child" database?

[WalWeb]

A button in a mail item opens a document which prompts for some user information, then creates a further email which is forwarded to a nominated userID. My question is how do I then cause the database from which the prompting form was loaded to close? I end up with a database left open on my user's workspace and some variation of a 4243 or 4327 user error if I try to close the database from within the prompting form itself. No great harm done, because I never save anything in that database, and I can always ask the users themselves to close that database that just opened up, but it's not at all an attractive look.

Any ideas welcome, especially the Right Approach which must surely exist somewhere ...

 

[pmonett]

Instead of closing the prompt form (where the focus may not be right), try using @command([FileCloseWindow]) after closing the prompt form but before sending the mail.
Alternatively, but more costly in development time, you could create the prompt form in the mail database and have it look up data in the other database without "opening" it for the user.

Pascal.

I've got nothing to hide, and I'd very much like to keep that away from prying eyes.

 

[WalWeb]

I'm not sure that it works the way you think it does -- users receive a button in an email, with the following code behind it:

Sub Click(Source As Button)
Dim ws As New NotesUIWorkspace
Dim db As NotesDatabase
Dim uidoc As NotesUIDocument
Call ws.OpenDatabase("ServerNm", "DBx.nsf")
Set uidoc = ws.ComposeDocument("","","SubmIt")
End Sub

The SubmIt form opens and accepts the user's input as required, which it forwards in an email to a "collecting" ID's mailbox. That all works fine, but it leaves the database (DBx in the above example) open on the user's desktop. Trying to close the database (for example, from within the "SubmIt" form's QueryClose event, or from within the code executed behind the button) yields a user error.

We can tell the user to close the database "longhand", ie, manually, but it seems a pretty clunky way to do what's needed. Any suggestions gratefully received.

 

[pmonett]

It's what I thought all right : you have a focus issue where the button code cannot properly target the DBx window.

What I would suggest us this : have the SubmIt form close the database itself, but only if the document was opened via the button.

Since your mail button probably cannot be changed, that means adding a control in the SubmIt form to check how it was opened, and a CloseWindow command on form exit that triggers if the mail button was used.

Pascal.

I've got nothing to hide, and I'd very much like to keep that away from prying eyes.

 

[WalWeb]

Thanks for your focus, Pascal.

I assume you mean putting a FileCloseWindow into the form's QueryClose event, but that's already full of LotusScript to do the actual doing, and in any case, my recollection is that a

Call db.Close

in that routine isn't viewed too kindly. Will I achieve the same effect if I explicitly close the default UI view (which I never explicitly open) and maybe try a FileCloseWindow in the view's Terminate event?

I'm not concerned about the form being opened any other way than as a result of the button being clicked.

 

[pmonett]

Your very welcome

But unfortunately we haven't cracked that nut yet.

So, to summarize :
- button in user mail opens the DBx database and composes a SubmIt form
- DBx remains open after SubmIt form is closed
- mail button cannot successfully close DBx window
- SubmIt form's QueryClose cannot be changed

Hmmm.

The SubmIt form is closed by a button ? Tell me that the button is plain old Formula and you could put another @Command([FileCloseWindow]) ?

Otherwise, there is always the heavy artillery option :
- create execution agent in DBx with @Command([FileCloseWindow]) as sole code
- have the SubmIt's QueryClose code call that agent as last argument

Pascal.

I've got nothing to hide, and I'd very much like to keep that away from prying eyes.

 

[WalWeb]

SubmIt form can't be changed (easily) from all-LotusScript in order to accommodate a FileCloseWindow, anyway -- all its work is done in QueryClose, including locating the user's ID file, where possible, and attaching it to the email that it builds ... and sends.

I'll try what you suggest, and code an agent that does nothing more than @Command([FileCloseWindow]), called just one step ahead of Exit Sub, and see what happens ... will post back to let you know (but possibly not before Monday ...).

 

[WalWeb]

Pascal,

I end up with the problem I had all along -- Notes diagnoses a logical inconsistency in a form that tries to close its own parent database, and posts a 4000 ("user-defined") error at the point of running the [FileCloseWindow] agent, right at the end of the document's QueryClose event. I think you'd see the same error whether you were trying to do it from an agent launched via LotusScript (as here) or from within a piece of formula code. (Or maybe not -- just coded a quick'n'dirty form to launch a test doc in another database, which presents a button that does nothing but [FileCloseWindow] to close itself, then repeats that in its own QueryClose event in hopes of closing the database, and while I don't get an error message, the called database stays open on the workspace.)

Think I'm going to have to settle for a button on the database's default view, which never has any documents to display, in any case, saying something like "Close this database". It's a clunky, clumsy imposition on users, but at least it does the job.

Thanks for your help anyway.