Load Case Param change does not trigger IUpdater

Load Case Param change does not trigger IUpdater

sroswurm4GJQU
Advocate Advocate
1,278 Views
9 Replies
Message 1 of 10

Load Case Param change does not trigger IUpdater

sroswurm4GJQU
Advocate
Advocate

Morning All,

 

I've worked my way through the forum enough to observe that a lot of development bug fix tickets come from these specific IUpdater issues, so I thought I would throw mine out here.  Someone posted here with an identical issue back in 2015, but there was no solution found at that time.

 

I need to be able to watch the parameters of a load (both line loads and point loads) and trigger an IUpdater Execute() when the parameters are changed.  The implementation is really quite simple and works beautifully for all instance parameters EXCEPT "Load Case" and "Is Reaction".

 

Changes to these two parameters do not trigger under any conditions I've been able to think of.  Even the old tried-and-true solution of GetChangeTypeAny() does not trigger.

 

For convenience, I've included my reproducible test case right here.  The actual updater is painfully simple:

public class LoadChangedUpdater : IUpdater
        {
            static AddInId m_appId;
            static UpdaterId m_updaterId;
            static UIControlledApplication application;

            public LoadChangedUpdater(AddInId id, UIControlledApplication myApplication)
            {
                m_appId = id;
                application = myApplication;
                m_updaterId = new UpdaterId(m_appId, new Guid("4b0dda0f-1448-4bee-a6ca-519112d25d26"));
            }

            public void Execute(UpdaterData data)
            {
                //Simple pop-up if change is detected
                MessageBox.Show("A load parameter change was detected!");
            }

            public string GetAdditionalInformation()
            {
                return "Load change: Generate a MessageBox if a load parameter is changed";
            }

            public ChangePriority GetChangePriority()
            {
                //I'm not 100% sure which ChangePriority is most appropriate here
                return ChangePriority.FloorsRoofsStructuralWalls;
            }

            public UpdaterId GetUpdaterId()
            {
                return m_updaterId;
            }

            public string GetUpdaterName()
            {
                return "Load Change Updater";
            }
        }

 

The registry and trigger creation is handled in the OnStartup method for the application.  Here is the registry and trigger which executes successfully for all EXCEPT the two I mentioned above.  The filter captures only loads and the triggers use GetChangeTypeParameter()

 

  //Build filters
            ElementCategoryFilter myLineLoadFilter 
                = new ElementCategoryFilter(BuiltInCategory.OST_LineLoads);
            ElementCategoryFilter myPointLoadFilter 
                = new ElementCategoryFilter(BuiltInCategory.OST_PointLoads);
            LogicalOrFilter combinedLoadFilter 
                = new LogicalOrFilter(myLineLoadFilter, myPointLoadFilter);

            //Register the updater
            LoadChangedUpdater myLoadChangedUpdater 
                = new LoadChangedUpdater(application.ActiveAddInId, application);
            UpdaterRegistry.RegisterUpdater(myLoadChangedUpdater);

            //Iterate over all values in BuiltInParameter enum and add a trigger for each
            foreach (BuiltInParameter myParam in BuiltInParameter.GetValues(typeof(BuiltInParameter)))
            {
                ElementId paramID = new ElementId(myParam);

                UpdaterRegistry.AddTrigger(myLoadChangedUpdater.GetUpdaterId(), 
                                           combinedLoadFilter, 
                                           Element.GetChangeTypeParameter(paramID));
            }

 

Now in the 2015 forum discussion on this topic, Arnost Lobel recommended testing with a fully generalized approach where the filter is set to capture all possible elements and the trigger uses GetChangeTypeAny().  Unfortunately, his example using an ExclusionFilter with an empty List<ElementId> throws an "ArgumentException".  My alternative to this is simply to build a LogicalOrFilter to include all contents of the BuiltInCategory enum, which should essentially capture all possible elements.  Coupling this with GetChangeTypeAny() produces identical behavior to the other test case.  It successfully raises the updater Execute() method for all load parameters except "Load Case" and "Is Reaction".  Here is that code sample:

 

// Register the updater
            LoadChangedUpdater myLoadChangedUpdater
                = new LoadChangedUpdater(application.ActiveAddInId, application);
            UpdaterRegistry.RegisterUpdater(myLoadChangedUpdater);

            //Declare filter list
            IList<ElementFilter> allBuiltInCatsFilters = new List<ElementFilter>();

            //Iterate over all values in BuiltInCategory enum and create a filter for each
            foreach (BuiltInCategory myCat in BuiltInCategory.GetValues(typeof(BuiltInCategory)))
            {
                try
                {
                    ElementCategoryFilter myFilter = new ElementCategoryFilter(myCat);
                    allBuiltInCatsFilters.Add(myFilter);
                }
                catch
                {
                }
            }

            LogicalOrFilter combinedCatsFilter = new LogicalOrFilter(allBuiltInCatsFilters);

            UpdaterRegistry.AddTrigger(myLoadChangedUpdater.GetUpdaterId(),
                                       combinedCatsFilter,
                                       Element.GetChangeTypeAny());

 

I'm all ears if someone has already conquered this issue.  Or I'm perfectly happy to help with whatever info is needed for a bug fix reproducible test case if needed.

 

