Hi Stephan,
Note that com.sun.star.linguistic2.XGrammarChecker is an interface,
not a service.
Of course, but anyway I'm not implementing any code that displays
public methods other than documented in API.
Sorry, I do not understand you here. (But that's probably not so
important, anyway.)
I meant you're right - but I don't need IDL to declare anything anyway.
Sorry for causing confusion. The latest style is to implement
__getComponentFactory and have it return XSingleComponentFactory (an
older alternative would be to implement __getServiceFactory and have it
return XSingleServiceFactory; see
jurt/com/sun/star/comp/loader/JavaLoader.java:1.16).
All it caused, however, was that classpath suddenly covered files that
are not in the manifest.xml (we have some jars that are not on the
classpath and should not be touched by OOo). But multiple instances of
the service are anyway created.
I do not understand your first part (about classpath)
The first part is a bug - but probably not a very frequent one, only
caused by having both __getComponentFactory and __getServiceFactory in
the same class. Java classpath should be as defined by manifest.xml and
manifests in the jar, and not include every jar in the directory of the
extension.
> but multiple
instances are of course still generated when you use
com.sun.star.comp.loader.FactoryHelper.createComponentFactory in
__getComponentFactory. You have to return your own implementation of
XSingleComponentFactory from __geComponentFactory, which controls the
number of instances generated.
My worry is that multiple instances of the class that extends
XSingleComponentFactory would be created as well, with their own
counters always equal 1. Is there any example of extending
XSingleComponentFactory in a way that you recommend?
Maybe there is another design that I could use for sharing instance
data? Adding a new public method to the class wouldn't help as calling
it would call still another instance that has no listeners attached.
However, be aware that XGrammarChecker has methods like startDocument
documented as "This enables the grammar checker to maintain state
information about the document".
Yes, but they will be called by the grammar checker iterator for a
document, so they will get into the first instance of my class anyway.
I have no problem with them at all.
What happens if two documents are grammar checked in parallel?
Both documents should get rechecked using new options, if the user is
not a schizophrenic ;) The grammar checker options, just like speller
options, are not document-level but rather on the level of the whole suite.
Anyway, I didn't check how many instances there are with two docs but
probably two working in parallel. Changing to a single instance won't
make matters much worse (if docs are in different languages, there can
be a little slow down as different dictionaries will be reloaded but
disk caching probably won't make it very serious). There are methods of
XGrammarChecker for initiating document state and clearing document
state, so I could even bind some internal class instances to docs and
get rid of the problem of the slow-down. Anyway, the methods are not yet
implemented properly in my code (just skeletons) and very basic in the API.
Regards,
Marcin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
