Hi Ariel,
see m comments inline ...
Ariel Constenla-Haile wrote:
Hi Jürgen,
bad news: this mail is too long.
good news: I have finished all the spreadsheet and drawing examples,
plus some component examples.
great
So now text, spreadsheets, and drawing examples from
sdk/examples/java/ and sdk/examples/DevelopersGuide are ready as NB
projects (a zip copy goes to your mail).
I will start now from the first chapters of the Dev'd Guide to the last
one, checking the Java examples in sdk/examples/DevelopersGuide/* (by
the way, should I check/clean also the C++ and OOo Basic examples?).
The following are some questions/doubts during my work:
*****************************************************************************
I have followed two main rules:
* one-example ==> one-NB-project
* keep the use of the project as simple as possible (just download and
run/build/debug)
The drawing examples have given some problems: as they use three helper
classes, here I see three options:
* copy the three classes in every project (hard to maintain: every
change in one of the classes must be reflected in every project)
* put these classes into one NB Project, and advice the user to download
the example and helper project, then reference by himself the helper
project in every example
* same as before but already including an import and the reference in
every project, advising to put the example and the helper project in the
same folder, so that the reference is in every example project
"../DrawingHelpers"
May be the better is the third: the user downloads the example and the
helper, and he only has to put them in the same folder, then when he
opens the example, he can choose whether to open also the required
project with the helpers (NB Open Project dialog will advice this).
putting the helper in one project and use a reference in the other
projects is probably the best idea.
I like the NB approach. When you have checked out the NB sources and
when you open a module all dependent modules are opened as well. Maybe
it is possible to do it this way but don't ask me how it works exactly.
But when tested this from Linux to Windows, I had reference problems
when opening the project (Is the way the projects reference stored in a
system dependent way? In the project.properties figures
"../DrawingHelpers" both in Linux and Windows, so ...).
i don't know, sound like a bug
Conclusion: here I'm not sure what way to follow, do I include the three
classes in every example/project?
mmh, good question. See comment above. I will ask some NB guys ...
*****************************************************************************
Some examples require a test document to be opened.
I designed the examples so that the document opens automatically when
debugging . You can see the add-in examples.
In the cases where the doc. has macros in it (for example
DialogComponent [DevelopersGuide_examples/Components/DialogComponent],
RuntimeDialogExecutor
[DevelopersGuide_examples/BasicAndDialogs/CreatingDialogs/RuntimeDialogExecutor]),
it is very annoying that for debugging, one has to change the default
macro security settings. Is there an option in the command line to open
docs. with macros but without the macro warning?
as far as i know it can't be disabled from the command line. But the
user can add a base directory where he stored the examples to the
trusted sources. Not the best solution but it has to be done only once.
*****************************************************************************
Related to this, it is also annoying that every first time one debugs
(or after cleaning the project), one has to pass through the first
registration wizard. Can this be turned off?
well, the behaviour is the same as when you develop a plugin for NB with
NB and debug your plugin. We thought that it is good idea but i have to
agree it is or can be annoying. It is possible to disable it with the
option -nofirststartwizard. Maybe we should think to make it
configurable in our NB plugin.
*****************************************************************************
Options pages example: I have created a new folder
DevelopersGuide_examples/Extensions because the options pages example
belongs to the Extensions chapter.
I have created an example out of the code in the Dev's Guide.
I added 3 leaves to Calc, Draw, Writer, and 3 to a new node (shown in
all modules).
cool, Jochen will be happy ;-)
The new own node shows some problems:
I copied the OOo-look-and-feel from svx/source/dialog/* and
svtools/inc/controldims.hrc, so that the options pages look like the one
from OOo. This way the node page has a header with an image (just like
every OOo node has one next to the title of the node (FT_PAGE_TITLE) ).
How do I indicate the image URL for the node options page ?
OOo seems to support only absolute URLs in the XML-dialogs.
And at runtime it is impossible to draw the image or set the URL,
because a node page, AFAIK, does not call the event handler service (as
they don't take user input, in the OptionsDialog schema "Node" has
"Label", "OptionsPage", "AllModules", "GroupId", "GroupIndex" BUT no
"EventHandlerService" ). If this is so, IMHO this should be enhanced to
give access to this page also (there may be other cases where the
extension developers want to access this node page at runtime).
it is already fixed in OO.org 2.4. You can simply use relative Urls to
the xdl. Put the image in the same directory and use ./myimage.png or
whatever. Try a developer snapshot of 2.4.
*********************************************************************************
Calc Add-ins:
as other examples in the SDK, seems to be from the stone-age: I removed
the function descriptions, and used the configuration file. I recreated
the examples using the plug-in wizard (so that the example looks like
the one the devopoler should get using the wiz. for his own add-in)
of course that make sense and is a good idea. The idea was that the
developers should normally maintain the examples but ... maybe in the
future when everything is in the wiki ;-)
The functions in the example
SDK_HOME/examples/java/Spreadsheet/CalcAddins.java use an "internal"
com.sun.star.beans.XPropertySet argument. I couldn't figure out what is
this intended for. Should I keep this, or does this belong to some old
API and should be removed?
keep it, it is still a valid API. It should be documented in the
DevGuide or you can find infos in the IDL reference for the Addin service.
**************************************************************************
I think that all for now; any other doubt, I will ask you.
you make a great job, would be nice to have more of you ;-)
Juergen
Regards
Ariel.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
