Form controls changing size / getting larger / OOo3.0.1

[frank.schoenheit]

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: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[frank.schoenheit]

Hi Drew,


> NOTE - If you try to open the Basic IDE here you will not see the ODB
> file (MyInvoice_pre_2) when you do this - WHY - because the odb file is
> currently hidden. The Basic IDE UI honors this - I like that, but don't
> know if it was intentional or not, I tend to think it was.

It is. Hidden documents can occur in quite some other scenarios, too.
For instance, if you have an .odb accessing a spreadsheet, this one is
loaded hidden, too. The other applications also have situations where
they load a "secondary" document hidden. You definitely do not want to
expose all those in the Basic IDE.

> -so-
>
> Use File>Open to bring the database document onto the desktop.
>
> In the database document window click on the Tables section.
>
> Now go back to the frmInventoryList and click on the 'New' button.
>
> The form frmInventoryItem opens this time.
>
> Why?
>
> 1 ) this is the only place (currently) where I use:
> thisDatabaseDocument.FormDocuments.getByName("frmInventoryItem").Open
>
> 2) Calling Open with no parameters works ONLY after a connection has
> been created USING the database document UI. The fact that within the
> macros I have already used:
> thisDatabaseDocument.DataSource.getConnection("","") a number of times
> is not enough.

To the data source, your basic macro is an arbitrary client, requesting
a connection. The doc UI (the controller), does not know anything about
this. Instead, it needs to create an own connection.
See my previous mail for how to obtain connections (and opening forms)
via the controller, this should solve the problem.

> This may be significant as a clue to another issue. How to get rid of
> the connections so that the file FULLy closes.

Same solution - obtain the connection from the controller, it then stays
in the controller's responsibility, instead of your own.

> With the macros in the ODB file as it stands you can not open this file
> twice in the same OO.o session and have the function Init:onLoad called
> after the first time. It appears that this is because a connection(s) to
> the HSQLdb engine is never released.

Did not check your macros, but I suppose you did not do a "dispose" on
the connection you got from the data source?

Ciao
Frank

PS: quite cool document ...

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Drew Jensen-4]

Frank Schönheit - Sun Microsystems Germany wrote:
> Hi Drew,
>  
> Did not check your macros, but I suppose you did not do a "dispose" on
> the connection you got from the data source?
>
>
>  

I'll keep it short.

Added thisDdatabaseDocument.CurrentController.connect() to the
Init.OnLoad macro.

Made a quick wrapper macro

function OpenDBForm( aFormName as string ) as object

    OpenDBForm = ThisDatabaseDocument.CurrentController.loadComponent( _
    com.sun.star.sdb.application.DatabaseObject.FORM, _
    aformName, false )

end function

Then did a simple find/replace to use this OpenDBForm vs my old
OpenDBDocument.

Voila!  Nothing like doing things the right way.

I can now load that file multiple times in the same OO.o session and the
Open Document event fires each time. (Assuming, of course, I close the
actual odb file each time)

Thanks much,

Drew

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Karl Weber]

Hi Frank,

Am Dienstag, 24. März 2009 15:49 schrieb Frank Schönheit - Sun Microsystems
Germany:
> > However: Window size and position are also changed.
>
> that's strange, and I never encountered this. If you have a reproducible
> step-by-step description of how to see this, I'd be interested in
> hearing it.

Now, with 3.1, I can reproduce the following:

I take a form and make it quite large with <Ctrl>-<Scroll wheel>. The window
size will not change, but the form will get larger and larger. Then I close
this form and open it again. This time the window is also large, probably in
proportion to the size of the form. With 3.1 I can always see the menu, but
the window bar has disappeared.

This is not quite what I observed before (since I can still see the menu now),
but maybe it helps.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[frank.schoenheit]

Hi Karl,

> I take a form and make it quite large with <Ctrl>-<Scroll wheel>. The window
> size will not change, but the form will get larger and larger. Then I close
> this form and open it again. This time the window is also large, probably in
> proportion to the size of the form.

Ouch. Can reproduce, care to submit an issue?

> With 3.1 I can always see the menu, but
> the window bar has disappeared.

Cannot reproduce, neither on Linux with Gnome, nor on Windows, but this
might be theming-dependent. I'd suppose once the original bug of wrong
scaling is fixed, this one vanishes, too.

Ciao
Frank

--
- Frank Schönheit, Software Engineer         frank.schoenheit@... -
- Sun Microsystems                      http://www.sun.com/staroffice -
- OpenOffice.org Base                       http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...