Re: [dev] paragraph number
Mohammad Alhammouri schrieb:
Hello there,
is there a similar function to the page number function
xPageCursor.getPage(),
that finds the paragraph number within the text document.
if not is there any way to find that number in JAVA ?
thanks in advance.
Regards,
Mohammad.
hi,
i am not sure if this might help you, but you can enumerate the
text::Paragraphs inside a text::Text.
e.g.:
// get all text from the document
::css::uno::Reference css::text::XText text =
textDocument-getText(); //
// this should be a text::Text Service. It offers the XEnumerationAccess
// to enumerate paragraphs
::css::uno::Reference ::css::container::XEnumerationAccess
paragraphEnumerationAccess (text, ::css::uno::UNO_QUERY);
// get the enumeration
::css::uno::Reference ::css::container::XEnumeration
paragraphEnumeration =
paragraphEnumerationAccess-createEnumeration();
// enumrate
while ( paragraphEnumeration-hasMoreElements())
{
::css::uno::Any anyParagraph =
paragraphEnumeration-nextElement();
::css::uno::Reference ::css::text::XTextContent paragraph(0);
anyParagraph = paragraph;
}
if you want to go deeper into the paragraph, you can get another
XEnumerationAccess interface from the Paragraph service. This will give
you access to TextPortions.
see:
http://api.openoffice.org/docs/common/ref/com/sun/star/text/Paragraph.html
http://api.openoffice.org/docs/common/ref/com/sun/star/text/TextPortion.html
http://api.openoffice.org/docs/DevelopersGuide/Text/Text.xhtml#1_3_1_2_Iterating_over_Text
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] OOo 2.0.4 status meeting
July 17th, 15pm - 15.30pm Participants: Mathias Bauer, Thorsten Ziehm (QA), Martin Hollmichel This group meet on Mondays 3pm German time on regular basis, please contact me if there is the need to raise any issues for the next release in this forum, we try to move to irc then or at least try to put your issues onto our agenda. In case you get this email as private copy as well, we think you need to take action on this mail. * RE this week: Kurt, m179 to start Wednesday 19th * onlineupdate3 will integrated later with some changed strings. issue count for 2.0.4 went down to 261 from 320 last week, there are still some candidates (ab, ihi, hro, er) with more than 10 issues with this target. Those people might reconsider the target 2.x for some of their issues. Initial response time (IRT) for patches is slightly increasing again, http://eis.services.openoffice.org/patchreport/irt_2006-07-08.html Initial inactivity time (IIT) for patches is slightly increasing again, http://eis.services.openoffice.org/patchreport/iit_2006-07-08.html The details link for IRT and IIT are currently broken, work for fixing this is in progress. The demand for branching off OOD680 is not that high as expected, so we are planning the branch around August 3rd to 10th, candidates for early integration for 2.0.5/2.1 are cws writercorehandoff and hcshared01. Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Christian Lohmaier wrote:
Hi *,
On Fri, Jul 14, 2006 at 10:00:57AM +0200, Stephan Bergmann wrote:
Christian Lohmaier wrote:
On Thu, Jul 13, 2006 at 06:04:41PM +0200, Stephan Bergmann wrote:
Now that CWS warnings01 is integrated and most of the OOo modules are
C/C++ warning free for the standard platforms (unxlngi6, unxsoli4,
unxsols4, wntmsci10),
only for specific compiler versions.
gcc 4.0.[23] at least cannot compile OOo without disabling the warnings
for quite a lot of dirs.
Please wait until CWS warningfixes02 is integrated, or manually apply
the patch from http://www.openoffice.org/issues/show_bug.cgi?id=66577.
I already have that one applied, but still, many, many directories need
the warnings != errors switch. (around 90)
With those changes integrated, OOo should compile fine at least with
GCC 4.1.1. I encountered spurious warnings with GCC 4.0.2 that I would
consider errors of GCC, and which disappeared for GCC 4.1.1. This might
rule out GCC 4.0.2 as an appropriate compiler for OOo.
Unfortunately :-(
[...]
Which modules are missing? As of SRC680m176, the situation is as follows:
m175 and m176 don't compile here either because typesizes.h is not
generated/ typesconfig is not built and not run. (but build walked
through the directory) - not sure why But that's another story
anyway.
You mean, unrelated to the warnings are errors thing? (Otherwise, I
would be interested in an issue id.)
Not related to the warnings are errors thing. I now tracked it down to a
broken patch that I applied
(http://qa.openoffice.org/issues/show_bug.cgi?id=67199 - I thought I had
the latest one, but my scripts applied the parallel-solenv-urd.diff one
instead)...
Opinions, anyone?
I'd like to have a statement of what compiler versions will be/are still
supported by OOo.
The official Sun Hamburg builds are done with GCC 3.4.1 (plus a
visibility patch and one other minor tweak, I think). Other versions
are also known to work, either by chance, or after some people put in
enough effort to make it work. Other versions are known not to work,
either due to errors in GCC or in OOo (wasn't that the case for GCC
4.0.0? I'm always bad at remembering such details).
I'm feared but nevertheless expected the by chance answer...
I personally would love to see as many versions of GCC supported as
possible, but there are certainly practical limits to this.
So in future, the only way to build with those other compiler versions
is to either patch a lot of makefiles or to disable the warnings=errors
flag completely?
That each person that wants to build OOo with compiler xy has to patch
a lot of makefiles IMO is no solution. Either OOo builds on copiler xy
out of the box or not at all. Also, I'm reluctant to introduce a global
switch that undoes warnings=errors for a build. I fear that switch
would be used too often to cheaply work around serious problems. New
compilers with new kinds of warnings can give us valuable information
about where our code is broken. Of course, it is also true that new
compilers can start to issue bogus warnings that cause endless pain for
those trying to use those compilers...
Yes, introduction of warnings=errors changed the landscape somewhat.
Now, it is no longer only (bogus) compilation errors or generation of
wrong code that can rule out a specific compiler, but also (bogus)
compilation warnings. I would hope that for each given compiler, we can
either change the OOo code base so that it compiles without warnings (as
was done e.g. for GCC 4.1.1) or decide that the compiler is not up to
the task (as I would suggest for GCC 4.0.2, but that is only my personal
opinion, see below). However, when changing the OOo code base so that
it compiles fine with a certain compiler, there is a line somewhere
between improving the code so that it does not cause warnings and
brutally mutilating the code to adapt it to the idiosyncrasies of that
compiler. Before we ever fall into the trap of doing the latter, we
should seriously re-consider whether supporting that specific compiler
version is worth it---maintaining a contorted code base is too high a
cost overall.
As you wrote in comment 3 to issue 66577 that gcc 4.0 generates warnings
or stuff like this
void f(com::sun::star::uno::Any const a) {
sal_Bool b;
if (a = b) {
// warning if b is used here
}
}
To me (I have no programming skills), this looks like a warning similar
to you'd better put parentheses around that expression to avoid
ambiguity (You'd better set a value for b or you may get weired
results) - but I cannot tell whether that is worth fixing or not.
It is not about parentheses but about definitive assignment of b. The
fix would be sal_Bool b = false; instead of sal_Bool b;, and IMO
that starts to touch the line between improvement and mutilation. A
later reader of the code might be puzzled why b is first assigned a
dummy value when all the uses of b
[dev] Asian CJK Group Announced!
On the 17th of July 2006, the Chinese, Japanese and Korean native-language projects of OpenOffice.org have decided to join forces to form the Asian CJK Native-Language Group of OpenOffice.org*. Mr Hirano Kazunari will act as the communications technical coordinator of the group. This group will allow these three projects to share experiences on common L10N and I18N issues and pool some ressources such as the work on some parts of QA. In the mean time, this group will also foster collaboration between the three projects on a marketing level, helping the spread of OpenOffice.org all over Asia.We would like to thank the volunteers of these projects for their hard work and their long time commitment to the OpenOffice.org project. Congratulations to Hirano Kazunari and good luck to the Asian CJK Native-Lang Group! Charles-H.Schulz, Lead of the Native-Language Confederation, OpenOffice.org - *Useful links: Chinese Native-Lang project: http://zh.openoffice.org Japanese Native-Lang project: http://ja.openoffice.org Korean Native-Lang project: http://ko.openoffice.org Asian CJK NL Group wiki: http://wiki.services.openoffice.org/wiki/CJK_Group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Asian CJK Group Announced!
Good luck. Jianhua On 7/18/06, Charles Schulz [EMAIL PROTECTED] wrote: On the 17th of July 2006, the Chinese, Japanese and Korean native-language projects of OpenOffice.org have decided to join forces to form the Asian CJK Native-Language Group of OpenOffice.org*. Mr Hirano Kazunari will act as the communications technical coordinator of the group. This group will allow these three projects to share experiences on common L10N and I18N issues and pool some ressources such as the work on some parts of QA. In the mean time, this group will also foster collaboration between the three projects on a marketing level, helping the spread of OpenOffice.org all over Asia.We would like to thank the volunteers of these projects for their hard work and their long time commitment to the OpenOffice.org project. Congratulations to Hirano Kazunari and good luck to the Asian CJK Native-Lang Group! Charles-H.Schulz, Lead of the Native-Language Confederation, OpenOffice.org - *Useful links: Chinese Native-Lang project: http://zh.openoffice.org Japanese Native-Lang project: http://ja.openoffice.org Korean Native-Lang project: http://ko.openoffice.org Asian CJK NL Group wiki: http://wiki.services.openoffice.org/wiki/CJK_Group - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- \* Study... */
Re: [dev] Set default posSize for new created Windows
Hi Carsten,
On 7/14/06, Carsten Driesner [EMAIL PROTECTED] wrote:
You can see that the configuration set Factories contains nodes for
every appplication module, in the example
com.sun.star.frame.StartModule and com.sun.star.text.TextDocument.
The property called ooSetupFactoryWindowAttributes stores the left,top
position and the width and height in pixel. You can use the
configuration API to change these values programmatically.
thanks. this works!
if you are interested in the solution, just have a look at example code below.
I am not sure if the current implementation reads the values for every
new window or if it just uses internal values. So it's possible that the
values are only read once from the configuration at startup time. Be
aware that these values will be overwritten when a user changes the
position or size of an application window.
it seems that the current implementation reads the attribue for every
new window and doesn't use internal values!
here the example code:
/**
* Diese Hilfsmethode liest das Attribut ooSetupFactoryWindowAttributes aus
* dem Konfigurationsknoten
* /org.openoffice.Setup/Office/Factories/com.sun.star.text.TextDocument
* der OOo-Konfiguration, welches die Standard-FensterAttribute enthält, mit
* denen neue Fenster für TextDokumente erzeugt werden.
*
* @return
*/
private static String getDefaultWindowAttributes(XComponentContext ctx) {
try {
Object cp = ctx.getServiceManager().createInstanceWithContext(
com.sun.star.configuration.ConfigurationProvider, ctx);
// creation arguments: nodepath
com.sun.star.beans.PropertyValue aPathArgument = new
com.sun.star.beans.PropertyValue();
aPathArgument.Name = nodepath;
aPathArgument.Value =
/org.openoffice.Setup/Office/Factories/com.sun.star.text.TextDocument;
Object[] aArguments = new Object[1];
aArguments[0] = aPathArgument;
XMultiServiceFactory xmsf = (XMultiServiceFactory) UnoRuntime
.queryInterface(XMultiServiceFactory.class, cp);
Object ca = xmsf.createInstanceWithArguments(
com.sun.star.configuration.ConfigurationUpdateAccess,
aArguments);
XPropertySet prop = (XPropertySet) UnoRuntime.queryInterface(
XPropertySet.class, ca);
return prop
.getPropertyValue(ooSetupFactoryWindowAttributes).toString();
} catch (java.lang.Exception e) {
}
return null;
}
/**
* Diese Hilfsmethode setzt das Attribut ooSetupFactoryWindowAttributes aus
* dem Konfigurationsknoten
* /org.openoffice.Setup/Office/Factories/com.sun.star.text.TextDocument
* der OOo-Konfiguration auf den neuen Wert value, der (am besten) über
* einen vorhergehenden Aufruf von getDefaultWindowAttributes() gewonnen
* wird.
*
* @param value
*/
private static void setDefaultWindowAttributes(XComponentContext ctx,
String value) {
try {
Object cp = ctx.getServiceManager().createInstanceWithContext(
com.sun.star.configuration.ConfigurationProvider, ctx);
// creation arguments: nodepath
com.sun.star.beans.PropertyValue aPathArgument = new
com.sun.star.beans.PropertyValue();
aPathArgument.Name = nodepath;
aPathArgument.Value =
/org.openoffice.Setup/Office/Factories/com.sun.star.text.TextDocument;
Object[] aArguments = new Object[1];
aArguments[0] = aPathArgument;
XMultiServiceFactory xmsf = (XMultiServiceFactory) UnoRuntime
.queryInterface(XMultiServiceFactory.class, cp);
Object ca = xmsf.createInstanceWithArguments(
com.sun.star.configuration.ConfigurationUpdateAccess,
aArguments);
XPropertySet prop = (XPropertySet) UnoRuntime.queryInterface(
XPropertySet.class, ca);
prop.setPropertyValue(ooSetupFactoryWindowAttributes, value);
XChangesBatch committer = (XChangesBatch) UnoRuntime
.queryInterface(XChangesBatch.class, ca);
committer.commitChanges();
} catch (java.lang.Exception e) {
}
}
regards,
Christoph
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
2006/7/18, Stephan Bergmann [EMAIL PROTECTED]:
As you wrote in comment 3 to issue 66577 that gcc 4.0 generates warnings
or stuff like this
void f(com::sun::star::uno::Any const a) {
sal_Bool b;
if (a = b) {
// warning if b is used here
}
}
To me (I have no programming skills), this looks like a warning similar
to you'd better put parentheses around that expression to avoid
ambiguity (You'd better set a value for b or you may get weired
results) - but I cannot tell whether that is worth fixing or not.
It is not about parentheses but about definitive assignment of b. The
fix would be sal_Bool b = false; instead of sal_Bool b;, and IMO
that starts to touch the line between improvement and mutilation. A
later reader of the code might be puzzled why b is first assigned a
dummy value when all the uses of b are within the if block where it
definitely is assigned a value.
Ok, I'm not a C++ programmer and this is probably not the right place
to start learning.
But isn't it the left (a) side that gets assigned in a = b?
I.e. b is still not assigned and the warning is good and fixing it is
no mutilation?
/$
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Asian CJK Group Announced!
Congrantulations! Charles Schulz 写道: On the 17th of July 2006, the Chinese, Japanese and Korean native-language projects of OpenOffice.org have decided to join forces to form the Asian CJK Native-Language Group of OpenOffice.org*. Mr Hirano Kazunari will act as the communications technical coordinator of the group. This group will allow these three projects to share experiences on common L10N and I18N issues and pool some ressources such as the work on some parts of QA. In the mean time, this group will also foster collaboration between the three projects on a marketing level, helping the spread of OpenOffice.org all over Asia.We would like to thank the volunteers of these projects for their hard work and their long time commitment to the OpenOffice.org project. Congratulations to Hirano Kazunari and good luck to the Asian CJK Native-Lang Group! Charles-H.Schulz, Lead of the Native-Language Confederation, OpenOffice.org - *Useful links: Chinese Native-Lang project: http://zh.openoffice.org Japanese Native-Lang project: http://ja.openoffice.org Korean Native-Lang project: http://ko.openoffice.org Asian CJK NL Group wiki: http://wiki.services.openoffice.org/wiki/CJK_Group - 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]
Re: [dev] Warning free code: the missing modules
Hi, please correct me, if I am wrong. I understand this as a 'C' inherited C++ oddity (no constructors for integral values), which leads to a warning if the first operation on the integral value is not classified as assignment. Obviously 'operator =' has not been classified as assignment at least not for the right operand. So, it seems that we have used the wrong operator here. Therefor I tend to agree to Frank, that we may want to fix this. Kay Frank Schönheit - Sun Microsystems Germany wrote: Nonetheless, I would not consider initializing b with something meaningful a mutilation. And be it just because months later, somebody will be tempted to re-use b some lines below. Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Kay Ramme - Sun Germany - Hamburg wrote:
Hi,
please correct me, if I am wrong. I understand this as a 'C' inherited
C++ oddity (no constructors for integral values), which leads to a
warning if the first operation on the integral value is not classified
as assignment. Obviously 'operator =' has not been classified as
assignment at least not for the right operand.
No, the compiler does not assume the user-supplied operator = has any
assignment semantics. Rather, as the operator = is inline, GCC tries
an analysis whether or not b is definitely assigned at point (1) in
com::sun::star::uno::Any a;
T b;
if (a = b) {
// (1)
}
Depending on T (i.e., depending on the complexity of the relevant inline
operator =):
- GCC sometimes comes up with the insight that b is definitely assigned
at (1), which is correct, and in which case GCC does not issue a warning
(why should it?);
- GCC sometimes cannot decide whether or not b is definitely assigned at
(1), although it *is*, and in which case GCC conservatively does not
issue a warning;
- GCC sometimes comes up with the insight that b is not definitely
assigned at (1), which is an incorrect analysis, and in which case GCC
erroneously issues a warning.
So, it seems that we have used the wrong operator here. Therefor I tend
to agree to Frank, that we may want to fix this.
The choice of operator is indeed unfortunate. However, I do not agree that
- T b;
+ T b = T();
is in general a fix that improves code quality.
-Stephan
Kay
Frank Schönheit - Sun Microsystems Germany wrote:
Nonetheless, I would not consider initializing b with something
meaningful a mutilation. And be it just because months later, somebody
will be tempted to re-use b some lines below.
Ciao
Frank
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Stephan Bergmann wrote: [...] C2 (M2, M3, M4): Create one CWS for the 20 wntmsci10 modules, svx, and desktop. Testing will be somewhat expensive. We should start this early and see we can integrate early in 2.0.5 timeframe. This could be distributed between three persons, one each for M2--M4. (Any volunteers?) I just started CWS sb59 for this. For the wntmsci10 modules, I will see how far I get on my own before spreading the work (as those modules are already warning-free for Linux/Solaris, there should not be too much to do). For svx, Christian Lippka will coordinate who fixes what. -Stephan [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Stephan Bergmann wrote: Kay Ramme - Sun Germany - Hamburg wrote: Hi, please correct me, if I am wrong. I understand this as a 'C' inherited C++ oddity (no constructors for integral values), which leads to a warning if the first operation on the integral value is not classified as assignment. Obviously 'operator =' has not been classified as assignment at least not for the right operand. No, the compiler does not assume the user-supplied operator = has any assignment semantics. Rather, as the operator = is inline, GCC tries I thought that this is what I said ;-), however. So, it seems that we have used the wrong operator here. Therefor I tend to agree to Frank, that we may want to fix this. The choice of operator is indeed unfortunate. However, I do not agree that - T b; + T b = T(); is in general a fix that improves code quality. Certainly not in general, only for the places the warning gets emitted. And only for the reason, that we may have chosen the wrong operator. If I get it right, the compiler makers are more or less in a dilemma. -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Seeking for guide
Xu, Shenshen wrote: Hello Everybody, Could anybody tell me what is the meaning of the return value of IMPL_LINK, I found some of the codes return 0L and few of the codes return 1L, I wonder what the difference is ? The meaning is that returning 0 means that the link wasn't executed successfully while returning any other value means success. As in most cases nobody cared for the return value on the calling side it's possible that also meanwhile nobody cares for it anymore on the called side. :-) Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] About encryption in OOo
Thomas Schaap wrote: Also, I couldn't find exactly what is being hashed for this checksum. I'm suspecting it's the unencrypted version of the file, so one can quickly see whether the decryption was succesful using a particular password. Am I correct here? The ODF standard is not quite clear on this, alas, yet it does seem the most logical thing to do. Yes, it's the unencrypted version. How it is done exactly can be found in the signDocumentContent method of the service com.sun.star.security.DocumentDigitalSignatures. It is called from sfx2/source/doc/docfile.cxx. Best regards, Mathia -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] website
I propose a change to the wording on the website to refer to the Linux build as Linux_x86 to differentiate it from a Linux_x64 build. The wording for Windows is fine as is because 64 bit Windows runs 32 bit software out of the box. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Hi Stephan, So, it seems that we have used the wrong operator here. Therefor I tend to agree to Frank, that we may want to fix this. The choice of operator is indeed unfortunate. However, I do not agree that - T b; + T b = T(); is in general a fix that improves code quality. Don't know which Ts are affected, but the original example was about sal_Bool, and - sal_Bool b; + sal_Bool b( sal_False ); seems legitimate to me. Besides that: Sure, not every change we did during the warning-freeness ride does directly improve code quality. But this is not the point - it's getting the code to compile without warning :) There will probably always be warnings which are wrong. Remember for instance MSVC's Foo* pFoo = ...; pFoo-doSomething(); which sometimes yields the wrong pFoo might be used without being initialized (or so) warning. In those cases, we simply need to workaround the compiler bug/limitation here. Of course, if there are other alternatives (other than disabling the respective warning completely), then that's fine, too. However, none springs to my mind ... Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
