Hi Drew, >> Furthermore, the Basic function "DeleteStr", using in onLoadForm*, does >> not exist here - is this to be expected in the document, and somehow >> lost? Or should it be present in every installation? Or is it something >> special in one of your own Basic libs? >> > DeleteStr is found in the Tools library. The procedure Init.onLoad is > where I pull this library in.
hmm, WORKSFORME now. Not sure what I did differently last time :-\ >> Just wondering which of those artifacts are perhaps 3.1 show stoppers :) >> > I've been working on this file since last Wednesday and my thought was > that there might be two issues worth that status. > I believe I have a solution for one - The problem with the Open Document > event on the ODB file not firing on subsequent loads. > The cause is simple - the connection is never closed, even when the > database document is closed explicitly. > Workaround Solution - NEVER do this: > thisDatabaseDocument.DataSource.getConnection( "", "" ) > > instead ThisDatabaseDocument.CurrentController.connect() oConnection = ThisDatabaseDocument.CurrentController.ActiveConnection ' never dispose oConnection, it's owned by the controller http://api.openoffice.org/docs/common/ref/com/sun/star/sdb/application/XDatabaseDocumentUI.html (Note that this is not up-to-date, in 3.1, connect does not return a boolean value, but instead throws an SQLException when establishing the connection fails, much like DataSource.getConnection would do.) This approach should be much less error-prone. > In the procedure Init:onLoad (in this case) that is called from Open > Document on the ODB file do: > Create a dispatch handler > Displatch the uno command to switch the database document to the tables > section. http://api.openoffice.org/docs/common/ref/com/sun/star/sdb/application/DefaultViewController.html: Dim selection as new com.sun.star.sdb.application.NamedDatabaseObject selection.Type = _ com.sun.star.sdb.application.DatabaseObjectContainer.TABLES ThisDatabaseDocument.CurrentController.select( selection ) > ( this gets a connection established for us) > Now only open forms using > thisDatabaeDocument.FormDocuments.getByName("formName").Open Again, using the controller's XDatabaseDocumentUI is more error-proof here, since it defines clear ownerships for all involved objects. ThisDatabaseDocument.CurrentController.loadComponent( _ com.sun.star.sdb.application.DatabaseObject.FORM, _ "formName", false ) This effectively triggers the very same code as a double-click onto the form would do. In particular, the controller then knows about the opened form, and feels responsible for it. > The other issue is: > Close Document event for embedded forms does not seem to fire at all. > (3.1 m7 and 3.2 m44) Without having actually tried it, this might have to do with the way how embedded objects are handled. You might want to submit an issue for this missing event. Alternatively or additionally, use the OnSubComponentOpened/Closed events, which are broadcasted by the document. For this, you need to add an css.document.XDocumentEventListener to the document, instead of a css.document.XEventListener. You'll then get css.document.DocumentEvent objects notified (as opposed to the css.document.EventObject objects), which contain an additional field "ViewController" (denoting the affected controller) and an additional field "Supplement", which in this concrete case contains the frame of the affected component. (and now that I write it ... I hope one is still able to obtain the controller from the frame, without getting a DisposedException or such nasty things ... need to check my test covers this ...) Note that Tools/Customize/Events also contains those two events, which saves you the programmatic listener handling. Ciao Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
