J-Link Model.Rename() always returns XToolkitCantModify

nsalaorno — Mon, 16 Mar 2026 07:55:31 GMT

I am using Creo Parametric Release 12.4 and Datecode12.4.3.0

Subject: Creo 12.4 + Windchill: J-Link Model.Rename() always returns XToolkitCantModify
We are migrating a Java J-Link workflow from Creo 6 to Creo 12.4 in a Windchill-linked environment.
In Creo 12.4, Model.Rename(newName, false) fails consistently with XToolkitCantModify for both .asm and .drw.
Isolated test (minimal):
1. RetrieveModelWithOpts() on MAC_NEXTAIR_2.ASM and MAC_NEXTAIR_2.DRW
2. CheckIsModifiable(false) => true
3. CheckIsSaveAllowed(false) => true
4. Model.Rename(...) => XToolkitCantModify
Manual rename from Creo UI (same environment) works.
We reviewed CS419079 / CS419066 about read-only policy since Creo 10, but our case is unclear because modifiable/save-allowed are true while J-Link rename still fails.
Please confirm:
1. Is J-Link Model.Rename() supported for Windchill-managed models in Creo 12.4?
2. Is checkout mandatory for rename in this context?
3. Is there a known difference between UI rename and J-Link rename?
4. What is the recommended supported API/workflow for renaming Windchill-managed CAD objects?

Re: J-Link Model.Rename() always returns XToolkitCantModify

remy — Tue, 17 Mar 2026 13:20:45 GMT

If this works from the UI then I assume that your application is asynchronous or is it ?

If yes, make sure that the application user runs the same access control profile as the manual session.

Re: J-Link Model.Rename() always returns XToolkitCantModify

RPN — Fri, 20 Mar 2026 10:16:51 GMT

You have set the config option let_proe_rename_pdm* (I’m not in front of a workstation, so this is not the full option name 😉). Take care what you doing here, you may loose Windchill references.

Re: J-Link Model.Rename() always returns XToolkitCantModify

HannesBuxbaum — Sat, 21 Mar 2026 12:24:09 GMT

Re Q1: Not tried in JLink, but in OTK (C++) pfcModel::Rename() does work, so JLink Model.Rename() should work, too. In my tests (OTK), it worked even independent of let_proe_rename_pdm_objects no or yes.

Re Q2: No, checkout is not mandatory for rename in this context (an unlocked object in Creo is), but checkout unlocks the read-only state in Creo. There are other functions for unlocking (TK: ProMdlHasNoConflict(), ProMdlIsModifiable(), JLink: CheckIsModifiable()).

Re Q3: API should behave identically, but small differences can be expected (as in other parts of TK/OTK/JLink sometimes happens). One difference is "independent of let_proe_rename_pdm_objects", as I just learned from my tests.

Re Q4: Renaming Windchill-managed CAD objects: sometimes a Windchill workflow for renaming is preferred, sometimes from within Creo (ootb or custom). Both are supported, since API exists for renaming.

In your case, it looks like the read-only policy for checked-in Windchill objects causes the modifying API call to fail (despite CheckIsModifiable(false) => true; more on this below).
Checked-in objects are read-only by default. They can be unlocked manually and via API.

Note:

To manually determine an object's read-only state, see ribbon Tools -> Parameters:
If there is an "Edit" button (lower right corner), this object is in read-only state (otherwise there is an "OK" button).
An object's read-only state seems to be workspace bound (not just Creo session, as one might think): to reset (activate) the state, undo checkout or remove object from workspace and reopen it (remove from session is not enough).

The first misconception is around ProMdlIsModifiable() or Java: CheckIsModifiable() (and I fell for this, too, since the wording/context is very confusing here):
The boolean result is not the actual modifiable state in Creo in terms of that "Edit" button (in the parameter dialog).

Java API doc CheckIsModifiable():
"[...] when [ShowUI] set to false no UI is enabled and the model is considered as modifiable if there are no conflicts that could not be overridden or resolved by default resolution actions."
This API is looking for conflicts in the workspace and subordinate models - not at this object's read-only state in Creo: it evaluates something else.

My tests with Creo 12.4.0.0 with a part object from Windchill regarding read-only policy since Creo Parametric 10 (CS419079/CS419066):
Using a synchronous OTK (C++) application, using pfcModel::Rename() (but any other modifying API call should also get the same errors, e.g. modifying parameters does).

Results of pfcModel::Rename() for a part that is...

Checked-in/read-only active, let_proe_rename_pdm_objects no or yes: pfcExceptions::XToolkitCantModify
Checked-in/read-only inactive, let_proe_rename_pdm_objects no or yes: No error, successfully renamed.

Conclusion: Error due to read-only state and unrelated to value of let_proe_rename_pdm_objects (while the Creo GUI correctly reflects the setting let_proe_rename_pdm_objects @ File -> Manage File -> Rename).

