Inheriting FilterNumericEquals and overriding FilterNumericEquals.Evaluate

Inheriting FilterNumericEquals and overriding FilterNumericEquals.Evaluate

RPTHOMAS108
Mentor Mentor
364 Views
2 Replies
Message 1 of 3

Inheriting FilterNumericEquals and overriding FilterNumericEquals.Evaluate

RPTHOMAS108
Mentor
Mentor

Hello @jeremy_tammik 

 

Sorry it's a long post but my main questions are numbered at the end.

 

I was looking at the FilterNumericEquals class and found that unlike other API objects it has a public constructor meaning it can be inherited. Then I look at the Evaluate(Double, Double, Double) method and it has the following note in RevitAPI.chm

 

"Derived classes override this method to implement the test that determines whether the two given double-precision values satisfy the desired condition or not."

 

I thought that sounds good because within that method of a derived class I can then convert the doubles to display units and compare them by that. The significance of this is that the epsilon is related to an internal units comparison. So if I wanted to find all lengths of 1000mm within a tolerance of 0.5mm I couldn't easily control that externally. Mathematically I may be able to relate it to that but it seems an obtuse way of going about it. i.e.

0.5/304.8 = 0.00164042

 

What I find with the FilterNumericEquals is that although you can inherit it the method Evaluate(Double, Double, Double) is not marked overridable. I also tried overloading it and shadowing/hiding it but the derived method is never called.

 

Then I looked at the class FilterDoubleRule, the constructor takes a FilterNumericEquals and there are the methods FilterDoubleRule.GetEvaluator and FilterDoubleRule.SetEvaluator. However no matter what derived class of FilterNumericEquals you feed into the constructor or with the SetEvaluator the GetEvaluator method always returns the base class FilterNumericEquals (confirming the derived class is never used).


FilterDoubleRule can also be inherited and FilterDoubleRule.ElementPasses is marked with the same note about being overridden in derived classes. Again however the method is not marked overridable.

 

So the questions I have are mainly as follows:

  1. Was it intended for FilterNumericEquals class to be inherited and modified?
  2. If not why couldn't FilterNumericEquals and similar classes have been enum values?  i.e. all we seem able to do with them is create a new instance to feed into FilterDoubleRule etc.?
  3. Would like some clarity on the notes about 'Overriding' the Evaluate and ElementPasses methods i.e. why is this wording within the RevitAPI.chm used if not intended for the developer?

With respect of the original problem I decided to compare double with display units between FilterNumericGreaterOrEqual and FilterNumericLessOrEqual filter rules. I still wonder what to do with the epsilon value of these rules for when the value becomes equal to either the lower or upper bounds.

 

I should also note that I was investigating these objects with respect to ElementParameterFilter does inheritance of these objects work with ParameterFilterElement (I didn't do any testing with that aspect)?

 

I found the same issue noted here:

https://spiderinnet.typepad.com/blog/2011/07/elementparameterfilter-custom-filterstringruleevaluator... 

 

365 Views
2 Replies
Replies (2)
Message 2 of 3

jeremy_tammik
Alumni
Alumni

Thank you very much for these interesting observations and your careful documentation.

 

It sounds as if this has not been properly thought through or completely executed.

 

I think the aspects you and spiderinnet noted are worthy of correction, either way, so I'll go ahead and raise a development ticket to have them addressed right away with no further prior discussion or clarification about the original intent.

 

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

RPTHOMAS108
Mentor
Mentor

Thanks Jeremy.

 

It looked like it could be quite a powerful tool for creating custom evaluators, so was slightly disappointing. The inclusion of SetEvaluator also seems odd i.e. for it not to have been hidden at some higher class level.

0 Likes