[feature] reach primitives in non-active parts of a multi-part SchLib component

[BiergitKraft]

Creating multi-part Library Symbols and do changes afterwards.

I'm using this wonderfull tool to generate schematic symbols for my library. It works well when generating single part components, but has some limitations with muli-part components. In a schematic library, obj_query / obj_modify / obj_delete scoped to lib_component:NAME only ever see part 1 of a multi-part component, and OwnerPartId comes back empty. Correcting an existing multi-part symbol therefore requires a full delete-and-rebuild, which throws away everything the API cannot reproduce or was done manually. Generating multi-part components obviously works fine, only doing changes doesn't work.

I tested with the TPS23881B.
Component TPS23881B: 4 parts, 56 pins (part 1 holds 11 power/NC pins).

Call (scope lib_component:TPS23881B)	Result	Expected
obj_query ePin, limit=0	11 objects (part 1 only)	56
… property OwnerPartId	empty string	1..4
obj_modify ePin, filter Designator=<pin in part 3>	matched: 0	matched: 1
obj_modify ePin, filter Designator=<pin in part 1>	matched: 1	matched: 1
lib_get_component_details	56 pins across all parts ✔	—

Proposed solution

Maybe one oft those proposals would work:

Make the `lib_component:` scope part-aware: iterate the component's full primitive collection instead of the current part, and accept a part filter (e.g. `filter="OwnerPartId=3"`).

or

 Expose an explicit selector: `lib_set_current_part(component_name | component_index, part_id)`, or a scope suffix like `lib_component:NAME@3`. Per-call rather than sticky state would keep the current `:= 1` default intact.

and perhaps

Populate `OwnerPartId` in query results regardless of the above. A caller cannot tell which part a returned primitive belongs to.

Alternatives considered

sch_set_component_part_id doesn't work in a schematic library.

Altium API surface

scripts/altium/Library.pas, Function SelectLibComponent (starting line 350), pins the part before every name-based resolution:

Try Component.CurrentPartID := 1; Except End;

The reset itself looks correct — its comment documents the "primitive lands in an invisible bucket" failure it prevents. So I guess you shouldn't remove it, but it would be great to add an way to target another part.

Additional context

I'm using: eda-agent 0.4.0 · Altium script SCRIPT_VERSION 2026.07.25.3 · Altium Designer 26.8.1.31 / Windows 11 · app_ping → version_match: true

[salitronic]

Thanks for the table with actual numbers against a real part. That made it easy to see exactly what was broken.

Fixed differently from your suggestion, and the reason is worth stating: a filter="OwnerPartId=3" cannot work, because the SchLib iterator only ever yields the current part's primitives, so a filter cannot reach parts it never iterates over. The active part has to be switched first.

The scope now takes a part suffix: lib_component:TPS23881B@3 selects part 3. It applies to obj_query, obj_modify, obj_delete and obj_batch_modify, all of which route through the same resolver. Query each part in turn to cover the whole component. OwnerPartId is now readable as a property, where 0 means shared across all parts. The suffix is parsed from the right, so a lib-ref that itself contains @ still works.

Being straight with you: this is not yet covered by a test against a genuine multi-part component, and only obj_query carries the suffix in its docstring so far. Both are on my list. If you can try it against your TPS23881B and report what you see, that would help a lot.

[BiergitKraft]

Hi, thank you for your effort.
I tested against TPS23881B (4 parts, 56 pins: 11 / 17 / 14 / 14). Thanks for turning this around so fast - the suffix reaches the right code path, but the part switch itself does not happen.

Environment

eda-agent 0.5.0 on both sides: app_ping -> mcp_server_version: 0.5.0, altium_script_version: 2026.08.05.1, bundled_script_version: 2026.08.05.1, version_match: true. Altium restarted so the Global Project recompiled from the fresh copy; MCP server restarted so it runs 0.5.0 code (confirmed: part_search / part_fetch are in the registry).

Results

With the library editor showing part A (part 1):

Call	Result	Expected
obj_query ePin, scope ..@1	11 pins, part 1	11
obj_query ePin, scope ..@2	11 pins, part 1	17
obj_query ePin, scope ..@3	11 pins, part 1	14
obj_modify ePin, scope ..@3, filter Designator=10	matched: 0	1
OwnerPartId as a property	"1" - correct	ok

Sharper variant, with the editor switched manually to part C (part 3) - here the suffix and the editor disagree, so the winner is unambiguous:

Call	Result	Expected if the suffix worked
obj_query ePin, scope with no suffix	14 pins, OwnerPartId: "3"	-
obj_query ePin, scope ..@1	14 pins, OwnerPartId: "3"	11 pins of part 1

The suffix is ignored outright; what the editor displays decides.

Had the split failed, CompName would have been TPS23881B@3, GetState_SchComponentByLibRef would have returned Nil, and ApplyLibComponentScope would have produced NOT_FOUND. We got part 1's pins instead, so SelectLibComponentPart('TPS23881B', 3) was reached.

I guess what has no effect is:

Try Component.CurrentPartID := Target; Except End;

Two observations:

1. The editor's part spinner did not move after the @2 and @3 calls - it stayed on part A.
2. The iterator follows the editor's displayed part, not CurrentPartID. With the spinner switched manually to part C and no suffix in the scope:
   • obj_query ePin -> 14 pins, all OwnerPartId: "3" (part 3, correct)
   • obj_modify ePin, filter Designator=10 -> matched: 1

So on a library component, setting ISch_Component.CurrentPartID from the script does not change what the SchLib document iterator yields.

Manually switching the part spinner is a usable workaround: with the editor on part N, unsuffixed obj_query and obj_modify both operate on part N. Enough to correct pin properties without a full symbol rebuild, just not automatable.

Happy to re-test on the same part as soon as you have something.

[salitronic]

Partly addressed, and staying open because the part you actually asked
about is not fixed.

Landed in #19 (e8602fd, f325336), plus follow-ups:

• lib_get_pin_list reports owner_part_id per pin, so a multi-part
  symbol's pins can be read with the part they belong to.
• lib_set_pin_owner_part moves pins to a sub-part or to Part Zero.
  SetSchProperty had no OwnerPartId writer at all before this.

What your table describes is still true. obj_query scoped to
lib_component:NAME sees only the editor's CURRENT part, so an ePin
query on a four-part symbol still returns part one's pins rather than
all of them, and obj_modify filtered on a pin in another part still
matches nothing.

The @N scope suffix exists in the code and does not work. It is
confirmed broken rather than merely unverified, which is worth stating
because reading the source suggests otherwise.

So the workaround is narrower than before rather than gone:
lib_get_pin_list will show you every pin and its part, and
lib_set_pin_owner_part will move them, but the generic obj_ tools
still cannot reach a primitive outside the active part.

Your lib_get_component_details observation was the useful tell: that
reader sees all pins across all parts, so the data is reachable and it
is the scope resolution that is limited, not the API.