Re: [dev] Warning free code: the missing modules
Kay Ramme - Sun Germany - Hamburg wrote: 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. I do not understand why the choice of function name should motivate us to change or not to change some code so that the (imperfect) definitive-assignment-analysis of some compiler does not cause problems. (The chosen function name operator = is IMO unfortunate in that a human reader might assume modification of the lhs, whereas it actually does assignment to the rhs.) If I get it right, the compiler makers are more or less in a dilemma. Why? They just need to be conservative in definitive-assignment-analysis and do not emit warnings if the compiler is not sure that a variable has definitely not been assigned a value (as most compiler versions seem to do). -Stephan -Stephan Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Frank Schönheit - Sun Microsystems Germany wrote: 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. With GCC 4.0.2, sal_Bool and other small integral types like sal_Int16, sal_Unicode are affected. With GCC 4.1.1, only those other small integral types are affected (which are used considerably less often in conjunction with com::sun::star::Any than sal_Bool). In the case of sal_Bool, it might be true that false is a better default value than true (no pun intended), but that need not be the case always, so you would have to analyze each place in the code where you add = false, which is tedious due to the large number of places involved. And still, I personally consider it a degradation of code quality to explicitly assign an (arbitrary) default value to a variable in places where it is obvious that the variable is only used after definitively having been assigned to (in places where that is not obvious, I think it is often better to restructure the code to make that obvious, than to initially assign an arbitrary dummy value to the variable; rationale: in the latter case, the reader has to scan the code to find out whether the initial assignment is of importance, or merely there to silence warnings from the compiler). 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 :) ...but only on compilers where we can achieve this with a reasonable amount of work. If we would need to make lots of hacky changes to make a single version of GCC work, while most other versions (even more recent ones) of GCC would not need that, I think we should weigh what is more important. That's all I wanted to say. 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 ... Not supporting GCC 4.0.2 is the alternative that springs to my mind (see above). -Stephan Ciao Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Mac Os X - X11 ?
Hvor kan jeg få tak i tillegget X11 for å kunne bruke OpenOffice på min maskin med operativsysten Mac OS X, versjon 10.4.7? Mvh Jens R. Knutsen [EMAIL PROTECTED] Tlf 76952281 - mobnr; 905 03 178
Re: [dev] Warning free code: the missing modules
Hi Stephan, In the case of sal_Bool, it might be true that false is a better default value than true (no pun intended), but that need not be the case always, so you would have to analyze each place in the code where you add = false, which is tedious due to the large number of places involved. Sure, this analysis has to take place. forgive me if I missed this in the thread: About which order of magnitued do we talk here? 10 places? 1? And still, I personally consider it a degradation of code quality to explicitly assign an (arbitrary) default value to a variable in places where it is obvious that the variable is only used after definitively having been assigned to (in places where that is not obvious, I think it is often better to restructure the code to make that obvious, than to initially assign an arbitrary dummy value to the variable; rationale: in the latter case, the reader has to scan the code to find out whether the initial assignment is of importance, or merely there to silence warnings from the compiler). Well, the warning could be an indicator to think about whether restructuring would be a good idea here ... That's the basic idea behind warnings, isn't it? Sometimes, they point to an error - then fix it. Sometimes, they don't, then check whether you can write code which doesn't expose the warning. This does not always mean silence the warning by brute force (which is assigning a default in our case), but restructure your code so it becomes better and less warning-prone is of course always a valid alternative :) ...but only on compilers where we can achieve this with a reasonable amount of work. If we would need to make lots of hacky changes to make a single version of GCC work, while most other versions (even more recent ones) of GCC would not need that, I think we should weigh what is more important. That's all I wanted to say. Okay, I agree. As said, I might have missed the number of places affected. For a certain amount, I'd probably also say it's not worth it ... (though my gut feeling is that my limit would be higher than your's here :) Not supporting GCC 4.0.2 is the alternative that springs to my mind (see above). Okay, cannot judge how many people will be repelled by this. But if it's as buggy as you say, this might be no problem, anyway ... 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]
Re: [dev] Warning free code: the missing modules
Frank Schönheit - Sun Microsystems Germany wrote: Hi Stephan, In the case of sal_Bool, it might be true that false is a better default value than true (no pun intended), but that need not be the case always, so you would have to analyze each place in the code where you add = false, which is tedious due to the large number of places involved. Sure, this analysis has to take place. forgive me if I missed this in the thread: About which order of magnitued do we talk here? 10 places? 1? 10^2--10^3 would be my guess -Stephan [...] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning free code: the missing modules
Hi Stephan, forgive me if I missed this in the thread: About which order of magnitued do we talk here? 10 places? 1? 10^2--10^3 would be my guess Hmm, that's quite a lot ... 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]
Re: [dev] Seeking for guide
Mathias Bauer wrote: 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. nitpick Actually the return value is a matter of negotiation between caller and callee - an implementation detail so to speak. In some case you might find more values than 0 or 1. Think of a Link as an early version of boost::bind, a safe function pointer. /nitpick 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. :-) Yes, that too :-) Kind regards, pl -- If you give someone a program, you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime. -- Author unknown - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Re: paragraph number
Hello, I have read somewhere that version 2.0.3 does that easily. ___ On 18th of July 2006 02:40, Mohammad Alhammouri wrote : 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Set default posSize for new created Windows
You could add this Snippet to our collection:
http://codesnippets.services.openoffice.org/
Tom
Christoph Lutz schrieb:
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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Asian CJK Group Announced!
Hi Jianhua and all, On 7/18/06, jiao jianhua [EMAIL PROTECTED] wrote: Good luck. Thanks. Developer's help are essential to improve CJK functionality, usability and accessibility. Please feel free adding your idea to improve them at: http://wiki.services.openoffice.org/wiki/CJK_Group Regards, khirano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Asian CJK Group Announced!
Hi Stanley and all, Congrantulations! Thanks. This group will allow these three projects to share experiences on common L10N and I18N issues We often face gsl issues such as font rendering, vertical writing, use of grid, pdf export etc. I hope the Group help share our experience and improve CJK use with OpenOffice.org. Regards, khirano - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
