UnitFormatUtils.TryParse Please enter a value less than 914400 mm

[chris]

Hello,

Has anyone every had an issue when using UnitFormatUtils.TryParse, getting a output of 0 and a message of: Please enter a value less than 914400 mm?

How do I get around this issue?

[matthew_taylor]

Hi @chris,

A lot of Revit UI parts have this 3000ft limitation, so it's just a native Revit thing - you're not doing anything wrong.

I had it just the other day in the View Filters dialog when dealing with large Length numbers.

I guess it depends what you're trying to do...as to trying to figure out a way around it.

One trick with non-Revit numbers that have upper limits is to - say - divide the number by 1000, and then re-multiply by 1000 when the limit no longer applies.

You may have to test the number for size and parse the number manually if it is too large.

Of course, you may be trying to parse the number so it can be used within Revit. To which point I would suggest you just parse a number over 914400 (to your macro) to see if your code actually works.

Cheers,

-Matt

[chris]

Hi Matt,

Thank you for your response. dividing by 1000 defeats the purpose of this method, and may not always be an option... say its 100000000mm where mm, could be cm, m, ... I want this function to return the correct answer, the only way around this is to work out what the units (as I don't know it is for a tool used all around the world) and then do a work around to convert, the reality is I will need to create my own UnitFormatUtils.TryParse due to this limit.

To say this is frustrating and another almost there but not quite from Autodesk is well... why would they put such a limit on it...

Cheers Chris

[chris]

The scenario this relates to is taking navisworks clash reports and bring the points back into Revit, although, I am now looking back at all my other tools and wondering how many of them have this issue, i.e. excel to Revit tools where the excel cell might have a suffix of its units, the good thing about this tryparse function is it deciphers all that return something Revit understands, but it this limit is a bit of a deal breaker...

[matthew_taylor]

Hi Chris,

I get what you're saying.

I've never had any issues with Excel et al with regards to units. I tend to not give the user a value with a unit suffix though. There's a title for that.

@jeremytammik normally suggests a roll-your-own approach with regards to units and conversion.

Seeing as you're getting values that don't work within Revit's limits, that would seem like the most likely approach. I mean, if tryparse fails, then use your custom function.

The Navis XML clash exports I've seen have a units field in the header. Maybe a different approach is required?

Cheers,

-Matt

[rossen.hristov]

@jeremytammik @matthew_taylor

Can you at least share the original TryParse source code, so we can use it in our projects without the 3000ft limitation.

Or create an overload of the function that will let us convert larger numbers. In this way, Revit can call the function with the limitation on and we can call it with the limitation off. I use it everywhere to convert large numbers for V-Ray for Revit and it would be great if I could successfully do it.

By the way, as a developer, I would put the 3000ft limitation OUTSIDE of the TryParse function and let the TryParse function do its job and work with the limitations of the double data type. 

[jeremytammik]

Can you provide some context, please? Where is the source string coming from? I would suggest never ever storing a length value in a string. Obviously, if it is from a user input field in a form, it comes in as a string. However, I would simply convert that to a number straight away, regardless of what units are being used. Maybe that is not possible in your context? As said, where is the source string coming from? 

Cheers,

Jeremy

[rossen.hristov]

From our V-Ray for Revit's settings window:

We use the Revit Project's Units throughout our entire UI, so that the end user has a consistent experience with the rest of the Revit UI. In this case, the user wants to enter a very large number for View Distance (because it makes sense for V-Ray for Revit) and he enters a very large amount in feet (it does not matter in what units anyway). We get this input as a string and we feed it to the TryParse method, which returns 0 because. It just does not make sense from a developer's point of view to bake-in the 3000ft limitation INSIDE the TryParse method. Let Revit limit its walls, planes, whatever to 3000ft, but this business logic should be OUTSIDE the TryParse method. TryParse should only do what it says -- PARSE and not include any business logic inside it. Just like the standard Microsoft .NET TryParse methods do. Please, forward this to the developer team. I think that they would agree. Thanks in advance.

[jeremytammik]

Sorry to hear about this.

I logged the issue REVIT-136637 [UnitFormatUtils.TryParse rejects values over 914400 mm] 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.

Cheers,

Jeremy

[rossen.hristov]

Thank you. The best option would be to provide an additional overload of the function in a future version/hotfix of Revit where the caller could specify that he does not want to be limited to 3000 ft. In this way the rest of the Revit codebase will not change a bit. Now onto the details:

• Impact on your application and/or your development: High
• The number of users affected: We don't really know
• The potential revenue impact to you: Medium
• The potential revenue impact to Autodesk: None
• Realistic timescale over which a fix would help you: Half a year
• 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: Simply add an overload of the TryParse method with an additional boolean parameter that specifies that no limitation should be imposed.

Thanks.

[jeremytammik]

Thank you! I added your suggestion and business case to the development issue.

[rossen.hristov]

Thank you!

[ana.lyubenova]

Hi Jeremy, 

Where can we track the progress of the issue? 

-Ana

[jeremytammik]

Dear Ana,

Unfortunately, you cannot track it yourself.

The issue REVIT-136637 [UnitFormatUtils.TryParse rejects values over 914400 mm] has been verified as a problem and a new development issue REVIT-137365 [UnitFormatUtils.TryParse rejects values over 914400 mm] has been created to perform the actual programming work. 

The fix is scheduled for the next major release of Revit.

Best regards,

Jeremy

[ricaun]

I didn't want to revive this post but the TryParse limitation still exists in the Length, if the value is bigger than 30000 ft or 9144 m the parse fails.

Does not make sense to me that UnitFormatUtils has this limitation, I tried others SpecTypeId and at the moment only Length has this kinda limit.

I test with SpecTypeId.Length, SpecTypeId.Number, SpecTypeId.Area and SpecTypeId.Volume. (Version 2021, 2022, 2023 and 2024)

Here is the code of the test.

https://gist.github.com/ricaun/284ac2a2cab9a58fbe3433ffebaeb24a

Edited: All the SpecTypeId based on length has this limit, SpecTypeId.Distance, SpecTypeId.ConduitSize...