https://bugs.documentfoundation.org/show_bug.cgi?id=97299
Julien Nabet <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |[email protected] Ever confirmed|0 |1 --- Comment #1 from Julien Nabet <[email protected]> --- On pc Debian x86-64 with master sources updated yesterday, I could reproduce this. It seems "No effect" is considered as "ambiguous effect" (see http://opengrok.libreoffice.org/xref/core/sd/source/ui/animations/SlideTransitionPane.cxx#138) In fact, every effect is considered first as ambiguous effect. Then SlideTransitionPane::getTransitionEffectFromControls() (see http://opengrok.libreoffice.org/xref/core/sd/source/ui/animations/SlideTransitionPane.cxx#761) updates it but only in this case: if( mpVS_TRANSITION_ICONS->IsEnabled() && !mpVS_TRANSITION_ICONS->IsNoSelection() && mpVS_TRANSITION_ICONS->GetSelectItemId() > 0 ) In "No effect" case, !mpVS_TRANSITION_ICONS->IsNoSelection() is wrong and mpVS_TRANSITION_ICONS->GetSelectItemId() = 0 I suppose related to this: 591 // ToDo: That 0 is "no transition" is documented nowhere except in the 592 // CTOR of sdpage 593 if( aEffect.mnType == 0 ) 594 mpVS_TRANSITION_ICONS->SetNoSelection(); 595 else 596 updateVariants( getPresetOffset( aEffect ) ); (from same file) Hope it helps a bit. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
