I'd like to know if the new programmatic control of menu and toolbar items
feature will allow me to create a custom ComboBox in a toolbar. Thanks.
Matthias
Stephan Bergmann wrote:
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
Matthias Benkmann wrote:
I'd like to know if the new programmatic control of menu and toolbar items
feature will allow me to create a custom ComboBox in a toolbar. Thanks.
Hi Matthias,
I think it's possible, but there is no easy way to do it. We plan to
implement an easy way for the next
Speaking of STLPort: It seems that these incredible number of
ANACHRONISM warnings regarding missing typenames on unxsols4 and
unxsoli4 can be fixed with a single line of change in STLPort. I'll
suggest that we fix this one in another CWS which has a chance to get in
OOo 2.0, if Martin
Kay Ramme - Sun Germany - Hamburg wrote:
Stephan Bergmann wrote:
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
Hi Kay,
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.
Why weird? The alternative is something like
#if
Stephan,
Stephan Bergmann wrote:
Maybe we could, but *not* on CWS warnings01. We already have enough to
do here to get rid of all warnings. If we take the burden of any
additional clean up (like unifying OSL_ENSURE and OSL_ASSERT) that is
not directly necessary to get rid of warnings, we
Hi,
sorry, could not resist...
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.
Why weird? The alternative is something
Jens-Heiner Rechtien wrote:
Speaking of STLPort: It seems that these incredible number of
ANACHRONISM warnings regarding missing typenames on unxsols4 and
unxsoli4 can be fixed with a single line of change in STLPort. I'll
suggest that we fix this one in another CWS which has a chance to get
On 8/31/05, Carsten Driesner [EMAIL PROTECTED] wrote:
If you want to try the hard way, please let me know and I will give a
summary how you can do it.
That would be great as I'm currently evaluating different implementation
options for one of our projects.
Matthias
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
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.
Why weird?
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
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.
Why weird?
Hi Kay,
Oh, while we're at it, let me throw in one of my favourites: Shouldn't
we consolidate the DBG_* and OSL_* diagnostics macros?
YES, YES, YES. May be you have some time the next weeks, to dive into
more details?
Count me in. The current inconsistencies suck^Ware cumbersome and
annoying
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
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.
Why weird?
Hi Philipp,
Philipp Lohmann - Sun Germany wrote:
I definately think that
OSL_VERIFY( callSomeFooWhichSignalsSuccess( bar ) );
is the better (non-weird) alternative here.
That case is weird, because you choose to ignore the return value. In
that you create a possibly not easy to find
Philipp Lohmann - Sun Germany wrote:
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
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
Stephan Bergmann wrote:
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
Kay Ramme - Sun Germany - Hamburg wrote:
Philipp Lohmann - Sun Germany wrote:
Can I interpretate this in a way, you to be willing to join our diagnose
and debug macro consolidation meeting?! So, watch out for an event
notification for sometime next week :-)
Very good, that will test the
Philipp Lohmann - Sun Germany wrote:
Kay Ramme - Sun Germany - Hamburg wrote:
Philipp Lohmann - Sun Germany wrote:
Can I interpretate this in a way, you to be willing to join our
diagnose and debug macro consolidation meeting?! So, watch out for an
event notification for sometime next week
Joerg Barfurth wrote:
Hi Kay,
Kay Ramme - Sun Germany - Hamburg 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.
Hi Philipp,
I definately think that
OSL_VERIFY( callSomeFooWhichSignalsSuccess( bar ) );
is the better (non-weird) alternative here.
That case is weird, because you choose to ignore the return value. In
that you create a possibly not easy to find error. Ignoring return
values is just bad
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Stephan,
As I wrote before, I think
if (!callSomeFooWhichSignalsSuccess(bar)) {
OSL_ENSURE(false, this was expected to succeed!);
}
is the better alternative to the OSL_VERIFY above, as it does not
violate the Principle of Least
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
It is the very purpose of OSL_VERIFY to evaluate the expression
regardless of debug level. For expressions without side effect
OSL_ASSERT/OSL_ENSURE should be used instead.
It is used to avoid cluttering the code with
Joerg,
Joerg Barfurth wrote:
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
I agree. If they signal runtime conditions that prevent normal
operations, they can be converted to exceptions, otherwise they should
be dealt with or propagated as approriate. (I think
Hi Stephan,
At OSL_DEBUG_LEVEL == 0,
OSL_VERIFY(callFoo(bar) == good);
is just
((void)(callFoo(bar) == good);
which you also trust the compiler to simplify.
Honestly: no, I wouldn't. I would have expected that this is simply
expanded to
callFoo(bar) == good
There's probably
Hi Frank,
Frank Schönheit - Sun Microsystems Germany wrote:
Hi Kay,
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
In Message-ID: [EMAIL PROTECTED]
Stephan Bergmann [EMAIL PROTECTED] wrote:
3 WE NEED YOU!
Here at Hamburg, we will only concentrate on those platforms we build
ourselves. Also, due to the fact that our build environment is slightly
different from a typical OOo build environment, we may
27 matches
Mail list logo
