Class FilterStringRule Parameter 'caseSensitive' has no effect on the result.

[Anonymous]

I'm searching an element with a unique IfcGuid Parameter and use the FilterStringRule.
The document contains two elements with a unique IfcGuid Parameter
Element 1 - "1R2bdPeeDBqOt5BWx5fq_k"
Element 2 - "1R2bdPeeDBqOt5BWx5fq_K"
The difference is only the last sign (k|K).

The parameter 'caseSentive' is passed true or false. The result is always two elements found.

GetElementId("1R2bdPeeDBqOt5BWx5fq_k")
or
GetElementId("1R2bdPeeDBqOt5BWx5fq_K")

public ElementId GetElementId(string ifcGuid)
{
var document = m_UIApplication?.ActiveUIDocument?.Document;
if (document == null)
return null;

var buildInParameter = BuiltInParameter.IFC_GUID;
ParameterValueProvider parameterValueProvider = new ParameterValueProvider(new ElementId((int)buildInParameter));
FilterStringRuleEvaluator filterStringRuleEvaluator = new FilterStringEquals();

FilterStringRule filterStringRule = new FilterStringRule(parameterValueProvider, filterStringRuleEvaluator, ifcGuid, true);
ElementParameterFilter elementParameterFilter = new ElementParameterFilter(filterStringRule);

FilteredElementCollector filteredElementCollector = new FilteredElementCollector(document);
var elements = filteredElementCollector.OfClass(typeof(SpatialElement)).WherePasses(elementParameterFilter).ToElements();
if (elements.Any())
{
if (elements.Count > 1)
{
// BUG = ? - Workaround
// 2nd filter the result
return elements.First(item => item.get_Parameter(buildInParameter).AsString().Equals(ifcGuid, StringComparison.Ordinal)).Id;
}
else
{
return elements.First().Id;
}
}
return null;
}

[jeremytammik]

Thank you for this interesting observation.

Could you please provide a minimal reproducible case that demonstrates this and that can be shared with the Revit development team for further analysis?

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

Thank you!

[Anonymous]

Please have a look at the attached minimal FilterStringRule Project.

RevitForum.Sample.Filters.zip
VS2019 Project Settings
- .NET Framework 4.7
- Start external program: C:\Program Files\Autodesk\Revit 2019\Revit.exe
- Post Build Events
copy/y "$(ProjectDir)RevitForum.Sample.Filters.addin" "$(AppData)\Autodesk\REVIT\Addins\2019"
copy/y "$(TargetDir)RevitForum.Sample.Filters.dll" "$(AppData)\Autodesk\REVIT\Addins\2019"

Revit2019
- open file RevitForumsFilterSample.rvt

   Door IfcGuid: 1R2bdPeeDBqOt5BWx5fq_k
   Room IfcGuid: 1R2bdPeeDBqOt5BWx5fq_K

- Ribbon Tab 'RevitForum'
- Command 'ShowDialogFilter'

FilterStringRule.png

Test with checked/unchecked 'CaseSensitive' option.
The filter does not react to the parameter 'CaseSensitive = true'.
Both elements are found.

Best regards,

Jo

[jeremytammik]

Thank you for your nice sample and reproducible case.

Just to make it easier for others to read, here is your dialogue box image inline:

[jeremytammik]

Dear Jo,

Thank you for your report and very nice reproducible case.

Sorry to hear about this unexpected behaviour.

I logged the issue REVIT-160988 [FilterStringRule constructor caseSensitive argument is ignored] 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

[Anonymous]

Dear Jeremy,

Thanks for the quick answers.
For our new application I use a workaround.

I filter the result again with a CaseSensitive String Comparison.

public IEnumerable<Element> GetElements(string ifcGuid)
{
    var document = m_UIApplication?.ActiveUIDocument?.Document;
    if (document == null)
        return System.Linq.Enumerable.Empty<Element>();

    var buildInParameter = BuiltInParameter.IFC_GUID;
    ParameterValueProvider parameterValueProvider =
                new ParameterValueProvider(new ElementId((int)buildInParameter));

    FilterStringRuleEvaluator filterStringRuleEvaluator = new FilterStringEquals();
    FilterStringRule filterStringRule =
                new FilterStringRule(parameterValueProvider, filterStringRuleEvaluator, ifcGuid, true);
    ElementParameterFilter elementParameterFilter = new ElementParameterFilter(filterStringRule);
    FilteredElementCollector filteredElementCollector = new FilteredElementCollector(document);
    var elements = filteredElementCollector.WherePasses(elementParameterFilter).ToElements();
    // return elements;

    // workaround
    // if the constructor FilterStringRule is called with parameter 'CaseSensitive = true'
    // I check the result a second time
    return elements
            .Where(item => item.get_Parameter(buildInParameter)
            .AsString().Equals(ifcGuid, StringComparison.Ordinal));

}

I can continue developing with the workaround and have no delay. But wrong filtering on an IfcGuid can have serious effects on an application.

Best regards,

Jo

[jeremytammik]

Thank you for your appreciation and the workaround!

The first reaction from the development team is illuminating: "So, I guess we need to make a decision whether to revive case-sensitive string comparison in filters or just remove the last remnants of it"...

[ngombault]

Looks like you went down the path of removing case sensitivity considering the CreateEqualsRule caseSensitivity argument has been made obsolete in Revit 2023.

I would have voted the other way since ifcGUID are case sensitive, as explained in Autodesk's own article:
https://knowledge.autodesk.com/support/revit/troubleshooting/caas/sfdcarticles/sfdcarticles/Are-IFC-...

[RPTHOMAS108]

Well all of this was based on the filter rules as could be constructed within the visibility filters dialogue. As far as I recall there was never a case sensitivity option there for strings in the UI.

So likely someone added the option to the API thinking it was logical

then discovered they had no internal way to implement it

then forgot about it

then was asked about it

then made it obsolete.

Probably different people.

The thing about GUIDs is it's about probability i.e. what is the probability that two randomly generated IFC guid strings will have the same characters in the same order but be of different character cases? It is probably the case like all GUIDs the IFC one is too large a capacity for what it is used for.

If they are not generated randomly then you have a problem i.e. if they are based on a count.

Int64 has a max value of 9223372036854775807 and you can double that for UInt64. Compared with how many elements in the average project.