[dev] When? (was Re: [dev] License Simplification)
Hi, Martin Hollmichel wrote: Hi, [...] I expect that this cws is ready for integration next week in time for OOo 2.0 release. [...] Some of my customers want to plan their migration to 2.0. Can someone pls give an estimate of the expected release week? Thanks a lot, -- Cor Nouws http://www.nouenoff.nl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] License Simplification
Hi, the child workspace ooo19126 (http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=3007&Path=SRC680%2Fooo19126) has been created for all the necessary changes in the source code. I expect that this cws is ready for integration next week in time for OOo 2.0 release. The pages http://www.openoffice.org/license.html http://www.openoffice.org/FAQs/faq-licensing.html are already updated, other documents contained in the product like README and license text will be updated win the above mentioned child workspace. JCA keeps to be required, this license change is a good example how the joint copyright helps. Martin Éric Bischoff wrote: Le Vendredi 2 Septembre 2005 19:02, Louis Suarez-Potts a écrit : 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. Sorry in advance if these are stupid questions: 1) All source files for OpenOffice.org start with some legalese explaining the dual licensing. Are there plans to automatically adjust all these texts before 2.0 ? 2) Same goes for initial End User License Agreement, READMEs, web server, ... 3) Will JCAs still be required in the future ? Or is it the occasion to have less formal procedures ? My two Vogon cents... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] License Simplification
Le Vendredi 2 Septembre 2005 19:02, Louis Suarez-Potts a écrit : > 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. Sorry in advance if these are stupid questions: 1) All source files for OpenOffice.org start with some legalese explaining the dual licensing. Are there plans to automatically adjust all these texts before 2.0 ? 2) Same goes for initial End User License Agreement, READMEs, web server, ... 3) Will JCAs still be required in the future ? Or is it the occasion to have less formal procedures ? My two Vogon cents... -- Marre des virus, vers, spywares, adwares et plantages ? Passez à Linux ! - 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]
[dev] Standalone XSLT tranformation to HTML
Please let me know if this is not the most suitable mail list for this question as I'm new to open office. I'm trying to transform from open office doc to HTML in a standalone XSLT process. I've found useful info and tools on the following site http://books.evc-cit.info/oobook/apc.html However when I use the xsl stylesheet that ships with OpenOffice as an export filter (OpenOffice\share\xslt\export\xhtml\ooo2xhtml.xsl) I get a blank html file produced. Does anyone know if there is some form of internal translation before the xslt is initiated when using Ooffice 'save as' ? Would it be easier to use the api instead od a straight Xalan XSLT process? Any help, direction or thoughts would be great. King regards, Miles
[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]
Re: [dev] Programmatic control of Toolbar Items: ComboBox possible?
Matthias Benkmann wrote: Hi Carsten, Do you have any specific example(s) in mind? It depends on your goal. If you want to create an add-on with a toolbar containing a combo box, you can select an example which has sample code for all the other work (command dispatching, toolbar definition, ...). If you only want to check how to implement a combo box in a toolbar, you can use every example. Regards, Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] csc.exe
That's great, thanks! For general reference, I'm going to try and put this kind of info in http://www.go-oo.org/wiki/index.php/Windows David Joachim Lingner wrote: Have a look at C:\Windows\Microsoft.NET\Framework\v1.1.4322 Joachim David Fraser wrote: Hi all I'm trying to build OOo under Windows. I have a full version of Visual Studio.NET 2003 installed However I can't seem to find csc.exe configure outputs the following: checking for csc.exe... no configure: error: csc.exe not found. Make sure it's in the path or use --with-csc-path Where should this tool be found, in which directory, and which product install does it come from? I have also installed the Platform SDK and the .NET Framework and .NET Framework SDK but can't find it anywhere... Regards David - 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] - 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
Re: [dev] csc.exe
Have a look at C:\Windows\Microsoft.NET\Framework\v1.1.4322 Joachim David Fraser wrote: Hi all I'm trying to build OOo under Windows. I have a full version of Visual Studio.NET 2003 installed However I can't seem to find csc.exe configure outputs the following: checking for csc.exe... no configure: error: csc.exe not found. Make sure it's in the path or use --with-csc-path Where should this tool be found, in which directory, and which product install does it come from? I have also installed the Platform SDK and the .NET Framework and .NET Framework SDK but can't find it anywhere... Regards David - 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]
[dev] csc.exe
Hi all I'm trying to build OOo under Windows. I have a full version of Visual Studio.NET 2003 installed However I can't seem to find csc.exe configure outputs the following: checking for csc.exe... no configure: error: csc.exe not found. Make sure it's in the path or use --with-csc-path Where should this tool be found, in which directory, and which product install does it come from? I have also installed the Platform SDK and the .NET Framework and .NET Framework SDK but can't find it anywhere... Regards David - 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] Error-handling concept [Was: [dev] assertions, again. Sigh.]
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
Propagating errors is the broader concept, comparing assertions and
error propagation. So, if in doubt, propagate! Never swallow unclear
situations (especially _not_ in _production_ code, following effects
may destroy valuable data), upper levels may know what to do or at
least can wan the user.
This is a nice theory, but one which doesn't fit the reality of 6
So, at least you like the theory?!
I think many people here know how to do things properly when starting
something from scratch, with sufficient time to take care of quality.
If from tomorrow onwards we would propagate every error which today is
"handled" with an assertion only, then in reality OOo would crash every
few minutes, since nobody else will handle it, either. (Take a
non-product build of m125 and try it out.)
We do *not* have a consistent error concept in place, and as much as
this is regrettable, it's also a fact which we cannot change by starting
with "error propagation" in some isolated places.
Interesting, this is a change in attitude. Before, you said (at least
that is how I understood it, please correct me if I am wrong), that the
way how we are currently using assertions etc. is the _correct_ way.
Now, you are saying, that the reason we are using assertions the way we
are using them is historically founded. In other words, implementing the
above theory would be right, if doable at all.
I did not say that, nor afair did Frank. We both said that there are
cases where using assertions is correct and there are such correct uses
of assertions. We both know all too well that there also are many cases
where assertions are being abused in the current code base. And such
cases are still added all the time, even by people who'd like to avoid
that, for the reasons Frank described.
Implementing the above theory would be right, if it were doable with
effort that is justified by the quality improvements.
But even if that theory is implemented completely there remain cases
where using assertions is the correct choice. So the mere fact that
assertion facilities are sometimes abused currently, is not sufficient
to justify removing the assertion facilities.
Some systems support some sort of transactionality. This is the someone
needed. Good error handling has IMO to go hand in hand with
transactionality.
Where possible ,yes. I don't think you can provide transactionality
everywhere with justifiable effort. You may not even be able to
guarantee a predictable state after failure recovery. But in all cases
error handling should lead to a consistent, stable state and do
everything possible to avoid data loss.
If I have the choice between the application crashing (or at least being
non-functional, which today for instance is the result of an access
violation on Windows, e.g. dereferncing a NULL pointer), and between
reacting as if the user didn't do anything, then I choose the latter. We
have zillions of crash reports, and in my opinion [1] there's hardly
something worse than a crash, from a user experience point of view.
I think we had this before. A user loosing data because an application
overwriting his files with nonsense, will _never_ send a crash report.
Yes. But that means that if you find yourself in an unexpected
inconsistent state, you should terminate ('crash') rather quickly and
refrain from any 'saving' actions that might destroy valid data.
And this is the difficult part, IMO: Having a consistent error handling
concept which is *applied across the whole application*. I'm in for
pragmatism here, even if this means not always following the "pure
doctrine" ...
Ever seen the "general I/O error" box when trying to save a document?
Without any clue what was going wrong? And already thinking about how to
best copy the (textual) content into the next emacs window?
This example shows that basic techniques (e.g. 'if in doubt,
propagate!') are not sufficient to produce good error handling. Here an
error obviously is propagated, but when it reaches the stage where it is
handled (i.e. reported) it has lost all detail and context.
We have oh so many cases where errors *are* propagated (e.g. by throwing
an exception) but contain far too little information (*) to truly
recover or meaningfully report/log the error. Effectively these
exceptions are only a enriched 'longjmp()' to back out trouble.
Part of the reason is that one can only provide useful information, if
it is known what it is to be used for. IMHO the semantics of how the
various members of our various exception types are still very much
underspecified. And some of that depends on having a comprehensive error
handling concept (e.g. who is the target audience for the message in an
exception? how will it be used? how about localization?)
(*) Without any message or context information; sample code
if (somethingwentwrong)
throw IOException();
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] Programmatic control of Toolbar Items: ComboBox possible?
Hi Carsten, thanks for the info. Pretty complicated but I think I'll at least give it a try. 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. > Do you have any specific example(s) in mind? Matthias
Re: [dev] compiler warnings: STLport; doubunder; OSL_VERIFY
Hi Stephan and all,
this is an answer to the _original_ posting!
Stephan Bergmann wrote:
1 STLport
I already wrote this before, but maybe it did not get the necessary
attention. To ensure that all spurious warnings from within any STLport
headers are suppressed, the following changes are necessary:
On unxsoli4 and unxsols4 the warnings inllargeuse ("function is too
large and will not be expanded inline") and notemsource ("Could not find
source for function") are globally disabled in each compilation unit
(regardless of whether or not it includes an STLport header), because
those warnings seem to only be generated at the end of a compilation unit.
I think these to be ok, because (correct me if I am wrong):
- inllargeuse
is only an optimization issue, it won't change semantics. It may change
performance, but I consider those cases quite rare.
- notemsource
Won't this be found by the linker again, if it is indeed a problem?
On wntmsci10 the warnings 4514 ("unreferenced inline function has been
removed")
That is a rather useless warning anyway. The inline function may be
needed elsewhere, so this message does not help.
and 4710 ("function not inlined")
I'd have voted to remove this waring from our sets anyway. Why should
non-inlined functions ever be a problem? Good programming practice is to
optimize by inlining only where a real performance need has occurred.
2 doubunder
It is a pity we violate the C++ standard with our identifiers!
But as we do not intend to change this, the warning is rather useless.
3 OSL_VERIFY
On unxsoli4 and unxsols4 PRODUCT builds, OSL_VERIFY(a == b) causes a
spurious warning "The result of a comparison is unused" (because the
argument of OSL_VERIFY is always executed, even for OSL_DEBUG_LEVEL ==
0). Instead of disabling the corresponding unxsoli4 and unxsols4
warning, I would vote to change code
My suggestion would be
#if OSL_DEBUG_LEVEL != 0
// ...
#else
#define OSL_VERIFY(x)
#endif
The issue of consolidating our error/assertion handling is a good one! ;-)
But as Stephan said, not for this CWS!
Nikolai
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Warning-Free Code
Hi all, * Initially I would suggest -Wno-reorder (I think) There are a HUGE number of errors caused simply by the order of the variables in the class declaration and I have only found one instance where it indicated a real error (parent initialisation depended on child data). The needle for this one is small and the haystack particularly large. Because of the pervasiveness of this change merges afterwards a PAINFUL! I speak from experience. I would think about doing this module by module as a separate exercise. Actually, the whole remove-warnings effort is a big effort. I doubt, if we will be able to do a similar large effort soon after. So I would suggest to include this kind of warning the first time, too. The problem with broken patches will happen later as well - so better make it right now, than postpone the problems. Also, as Mathias wrote, I know this warning to highlight very serious errors in a few cases. To find those, we have to remove the other ones (this is the same as what the whole CWS is about: removing the useless warnings to get real information from new ones). 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] 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] 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 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]
