Hello Marco, * ,
I took the above code from the TextDocuments.java example that comes with the
OO SDK
well, if you are starting studying OOo API, you must take care both of
the SDK and its examples, because they have some errors, some of them
quite serious and may make you waste a whole day thinking what you're
doing wrong, when it's the SDK that's wrong and not you.
All this will sure be fixed when the SDK is on the Wiki.
Concerning the TextDocuments.java, as I started (for my own
training/studying) to translate the SDK Java examples into C++, I
realize that it has some issues:
* the TextSectionExample() is supposed to show how to create
child-parent sections, and a linked one, but due to errors moving the
text cursor and selecting text ranges, the example ends up creating two
simple sections and a linked one
* the DrawPageExample() is quite old, so at the end it does not group
shapes (and by the way the commented code is wrong)
* the viewCursorExample() is, IMHO, a serious case:
starting with its ACTHUNG!:
viewCursorExample(); // makes changes to the current document,
// use with *care*
and all the rest, the example is a way to propagate a bad programming
practice.
This assertion is justified because of the way it access the document:
XDesktop.getCurrentComponent(), by reading a very hidden comment in
Dev's Guide 20. GUI
http://api.openoffice.org/docs/DevelopersGuide/GUI/GUI.xhtml#1_5_3_The_Toolkit_Service
"There are several ways to retrieve a frame. The easiest way to retrieve
a frame is to query the frame that has the focus: [...]
XDesktop.getCurrentFrame() [...] This should only be used for debugging
purposes. The method getCurrentFrame is based on the implementation of
the window handler of the operating system and you cannot be sure that
the returned frame is always the desired one on all supported platforms,
or that a valid frame is returned at all."
and as@ comment in
http://www.openoffice.org/issues/show_bug.cgi?id=84767
"Using of any API related to the focus (getActiveFrame(),
getCurrentComponent() etc) should be supressed. It works sometimes ...
but not always and even not on all platforms in the same way. Its always
better to make thinks more explicit. You can travel the frames
hierarchie .. analyzing controlls/models to find the right (in your
example forms) component - and it will work always."
So getting any reference using getCurrentComponent(), getCurrentFrame(),
getActiveFrame() is completely discouraged, and every example should
avoid to use this.
[Side comment: some hidden place in the Dev's Guide or an issue comments
is not the right place to state this warning to the developers, it
should at least be in the corresponding chapter in the Developer's
Guide:
http://api.openoffice.org/docs/DevelopersGuide/OfficeDev/OfficeDev.xhtml
seems to be the right place, because there is explained the use of
getActiveFrame(), getCurrentFrame() and getCurrentComponent() *BUT*
there is no explanation at all concerning the possible problems of using
the current implementation. Again: this will sure be fixed when the SDK
is on the Wiki]
Said so, you can find my version of TextDocuments.java as a NetBeans
Project in
http://www.ArielConstenlaHaile.com.ar/ooo/temp/TextDocuments_java.zip
I have corrected the text sections example (now there is a parent and a
child section), the view cursor example is completely re-writen, and in
the draw page example added two ways to group shapes.
Regards
Ariel.
--
Ariel Constenla-Haile
La Plata, Argentina
[EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.ArielConstenlaHaile.com.ar/ooo/
"Aus der Kriegsschule des Lebens
- Was mich nicht umbringt,
macht mich härter."
Nietzsche Götzendämmerung, Sprüche und Pfeile, 8.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
