Re: [dev] Programmatic control of Toolbar Items: ComboBox possible?
Matthias Benkmann wrote: On 8/31/05, Carsten Driesner [EMAIL PROTECTED] wrote: That would be great as I'm currently evaluating different implementation options for one of our projects. Hi Matthias, Sorry for the late answer, but I was very busy. I give you a first draft how you can add a combo box to a toolbar. Be aware that this solution needs some effort: 1. You have to implement a toolbar controller to be able to use a combo box in the tool bar. 2. You have to create a uno package. The configuration file org.openoffice.Office.UI.Controller.xcu contains all registered user interface controllers. You have to add your new toolbar controller in the configuration set ToolBar. There are some examples in an installed OOo, see Office installation/share/registry/data/org/openoffice/Office/UI/Controller.xcu. An toolbar controller in the Controller.xcu must provide three properties: - Command: The command which is associated with your toolbar controller. - Module: You can associate a controller with a certain module or leave this empty, so your controller is created for all application modules. - Controller: This is the implementation name of your uno service. 3. You have to implement the com.sun.star.frame.ToolbarController service. It's responsible to create the combo box and provide it to the toolbar implementation. You also have to support several listeners to react on user input. 4. You have to create you combo box with the toolkit service: com.sun.star.awt.Toolkit. It has one interface com.sun.star.awt.XToolkit, where you can call createWindow(...). 5. The toolbar controller has to provide the combo box in the call createItemWindow(...) . You have to use the provided parent window to create your combo box (see interface com.sun.star.frame.XToolbarController). These are the first steps to add a custom combo box into a toolbar. You should adapt an add-on example from the SDK, so don't have to start from the scratch. Regards, Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Hi all, Ken Foskey wrote: So I would actually recommend against an all out warnings push unless everyone is VERY clear the objective is to highlight bugs not to remove warnings. The difference in objectives is very important. Yes, but given the mass of code we have, the only way I see to really highlight bugs, is to remove as much as all warnings. 2 To reach that main objective, we have to remove warnings from the current code base. There are to cases: 2a The warning indicates an error in the code. We will fix that error (which is a positive side effect of the efforts spent on this CWS; [...]) 2b The warning is a spurious one. However, to reach the main objective, we have to make it go away anyway, by modifying the code base in some way or other. This (as well as deciding whether the occurence of a warning is case 2a or 2b) is a delicate task, to be sure. I agree with Stephan, that - though this task may be delicate in a few cases (most cases I had a look at are quite simple) - it is necessary. And as the software professionals and/or enthusiasts we are, I don't really think it is impossible. This is just our work. Nikolai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Hi,
Ken Foskey wrote:
I am also concerned that then process will become a template fix.
if( fp = fopen( file, r )) {
can become:
if( (fp = fopen( file, r)) ) {
If I assign someone to clean up the error, say a junior programmer
because it is menial, and we have this code:
if( x = 4 ) {
They may very well apply the 'template' solution hiding a useful
warning.
if( (x = 4) ) {
Well, I just assume that the people who do this task are experienced
enough to first understand the code - and only then change it.
- - -
A little sidetrack: I would not suggest to change
if( fp = fopen( file, r )) {
into
if( (fp = fopen( file, r)) ) {,
because the first not only issues a warning, but also is probably not
exception safe.
So rather I'd write:
fp = fopen( file, r );
if(fp != NULL) {
to remove the warning.
And then something similar to
fp = fopen( file, r );
if(fp != NULL) {
FileGuard fg(fp); // will close file in destructor
to ensure exception safety.
Nikolai
That useful warning being removed is WORSE than the problem of many
warnings. This gets really tricky when you get into essoteric C++
warnings.
The objective of the push should be to highlight bugs by removing as
many warnings with obvious solutions as possible. If in doubt leave the
warning!
As Pavel has hinted it is possibly better to work through one warning
class at a time, eg assignment bugs. This can be discussed so that the
approach to each is correct, eg don't just bracket them.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] compiler warnings: STLport; doubunder; OSL_VERIFY
Hi, Eike Rathke wrote: Hi Stephan, On Wed, Aug 31, 2005 at 10:04:47 +0200, Stephan Bergmann wrote: Sorry for the (may be stupid) question, but why not just change OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect that only weird code would relay on the evaluation in case of a zero debug level. And these case can probably easily be changed to something with assert (or ensure). No, the code I saw was of the form OSL_VERIFY(close(f) = 0); Well, to me that _is_ weird code. The programmer tried to save a variable and an assignment of the return value to the variable, but trades that in for not detecting an unsuccessfull close() in an OSL_DEBUG_LEVEL == 0 build, and not reacting on it. That's not only bad style, that's ugly, and maybe even wrong code. If the file that is being closed was written to, this is almost certainly a bug. If the file was opened read-only, then ignoring the result of close() is generally OK. In that case the programmer may have added this assertion to catch cases where the close fails due to an invalid file descriptor (e.g. a double close), which would indicate a logic error, or simply to document their (erroneous) assumption that close() can't fail after reading a file. So for a read-only file this might be acceptable, but as it is of very limited utility even in that case, the assertion should better be dropped. Leaving statements of debug macros in a product version most times leads to unnecessary code being executed, instead nasty uses such as above should be detected and eliminated and then OSL_VERIFY() set to empty for OSL_DEBUG_LEVEL == 0. As stated elsewhere: It is the one and only purpose of OSL_VERIFY to provide a construct that allows asserting on a expression that must be evaluated every time, including in the product version. All uses of that macro should contain expressions with a side effect. Your proposal is to make OSL_VERIFY identical to OSL_ASSERT (in which case it should be dropped completely). The nastyness in the above example is not that code with side effects is embedded in a debug macro (that is as intended). The nastiness is that an assertion is used in place of proper handling of runtime errors. But that is not specific to OSL_VERIFY. There are loads of places in the office where error return codes or caught exceptions are 'reported' by an OSL_ASSERT or OSL_ENSURE - and then ignored. BTW: In my experience the usual debug macros have the potential for much more serious errors, when code with side effects is used in an assertion. In that case they may cause necessary code to not be executed in product versions or they may change the entire flow of control, leading to hard to debug problems. Btw, since when would a close() return a value 0 ?!? Apparently this is inverting the common logic of checking if (close(f) 0) handle_error(); But I agree that it looks unusual and ==0 should be used to check success. Ciao, Jörg -- Joerg Barfurth Sun Microsystems - Desktop - Hamburg using std::disclaimer Software Engineer [EMAIL PROTECTED] OpenOffice.org Configuration http://util.openoffice.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Another reason not mentioned is that few compilers complain a lot
about such compact constructs as assignments in if statements, which
leads to another reason why warning-free code is much better (I didn't
see this in the introduction post by Stepahn): What gives warnings on
one Operating System, might *break* on another.
Also I would like to know if Sun Hamburg is interested in warnings
that only come from Mac OS X, or whether community members can work on
that in another cws, etc.?
I ask this because it was said that only Linux, Win32 and Solaris will
be taken care of.
Thanks.
2005/9/2, Nikolai Pretzell [EMAIL PROTECTED]:
[...]
So rather I'd write:
fp = fopen( file, r );
if(fp != NULL) {
to remove the warning.
And then something similar to
fp = fopen( file, r );
if(fp != NULL) {
FileGuard fg(fp); // will close file in destructor
to ensure exception safety.
Nikolai
--
Best Regards
Christian Junker
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[dev] Strange Bug in StarBasic? Function returning null instead of empty
I have a problem with a recursive function in one of my macros. The function is supposed to either return an array of strings or Empty (in case there's not enough input data). However, under some circumstances the function mysteriously returns Object/Null instead of Variant/Empty. I'd like to know if this is a bug in OOo (I tested 1.9.122 and 1.9.125) or some misunderstanding on my part. The following is a chopped down version of my code: Sub Main Dim n(1) as String n(0) = n(1) = Dim a as Variant f(Array(60,10,1,12,20,10,25,30), n(), 0, 76) End Sub Function f(splitInfo() as Variant, daten() as String, i as Long, j as Long) as Variant If i UBound(daten) Then Exit Function End If Dim ret() as String for k = 0 to UBound(splitInfo) restLen = Len(daten(i)) - j Dim splitPos as Long splitPos = splitInfo(k) If splitPos = restLen Then j = j + splitPos Else st = Right(daten(i), restLen) i = i + 1 j = 0 sta = f(Array(splitPos - restLen), daten, i, j) If IsNull(sta) Then MsgBox(This is impossible!) Exit Function End if End If next k f = ret() End Function As you can see there are only 2 ways out of the function f(). The first one is an Exit Function that is called without an assignment to the function's return value. On this code path the function is supposed to return Variant/Empty. The 2nd way out of the function is after the assignment f = ret() which sets the return value to an array of string. There should be no way for the function to return Variant/Null, so the condition IsNull(sta) should never be true. But strangely it is at some point. If I call the function directly from Main with the exact same parameters as the recursive call that returns Null, I get Empty as it should be. So it seems that Null is returned only in the recursive case. Can someone give me a clue what's going on? Is this a bug? Should I file a bug report? Matthias
[dev] License Simplification
All, On 2 September 2005 Sun Microsystems announced that it was retiring the Sun Industry Standards Source License (SISSL), an Open Source Initiative (OSI)-approved software license. In recent weeks, the OSI, which authorises open-source licenses, has been discussing limiting license proliferation, so as to make the process of choosing a license easier for developers and companies. Sun's move is in support of that objective. How does this move affect OpenOffice.org? As most know, OpenOffice.org code was launched under the dual banner of the SISSL and LGPL; licensees could choose which one they wanted to use, and nearly all have chosen the LGPL. Effective with the announcement that Sun is retiring the SISSL, however, OpenOffice.org will in the future only be licensed under the LGPL. For users, the simplification means: no change. OpenOffice.org remains free to use, distribute, even sell. One can freely use it in commercial as well as government environments; nothing has changed. For vendors, distributors, add-on and plug-in writers of OpenOffice.org: The LGPL allows for commercial distribution without affecting derived products in the same way as the GPL. For developers and other contributors: As the code will be licensed only under the LGPL, modifications to the source must be published. (The SISSL did not require all changes to the source to be published.) As most OpenOffice.org contributors are already openly contributing to the community, we anticipate no problems. And for those who have been using the SISSL exclusively, we invite you to join us. The OpenOffice.org Community Council http://council.openoffice.org http://www.openoffice.org/FAQs/license-change.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dev] menu bar and toolbars listener
Hi, how can I obtain the references to the menu bar and toolbars of a text document?Because I want to register a XActionListener to that objects, if it is possible, in order to receive all the events thrown by the toolbar buttons and the menu items. Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
