Skip to main content
T
23-Emerald IV
TomU23-Emerald IV
23-Emerald IV
November 11, 2021
Question

Windchill Listener Events - Get Rename Values

  • November 11, 2021
  • 2 replies
  • 2775 views

Does anyone know of a way to retrieve the target values a user enters into the rename GUI before any of the rename events finish?  We're running into a problem where we can't see what the new filename is until after the number change is already complete.  We need to know if the filename is going to be changing, and if so what its new value will be, before we decide whether or not to let the number change proceed.  Since separate events are being fired for name, number, and filename, it seems like it's impossible (from just these events) to tell in advace what is going to be changing.  Instead of just looking at the object passed by these listeners (EPMDocument, etc.) is there some way to get all the data that was actually submitted by the user on the rename form, before any of the rename events actually finish?

 

Rename dialog:

TomU_1-1636672142378.png

 

Event listener order depending on what is being changed:

TomU_0-1636672011173.png

 

2 replies

S
21-Topaz I
STEVEG21-Topaz I
21-Topaz I
November 15, 2021

I would think getting what someone types in a field and not completing the task by not selecting the OK button is not possible.

 

I have created a report that shows a past name of a file.  Not sure if that would help though.

avillanueva
23-Emerald I
avillanueva23-Emerald I
23-Emerald I
November 15, 2021

I have a rename listener and am using a PRE_CHANGE_IDENTITY. Presumably, the target has already been changing but not stored yet. Why else would it be a pre-change event? I get an IdentityServiceEvent returned. I did not see any "pre" identity objects in the event so agree that they are not exposing that. What if you tried this? Using the internal ID of the object, look it up via a query and get the current identity. In this way, you have the modified object passed from the event and a separate database query of that same item to compare against.  

IdentityServiceEvent idEvent=(IdentityServiceEvent)event;

Object target=idEvent.getEventTarget();
logger.debug("Listen hears PRE_CHANGE_IDENTITY: ");
logger.debug(" target:"+target.toString());
if(target instanceof EPMDocumentMaster)
{
EPMDocumentMaster master = (EPMDocumentMaster)target;
EPMDocumentMasterIdentity cadDocID=(EPMDocumentMasterIdentity)idEvent.getIdentity();
logger.debug("New name:"+cadDocID.getName()+":"+cadDocID.getName().length());
String newName=cadDocID.getName();

T
23-Emerald IV
TomU23-Emerald IVAuthor
23-Emerald IV
November 15, 2021
@avillanueva wrote:

I have a rename listener and am using a PRE_CHANGE_IDENTITY. Presumably, the target has already been changing but not stored yet.

From the debugging I've done, that second statement is not accurate.  Here's what I'm seeing:

  • PRE_CHANGE_IDENTITY is called before the change takes places and does not tell you what you what the new value will be.
  • POST_CHANGE_IDENTITY is called after the change has taken place and does not tell you what the old value previously was.

Either listener can stop the change, and in the case of a POST event, roll the change back, but neither one provides both the old value and the new value together.  From what I can tell, there is no way (just using these listeners) to intelligently compare both the old and new values before letting the change proceed.

 

I turned on a bunch of other logging, and Windchill clearly know both of these values way before the listeners are fired, but from what I can tell these are not exposed to the listeners.

2021-11-12 16:30:17,062 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.request.AbstractUwgmRequestAdapter administrator - AbstractUwgmRequestAdapter.debugKeyValuePair :: Key: MULTIRENAMETABLE_NEWFILENAME_JSID Value: FN02090002_50.prt
2021-11-12 16:30:17,062 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.request.AbstractUwgmRequestAdapter administrator - AbstractUwgmRequestAdapter.debugKeyValuePair :: Key: MULTIRENAMETABLE_NEWNAME_JSID Value: null
2021-11-12 16:30:17,062 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.request.AbstractUwgmRequestAdapter administrator - AbstractUwgmRequestAdapter.debugKeyValuePair :: Key: MULTIRENAMETABLE_NEWNUMBER_JSID Value: NUM02090002_50.PRT


2021-11-12 16:30:17,155 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.cadx.multirename.RenameL01RequestAdapter administrator - RenameL01RequestAdapter.createEpmRenameInstruction :: EPM Rename Instruction: EPMDocID: OR:wt.epm.EPMDocument:532031880 New Name: null New CadName: FN02090002_50.prt New Number: NUM02090002_50.PRT New Organization: Autonumbered: false DerivedFromNumber: false Name Same As Number: false Same Base Number As: Same Base Number As Related: false


2021-11-12 16:30:17,249 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmIdentityInstructionCacheAdapter administrator - EpmIdentityInstructionCacheAdapter.validateEpmIdentityInstructions :: Created EpmIdentityInfo for document: h02090002_50.prt[wt.epm.EPMDocument:532031880](-.0) EpmIdentityInfo: number = NUM02090002_50.PRT name = null autoNumbered = false container = wt.pdmlink.PDMLinkProduct:423216551 organization = null source = null soft type = null IBAs = null MIBAs = null isNameSameAsNumber = null baseNumberObject = null newBaseNumber = null errorCause = null sameBaseNumberAsRelated = null cadName = FN02090002_50.prt deriveCadName = false usePreferences = false
2021-11-12 16:30:17,249 DEBUG [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmIdentityInstructionCacheAdapter administrator - EpmIdentityInstructionCacheAdapter.validateEpmIdentityInstructions :: Created 1 IdentityInfos
2021-11-12 16:30:17,249 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmRenameInstructionL01CacheAdapter administrator - EpmRenameInstructionL01CacheAdapter.validateInstructions :: Created 1 EpmIdentityInfos
2021-11-12 16:30:17,249 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.proesrv.cache.EpmRenameInstructionL01CacheAdapter administrator - EpmRenameInstructionL01CacheAdapter.validateInstructions :: Created EpmIdentityInfo for document from input as received from UI: h02090002_50.prt[wt.epm.EPMDocument:532031880](-.0)
IdentityInfo = EpmIdentityInfo: number = NUM02090002_50.PRT name = null autoNumbered = false container = wt.pdmlink.PDMLinkProduct:423216551 organization = null source = null soft type = null IBAs = null MIBAs = null isNameSameAsNumber = null baseNumberObject = null newBaseNumber = null errorCause = null sameBaseNumberAsRelated = null cadName = FN02090002_50.prt deriveCadName = false usePreferences = false

2021-11-12 16:30:17,655 DEBUG [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.common.identity.DefaultCADNameValidator administrator - DefaultCADNameValidator.validateCADName :: Authoring application-specific checks successful for CAD name fn02090002_50.prt
2021-11-12 16:30:17,655 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.common.identity.DefaultCADNameValidator administrator - DefaultCADNameValidator.validateCADName :: Validated new CAD name fn02090002_50.prt for master: h02090002_50.prt[wt.epm.EPMDocumentMaster:532031858]
2021-11-12 16:30:17,655 TRACE [ajp-nio-127.0.0.1-8010-exec-8] com.ptc.windchill.uwgm.common.delegate.DefaultEPMOperationDelegate administrator - DefaultEPMOperationDelegate.validateCADName :: No validation error for master: h02090002_50.prt[wt.epm.EPMDocumentMaster:532031858] New CAD Name: fn02090002_50.prt AuthApp: PROE

 

Both the old and the new values are listed above, before the listeners are ever fired off.  Sure seems like we should be able to hook into *something* here…

Terms & ConditionsCookie settingsAccessibility statement