Some properties display as 0 instead of their actual value when extracted

Some properties display as 0 instead of their actual value when extracted

Anonymous
Not applicable
967 Views
6 Replies
Message 1 of 7

Some properties display as 0 instead of their actual value when extracted

Anonymous
Not applicable

Hi guys,

 

I'm working on this Navisworks plugin that extracts a bunch of properties from a bunch of elements in the model and writes those properties into an SQL database.

 

Eveything seems to be working (yay!)  but some values, when extracted come out with a value of 0 (number zero) instead of their actual value. Refer to picture below for examples:

image.png

 

And this is how I'm extracting the properties' values:

        internal static string GetPropertyValue(DataProperty property)
        {
            // Instantiate value of parameter
            string value;
            // Get value depending on its type
            switch (property.Value.DataType)
            {
                case VariantDataType.None:
                    value = property.Value.ToString();
                    break;
                case VariantDataType.Double:
                    value = property.Value.ToAnyDouble().ToString();
                    break;
                case VariantDataType.Int32:
                    value = property.Value.ToInt32().ToString();
                    break;
                case VariantDataType.Boolean:
                    value = property.Value.ToBoolean().ToString();
                    break;
                case VariantDataType.DisplayString:
                    value = property.Value.ToDisplayString();
                    break;
                case VariantDataType.DateTime:
                    value = property.Value.ToDateTime().ToString();
                    break;
                case VariantDataType.DoubleLength:
                    value = property.Value.ToDoubleLength().ToString();
                    break;
                case VariantDataType.DoubleAngle:
                    value = property.Value.ToDoubleAngle().ToString();
                    break;
                case VariantDataType.NamedConstant:
                    value = property.Value.ToNamedConstant().Value.ToString();
                    break;
                case VariantDataType.IdentifierString:
                    value = property.Value.ToIdentifierString().ToString();
                    break;
                case VariantDataType.DoubleArea:
                    value = property.Value.ToDoubleArea().ToString();
                    break;
                case VariantDataType.DoubleVolume:
                    value = property.Value.ToDoubleVolume().ToString();
                    break;
                case VariantDataType.Point3D:
                    value = property.Value.ToPoint3D().ToString();
                    break;
                case VariantDataType.Point2D:
                    value = property.Value.ToPoint2D().ToString();
                    break;
                default:
                    value = property.Value.ToString();
                    break;
            }

            return value;
        }

Can anyone see why those anomalies are happening?

 

Thanks for the help!

 

Andrea

0 Likes
968 Views
6 Replies
Replies (6)
Message 2 of 7

ulski1
Collaborator
Collaborator
There are parsing bugs in Navisworks (which I have reported to Autodesk). My guess is that the values containing "#" gets parsed into some sort of unexpected csharp binary / hex value and because you haven't written a switch case for that type your "#" containing values ends up in the default case - but to be sure, I would suggest that you add a conditional breakpoint to know for sure what is happening.
Br
Ulrik
Message 3 of 7

Anonymous
Not applicable

Thanks for your reply @ulski1 !

 

I thought that by basing the switch case on the DataType of the Property, you wouldn't have to deal with any sort of parsing, no?

 

Anyway, do you have some resource to link here on how to add conditional breakpoints and actually do some normal debugging on Navisworks? I tried to have a look around but I haven't found some clear guide. (Right now I have to debug using MessageBox which is far from ideal 😄 )

 

Thanks!

0 Likes
Message 4 of 7

ulski1
Collaborator
Collaborator
Hi,
Article about conditional breakpoints and debugging
https://devblogs.microsoft.com/visualstudio/how-can-i-pause-my-code-in-visual-studio-breakpoints-faq...
https://devblogs.microsoft.com/visualstudio/7-lesser-known-hacks-for-debugging-in-visual-studio/

For debugging you can do 2 things.

1. You start navis and attach to the roamer.exe process from within the debug menu in visual studio
2. Or in your visual studio project you go to project properties and in there in the debug section you add a debug start action as "C:\Program Files\Autodesk\Navisworks Simulate 2019\roamer.exe" and if needed you can add command line arguments as well. Next you click "start in visual studio" and that should start navis with visual studio connected for debug
Br
Ulrik
0 Likes
Message 5 of 7

xiaodong_liang
Autodesk Support
Autodesk Support

Hi @Anonymous ,

 

is this issue working now? I might be missing something, while it looks the property value with #  can be extracted correctly. I simply tested with SDK sample AppInfo and Navisworks API training labs (the section Dump Properties). Both works well with the string which contains #.  AppInfo uses generic way of .NET Reflection, while training lab uses the way you are trying.

 

if you still have the problem, please share a copy of demo file with such property for diagnose. Thanks.

 

@ulski1 Thank you for helping this case. Could you remind me the problem of # ? I seemed not to find a ticket that has been logged with engineer team. 

 

Screen Shot 2019-07-21 at 11.00.42 PM.pngScreen Shot 2019-07-21 at 10.42.00 PM.png

0 Likes
Message 6 of 7

ulski1
Collaborator
Collaborator
Hi Xiaodong,
As far as I recall the parsing problems is with strings being parsed as numbers if the sting begins with numbers and later contain the letter d. I just guessed that the # could cause some similar issues and that is why I recommend creating a breakpoint to investigate what is happening. There was another parsing bug as well with dates older than a specific date.
Be
Ulrik
0 Likes
Message 7 of 7

Anonymous
Not applicable

Thank you for your reply Xiao!

 

It actually hasn't happened anymore, but I haven't changed anything in the code, so I suspect it could happen again in the future.

 

I'll keep monitoring it and in case it will happen again I'll post it here 😉

 

Thanks for the support guys!

0 Likes