Hi Weike,
Liang Weike wrote:
> 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?
It took me some time but now I think I understand the current
implementation and your proposed changes:
1. If only one object is selected then both do the same thing (the same
is true when no object is selected but that is a trivial case).
2. When two or more objects are selected then the current implementation
returns SDRCONTEXT_GRAPHIC or SDRCONTEXT_MEDIA when all these objects
are either graphic objects or media objects, respectively.
3. Your proposed changes return SDRCONTEXT_GRAPHIC or SDRCONTEXT_MEDIA
when at least one object is a graphic object or a media object,
respectively.
The proposed changes do fix this issue but would lead to other problems.
What when the multi-selection does contain a normal shape, a graphic
object, and a media object? Which tool bar is to be shown in this case?
I think that the real problem lies on more level deeper. Why is there a
multi selection after the conversion to bitmap in the first place?
When the conversion is triggered then a bitmap object is created. It
then replaces the rectangle (or whatever it was before) by calling the
SdrEditView::ReplaceObjectAtView() method. The replacement works as
designed but the selection is not adapted accordingly.
The set of selected objects is organized in the so called mark list.
Selecting an object means inserting it into the mark list. Removing an
object from the mark list deselects it. When ReplaceObjectAtView() is
called then the new object is selected but the old object is not
deslected: the mark list still holds a reference.
Explicitly deselecting the old object fixes the issue:
Index: svdedtv.cxx
===================================================================
RCS file: /cvs/graphics/svx/source/svdraw/svdedtv.cxx,v
retrieving revision 1.23
diff -c -r1.23 svdedtv.cxx
*** svdedtv.cxx 6 Jul 2007 07:39:35 -0000 1.23
--- svdedtv.cxx 16 Nov 2007 09:46:38 -0000
***************
*** 844,849 ****
--- 844,850 ----
{
SdrObjList* pOL=pOldObj->GetObjList();
AddUndo(GetModel()->GetSdrUndoFactory().CreateUndoReplaceObject(*pOldObj,*pNewObj));
+ MarkObj(pOldObj,&rPV,TRUE);
pOL->ReplaceObject(pNewObj,pOldObj->GetOrdNum());
if (bMark) MarkObj(pNewObj,&rPV);
}
Have a nice weekend,
Andre
>
> 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]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
