kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #28513
Re: [RFC] Strange libedit behaviour
As an extra note to Example B in the above comment, deleting a pin also
deletes any pins in other units (for multi-unit symbols) that are in the
same location.
On Wed, Mar 8, 2017 at 12:04 AM, Oliver Walters <
oliver.henry.walters@xxxxxxxxx> wrote:
> I have recently noticed some very strange libedit behaviour, where
> performing an action on a pin at a given location performs the same action
> on all pins at that same location.
>
> Consider the following examples, where two pins are located in the same
> x,y position:
>
> Example A - Edit Pin
> - Place two pins in the same position
> - Edit one (e.g. Press "E" and clarify selection
> - Change anything except for pin number (name, type, length)
> - Hit "ok"
> - All pins at that location will be set to the parameters in the window
> (except for pin-number)
>
> Example B - Delete pin
> - Place two pins in the same position
> - Delete one pin (after clarifying selection)
> - All pins are deleted
>
> The offending source code is here:
>
> Example A
> lib_pin.cpp
>
> Here most functions to edit a given pin act on given pin children of the
> parent, which is exposing all the other pins at the same location...
>
>
> Example B
> libeditframe.cpp : 1345
>
> if( m_drawItem->Type() == LIB_PIN_T )
>>
>> {
>>
>> LIB_PIN* pin = (LIB_PIN*) m_drawItem;
>>
>> wxPoint pos = pin->GetPosition();
>>
>>
>>> part->RemoveDrawItem( (LIB_ITEM*) pin, m_canvas, aDC );
>>
>>
>>> if( SynchronizePins() )
>>
>> {
>>
>> LIB_PIN* tmp = part->GetNextPin();
>>
>>
>>> while( tmp != NULL )
>>
>> {
>>
>> pin = tmp;
>>
>> tmp = part->GetNextPin( pin );
>>
>>
>>> if( pin->GetPosition() != pos )
>>
>> continue;
>>
>>
>>> part->RemoveDrawItem( (LIB_ITEM*) pin );
>>
>> }
>>
>> }
>>
>>
>>> m_canvas->Refresh();
>>
>> }
>>
>>
> Here we have LIB_PIN* item 'pin' which we can delete but then we go
> through and delete all the other pins in the same spot?
>
>
>
>
> a) Is this desired? It doesn't intuitively seem like desired behaviour
> from a user perspective
> b) Why is the code handled in such a convoluted manner here?
> c) I would offer a fix but given how strange the code seems I shall await
> information on a) and b) in case I am missing some intended feature.
>
> Regards,
> Oliver
>
Follow ups
References