@Wayne, I mean neither of the above (I'm ok with selecting a net for a track/via/pad in the respective dialogs), I meant the code in dialog_track_via_properties.cpp (lines 343 onwards):
for( D_PAD* pad : connectedPads )
{
if( pad->GetNetCode() != newNetCode ) changingPads.push_back( pad );
}
....
It propagates the new (changed) net of a track edited through the Track/Via properties dialog to all pads connected to that track. Kicad asks if the user wants these pads nets to be changed, but IMHO it's still dangerous and just not the way proper PCB designs are made (there are people who want to draw PCBs without drawing a schematic/having a netlist, but should we cater for such exotic needs?). It also triggers a hidden bug in the connectivity algorithm which this report is about, but it wouldn't have surfaced otherwise.
@Wayne, I mean neither of the above (I'm ok with selecting a net for a track/via/pad in the respective dialogs), I meant the code in dialog_ track_via_ properties. cpp (lines 343 onwards):
for( auto& item : m_items ) cast<BOARD_ CONNECTED_ ITEM*>( item );
connectivi ty->GetConnecte dPads( boardItem, &connectedPads );
{
auto boardItem = static_
}
for( D_PAD* pad : connectedPads )
changingPads. push_back( pad );
{
if( pad->GetNetCode() != newNetCode )
}
....
It propagates the new (changed) net of a track edited through the Track/Via properties dialog to all pads connected to that track. Kicad asks if the user wants these pads nets to be changed, but IMHO it's still dangerous and just not the way proper PCB designs are made (there are people who want to draw PCBs without drawing a schematic/having a netlist, but should we cater for such exotic needs?). It also triggers a hidden bug in the connectivity algorithm which this report is about, but it wouldn't have surfaced otherwise.
Tom