By the way, I do something in my python package that I am not very sure about.
It works and just doing differently wouldn't be of much use because I don't
know how to controlledly reproduce the crash.
1 - I provide a service that creates text iterators. The text iterators are not
themselves services (much like enumerations), because they must be provided by
some component and not simply created by e.g. createInstance. Therefore, my
service ends up yielding instances of iterators whose classes have never been
registered by something like the addImplementation method of
unohelper.ImplementationHelper.
2 - my components don't inherit from unoHelper, because they implement custom
interfaces.
In one snippet, I have a service that produces instances of the following class
and sends them to the outside:
class SxwTextIterFrontEnd(SimpleHelper):
unoImplName = "com.itautec.ooo.comp.py.SxwTextIter"
unoServices = ()
def getInterfaces(self):
return (getTypeByName("com.itautec.ooo.lingu.XTextIter"),
getTypeByName("com.sun.star.lang.XTypeProvider"))
def __init__(self, startIter):
self.iter = startIter
def nextChunk(self, dummy):
self.iter, chunk = self.iter.nextChunk()
chunk = tuple(chunk)
return (chunk, chunk != ())
This class is never "registered" and simply implements (using my own
SimpleHelper) the interfaces com.itautec.ooo.lingu.XTextIter and
com.sun.star.lang.XTypeProvider. I never implement methods such as "acquire"
and the like. I take care never to call uno.getTypeByName twice for the same
name (my own getTypeByName ensures this).
Is that all right?
By the way, I've read about crash resulting from python exceptions, but you must
understand that the components are run a couple of times and crash happens while
doing routine things like editing or closing, some time after the action of any
component. And during development, when my component rose exceptions, they
seemed to be very well treated by Basic (the only user of my components so
far). In a word: while they had (grosser) errors, the didn't crash OOo ;o)
Cheers,
Jorge.
Selon [EMAIL PROTECTED]:
>
> Hi, all! I am developing some python components to help iterating and
> updating
> text respecting its original format transparently. They abstract away where
> each piece of text comes from (TextTables, Footnotes, regular Paragraphs) its
> font properties (i.e., allow treating sequences of TextPortions in a
> paragraph
> as a single string).
>
> As you can imagine, they create a bunch of simultaneously active TextCursors,
> keep lists of TextPortions which are modified while enumerations are active
> to
> have access to the following Paragraphs/Tables/TextPortions/etc. And they
> also
> spend some memory with intermediary strings and other data structures to
> compute minimum editing operations.
>
> My components are entirely developed in python and are being tested on OOo
> 1.1.5. However, sometimes I experience OOo to crash (generating an error
> report) during my tests, more often on saving the document after everything
> seems to have gone alright. I was somewhat surprised at this. What could I be
> doing wrong in python that just don't throw an exception? Should I explicitly
> "destroy" my cursors and textportions somehow? Explicitly "release" them?
> Force
> garbage collection (is it possible?)? Is that all a well-known bug and I just
> should move to 2.0 (not that easy)?
>
> Thanks in advance.
>
> Cheers,
>
> Jorge.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