0 Likes
Accepted solutions (3)
1,279 Views
9 Replies
Replies (9)
Message 2 of 10

jeremytammik
Autodesk
Autodesk

Thank you very much for reporting this and for your deep research and careful analysis.

 

Please submit a complete minimal reproducible case for the development team to analyse:

 

https://thebuildingcoder.typepad.com/blog/about-the-author.html#2

 

You seem to have everything required in place already for that.

 

Please make it as foolproof as possible, so that no possible doubt remains.

 

Maybe, in their analysis, they will point out something we missed. Maybe there is some underlying issue that needs to be addressed.

 

Thank you!

 



Jeremy Tammik
Developer Technical Services
Autodesk Developer Network, ADN Open
The Building Coder

0 Likes
Message 3 of 10

sroswurm4GJQU
Advocate
Advocate

Jeremy,

 

Thanks for your response.  The attached Revit file and the macro it contains are a reproducible test case to demonstrate that IUpdater does not trigger when specific load parameters are changed.  Here are the steps to reproduce the issue:


1.)  Open the Revit 2020 file IUpdater_Test_Project.rvt
2.)  If desired, open the Macro Manager and run the "RegisterUpdater" method to verify that Updater is registered
3.)  After registering, attempt to change any instance parameter of the loads modeled in the Revit file
4.)  Changing "Load Case" or "Is Reaction" causes no result
5.)  Changing any other parameter causes the IUpdater Execute() method to show a MessageBox
6.)  To observe the same behavior with the more general updater triggers, reverse the commenting as indicated in the RegisterUpdater() method 

 

Thanks again for you help, and please let me know if you need anything further from me.  I'll look forward to hearing more about this from the development team.

0 Likes
Message 4 of 10

RPTHOMAS108
Mentor
Mentor

It is interesting to note that the category of load changes according to the value of 'Is Reaction' e.g.

 

For point loads

OST_InternalPointLoads (Is Reaction = True)
OST_PointLoads (Is Reaction = False)

 

Parent of both is OST_Loads

 

I don't see anything interesting about 'Load Case' however...

0 Likes
Message 5 of 10

sroswurm4GJQU
Advocate
Advocate

I just wanted to follow up and see if there were any findings on this topic from the development team.  The IUpdater works great for all of the other load parameters, but I expect to eventually receive user complaints that we are unable to produce a warning and accompanying data updates when the load case is toggled.  Thanks!

0 Likes
Message 6 of 10

jeremy_tammik
Alumni
Alumni

Dear Seth,

 

Thank you for your reproducible case and patience with this.

 

Sorry for the delay in responding.

 

I logged the issue REVIT-177344 [Load Case parameter does not trigger IUpdater] with our development team for this on your behalf as it requires further exploration and possibly a modification to our software. Please make a note of this number for future reference.

 

You are welcome to request an update on the status of this issue or to provide additional information on it at any time quoting this change request number.

 

This issue is important to me. What can I do to help?

 

This issue needs to be assessed by our engineering team and prioritised against all other outstanding change requests. Any information that you can provide to influence this assessment will help. Please provide the following where possible:

 

  • Impact on your application and/or your development.
  • The number of users affected.
  • The potential revenue impact to you.
  • The potential revenue impact to Autodesk.
  • Realistic timescale over which a fix would help you.
  • In the case of a request for a new feature or a feature enhancement, please also provide detailed Use cases for the workflows that this change would address.

 

This information is extremely important. Our engineering team have limited resources, and so must focus their efforts on the highest impact items. We do understand that this will cause you delays and affect your development planning, and we appreciate your cooperation and patience.

 

Best regards,

 

Jeremy

 

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 7 of 10

jeremy_tammik
Alumni
Alumni
Accepted solution

Dear Seth,

 

Thank you for pointing this out and your patience with this.

 

The development team analysed and verified the issue REVIT-177344 [Load Case parameter does not trigger IUpdater] that I submitted for you.

 

They closed that and opened a new code fix issue REVIT-177734 [Load Case parameter does not trigger IUpdater] to rectify the behaviour in a future version of Revit.

 

Please make a note of this number for future reference.

 

Best regards,

 

Jeremy

 

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 8 of 10

sroswurm4GJQU
Advocate
Advocate

Jeremy,

 

That's great news!  Thank you so much for your efforts in pursuing this issue and for your updates along the way!

I'll look forward to taking advantage of this fix in the future.

 

Thanks,
Seth

0 Likes
Message 9 of 10

jeremy_tammik
Alumni
Alumni
Accepted solution

Dear Seth,

  

Good news: the development team resolved issue REVIT-177734 [Load Case parameter does not trigger IUpdater] to rectify the behaviour in a future version of Revit. It is now completed, with the comment, Improved the updater to report Structural Loads "Load Case" and "Is Reaction" parameter changes.

  

Best regards,

 

Jeremy

  

Jeremy Tammik Developer Advocacy and Support + The Building Coder + Autodesk Developer Network + ADN Open
0 Likes
Message 10 of 10

sroswurm4GJQU
Advocate
Advocate
Accepted solution

Jeremy,

 

Thanks so much for the update!  That is great to hear!

I always appreciate how much effort you put out to advocate for the Revit API dev community and help address issues like this.

 

Seth

0 Likes