mmh, it seems that we have a classical problem where you have
implemented a macro based on a not documented implementation detail. But
the implementation gets cleaned up for 3.2.
The problem is that the correct way is also not well documented :-(
In this case it would be correct to check the TextPortionType and in
case of a text field ask for the property "TextField". It should be
possible to ask for the property always and do the necessary checks...
I am not sure if we can or should mark this as a show stopper because it
was an implementation detail. And the clean up of the code makes sense
and we don't really want to change it back.
Maybe the responsible developer can shed some light on this and give us
some more reasons for the change.
We have definitely to fix the documentation to reflect the correct way.
To avoid such problems in the future it is probably a good idea to ask
here on this list first before you use an API that is not documented.
Often enough the documentation is simply missing or incomplete.
We should be careful with the available introspection tools. They
provide great help and are necessary but the user of these tools should
at least check the documentation too. This way we can improve the
documentation as well.
Juergen
Juergen Schmidt wrote:
Hi,
i currently don't know enough details to answer your question but i will
check it.
But in general i would suggest that you submit such issues under the
correct component api. That ensures that i get these issues on my radar
and can help.
Juergen
Matthias B. wrote:
Hi,
I'd like to know the reasoning behind the decision not to treat
http://www.openoffice.org/issues/show_bug.cgi?id=106151
as a release blocker for 3.2. It's a serious regression regarding the
API. Common interfaces (XTextField) that used to be supported by
common objects (TextPortion) are missing now. Who knows how many
macros and extensions break because of this. But no one seems to care
enough to comment even on my request in bug 99999 to make this a 3.2
blocker.
Matthias
---------------------------------------------------------------------
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]
