Hi Andre,
I tracked the issue step by step once more. Yes, you're right. The wrong
context leads to the issue. I think, the real problem occurs where the
method "SdrViewContext SdrView::GetContext() const" within svx module is
invoked. And it returns SDRCONTEXT_STANDARD rather than
SDRCONTEXT_GRAPHIC. The original and responsible code is strange from my
point of view. So I modify the code included in that method and the
changes are as follows:
diff -uNr old/svx/source/svdraw/svdview.cxx
new/svx/source/svdraw/svdview.cxx
--- old/svx/source/svdraw/svdview.cxx 2007-11-16 11:50:26.000000000 +0800
+++ new/svx/source/svdraw/svdview.cxx 2007-11-16 11:49:36.000000000 +0800
@@ -1227,16 +1227,20 @@
if( GetMarkedObjectCount() )
{
- BOOL bGraf = TRUE, bMedia = TRUE;
+ BOOL bGraf = FALSE, bMedia = FALSE;
- for( ULONG nMarkNum = 0; nMarkNum < nMarkAnz && ( bGraf || bMedia );
nMarkNum++ )
+ for( ULONG nMarkNum = 0; nMarkNum < nMarkAnz; nMarkNum++ )
{
const SdrObject* pMarkObj = GetMarkedObjectByIndex( nMarkNum );
- if( !pMarkObj->ISA( SdrGrafObj ) )
- bGraf = FALSE;
+ if( pMarkObj->ISA( SdrGrafObj ) )
+ bGraf = TRUE;
+ else
+ bGraf = FALSE;
- if( !pMarkObj->ISA( SdrMediaObj ) )
+ if( pMarkObj->ISA( SdrMediaObj ) )
+ bMedia = TRUE;
+ else
bMedia = FALSE;
}
And now the code works well in my computer and the phenomenon of the
issue does not exist. So could you please help check it?
Best regards,
Weike
> Hi Weike,
>
> Liang Weike wrote:
>
>> Hi Andre,
>>
>> I made an investigation of issue 73871 and tracked it.
>>
>> While the rectangle is converted into bitmap the program should add
>> "graphicobjectbar" to the tool bar. During the procedure the
>> toolbarmanager in sd module will add it and then post the update. And
>> within the method "void ToolBarManager::Implementation::PostUpdate
>> (void)" there is the line "mxLayouter->requestElement(sFullName);" which
>> passes to the layoutmanager involved in framework module to handle the
>> element of toolbar. But the method requestElement doesn't work well: the
>> layoutmanager does not request it successfully. So should the method
>> requestElement be modified to make the return value true?
>>
>
> No. I just stepped through this code and found that after the
> conversion from rectangle to bitmap PostUpdate() is called with an empty
> set of tool bars that is to be activated. So the problem occurs earlyier.
>
> When the bitmap has been created the old shape is replaced with the new
> bitmap shape. This leads to a change of the selection, which in turn
> triggers eventually the ToolBarRules::SelectionHasChanged() method.
> Here a context is retrieved from the view and the set of active tool
> bars is adapted accordingly.
> The context after the conversion should be SDRCONTEXT_GRAPHIC but for
> some reason it is SDRCONTEXT_STANDARD. Probably the context has not yet
> been updated. When the user deselects the new shape and then selects it
> again the same SelectionHasChanged() method is called but this time the
> context is correct.
>
> So, find out why the context is not updated when SelectionHasChanged()
> is called and the fix of this issue will probably present itself.
>
>
>> Best regards,
>> Weike
>>
>>
>
> Best regards,
> Andre
>
>
>> ---------------------------------------------------------------------
>> 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]
>
>
