Hi Angela,
You are correct in your original post that the information needs to be extracted from the eventData variable. It seems that there is usually at least a TypeId and an IdList property on this variable though it does change a bit depending on the event type.
Is there a specific use case you had in mind?
Chris
I made some progress. Thanks for the hint regarding the TypeId! I
I currently use a onAfterAdd Version 2 Method and try to add 3 Part Document relationships at once.
[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:f2b3d95b-df7c-4b58-a91f-afc4bfe0f6b1:type=csharp&text=string%20idlist%20%3D%20eventData.IdList.First%28%29%3B%0Astring%20typeId%20%3D%20eventData.TypeId%3B%0A%0A%2F%2F%20Alternate%20approach..%0AIEnumerable%20enumerable%20%3D%20eventData.IdList%3B%0Astring%20idtest%3D%20string.Join%28%22%2C%22%2C%20enumerable.Cast%3Cobject%3E%28%29.Select%28x%20%3D%3E%20x%3F.ToString%28%29%29%29%3B]
Current result: TypeId works, but I only get one item id. I checked the eventData object. It looks like it only contains the first ID of my three new 'Part Document' items.
---
My use case would be all kind of indicators and something related to ECO Affected Items.
Typically I use onAfterAdd/onAfterDelete server events to update the tab counters and an unicode "has BOM" indicator in the grid. Solution is loosely based on the PE files flag concept.
Let´s assume user import a BOM via batch loader with 429 elements. The same Method would be triggered 429 times. This is currently no problem. Systems runs smooth and fast since years.
Occasionally, I refactor legacy code to enhance long-term maintainability and stability. The current solution to update these indicators with version 1 events just feels super wrong and inefficient.
With the above code at least the BOM indicator would work with version 2 events, as I don´t need to count the elements for this use case. But without the amount of relationships it will not work for the tab indicators.
I'm right now questioning whether this approach can actually work, or if V2 events were designed for a completely different purpose.
----------
Some side notes to the use case.
Eli once helped me to get the tab indicator idea running. End users would start a riot if I remove the feature.[emoticon:0f36700dfeb3494fa10d47dd9e1f90a1] But I still rate the concept as too experimental to promote it on a larger scale.
I have a rough concept to improve the overall feature with CUI in I14. Unfortunately I still use 12SP7. For my idea I need a few of the new CUI features, especially relationship accordions.
The current solution use a combination of server methods and a Form onLoad event. I want to get rid of both to achieve the ultimate fast and efficient tab indicator solution. It´s not as revolutionary as "something with AI", but I still believe it adds value.[emoticon:44a8a53ad3364ea78a16c5a3229f75bb]