PTC provided functions for the read-only state with Creo 12 (ProMdlIsModifiable() existed before):
https://support.ptc.com/help/creo/creo_pma/r12/usascii//index.html#page/whats_new_pma/creo_toolkit_read_only_locked_models.html
ProMdlHasNoConflict()
ProMdlsAreModifiable()
ProMdlsHaveNoConflict()

While this functions can unlock the read-only state, they can not reveal the actual read-only state in terms of that "Edit" button (in the parameter dialog) - and the docs never promised this.
I never got any indication for the read-only state from ProMdlHasNoConflict() or ProMdlIsModifiable(), see the test cases below.

Testing ProMdlHasNoConflict() and ProMdlIsModifiable(): using config.pro options:

let_proe_rename_pdm_objects unset (=no*)
dm_auto_conflict_resolution unset (=no*)
dm_checkout_on_the_fly unset (=checkout*)

and test part checked-in/read-only active:

Both functions do not affect check-in or read-only status if 2nd parameter PRO_B_FALSE:

ProMdlHasNoConflict(pMdl, PRO_B_FALSE, &bNoConflict) => PRO_TK_NO_ERROR, bNoConflict => PRO_B_TRUE
ProMdlIsModifiable(pMdl, PRO_B_FALSE, &bIsModifiable) => PRO_TK_NO_ERROR, bIsModifiable => PRO_B_TRUE <- This is the source of misunderstanding, because the object is checked-in & read-only active.

Both functions can affect check-in/read-only status with 2nd parameter PRO_B_TRUE:

ProMdlHasNoConflict(pMdl, PRO_B_TRUE, &bNoConflict) => PRO_TK_NO_ERROR, bNoConflict => PRO_B_TRUE, changed: read-only inactive, optional also check-in state
- triggers automatic Conflict Resolution (always without GUI, dm_checkout_on_the_fly applies)

ProMdlIsModifiable(pMdl, PRO_B_TRUE, &bIsModifiable)
- triggers Conflict Resolution: with or without GUI, depending on dm_auto_conflict_resolution.

-> Answer: Cancel => PRO_TK_NO_ERROR, bIsModifiable => PRO_B_FALSE, nothing changed (still checked-in/read-only active)
-> Answer: make read only, OK => PRO_TK_NO_ERROR, bIsModifiable => PRO_B_FALSE, changed: now also locked (pad lock symbol), (still checked-in/read-only active)
-> Answer: check out, OK => PRO_TK_NO_ERROR, bIsModifiable => PRO_B_TRUE, changed: checked-out/read-only inactive
-> Answer: continue, OK => PRO_TK_NO_ERROR, bIsModifiable => PRO_B_TRUE, changed: read-only inactive, (still checked-in)

My findings:
- ProMdlHasNoConflict(pMdl, PRO_B_TRUE, &bNoConflict) does what is configured by dm_checkout_on_the_fly (default: checkout). (Sidenote: under a special condition, after removing checked-out object etc., it fails with XToolkitGeneralError, and on next try succeeds.)
- Neither ProMdlHasNoConflict() nor ProMdlIsModifiable() can be used to check for the Checked-in/read-only state. I would have expected to be able to do it with ProMdlIsModifiable(pMdl, PRO_B_FALSE, &bIsModifiable), but it always returns PRO_B_TRUE (when modifyable and when read-only in terms of that "Edit" button (in the parameter dialog)).

Creo knows this read-only state and offers options to the user ("Edit" button), while TK/OTK applications can not detect this state. PTC should provide a way for this.

Additional background/workaround for C TOOLKIT: ProMdlReadonlyIgnore()
https://community.ptc.com/t5/Customization/ProMdlReadonlyIgnore-implementation/m-p/976820#M13529

Note: If I strech the scope from JLink API to C TK and C++ OTK, it's because TK/OTK is the full set of API and helps to understand Creo behavior.

Re: J-Link Model.Rename() always returns XToolkitCantModify

RPN — Sun, 22 Mar 2026 10:57:48 GMT

Good answer Hannes! @nsalaorno Don’t expect a rename in Windchill as well😵‍

The role of PTC_COMMON_NAME must be more prominent in Creo. The filename as an ID, is not acceptable for a User. There is a much better behavior of customer ID’s in Creo required. The current requirements would not acceptable for me and a no go. But this may a different discussion 😎😉

topic J-Link Model.Rename() always returns XToolkitCantModify in Customization

J-Link Model.Rename() always returns XToolkitCantModify

Re: J-Link Model.Rename() always returns XToolkitCantModify

Re: J-Link Model.Rename() always returns XToolkitCantModify

Re: J-Link Model.Rename() always returns XToolkitCantModify

Re: J-Link Model.Rename() always returns XToolkitCantModify