parsing DateTime to user data property value

[ulski1]

Hi guys,

I had some issues yesterday where I could not understand why one of my plugins failed. I found out that parsing a DateTime with year 1899 causes a exception.

My question is :  Is there is a lower limits at year 1900? If there is I recommend that you add this limitation to the documentation for the API.

ComApi.InwOpState10 state;
state = ComApiBridge.ComApiBridge.State;
//InwOaPath ToInwOaPath(ModelItem modelItem);
ComApi.InwOaPath3 oPath = (ComApi.InwOaPath3)ComApiBridge.ComApiBridge.ToInwOaPath(MI);
// get properties collection of the path
ComApi.InwGUIPropertyNode2 propn = (ComApi.InwGUIPropertyNode2)state.GetGUIPropertyNode(oPath, true);
// create new property category (new tab in the properties dialog)
ComApi.InwOaPropertyVec newPvec = (ComApi.InwOaPropertyVec)state.ObjectFactory(ComApi.nwEObjectType.eObjectType_nwOaPropertyVec, null, null);

//CurrentValue is a DateTime with year 1899 - DateTime.TryParse handles this fine but the code crashses when the DateTime is handled over to Navisworks - this code works for all dates >1899

if (CurrentValue.GetType() == typeof(DateTime))
{
DateTime MyDate;
if (DateTime.TryParse(CurrentValue.ToString(), out MyDate))
{
MyProp.value = MyDate;
}
newPvec.Properties().Add(MyProp);

// add the new property category to the path
propn.SetUserDefined(ndx, MyPropertyTabName, MyPropertyTab_InteralName, newPvec);

Ulrik

[Aaron.Lu]

Dear, 

May I know which line of code throws which kind of exception?

or did you try the raw code regardless of Navisworks? 

I tried, seems it works. see below;

 > DateTime.Parse("1900-01-01")
1900/1/1 0:00:00
 > DateTime.Parse("1800-01-01")
1800/1/1 0:00:00
 > DateTime dd;
 > DateTime.TryParse("1800-01-01", out dd)
True
 > dd
1800/1/1 0:00:00
 > DateTime.TryParse("1899-01-01", out dd)
True
 > 

[ulski1]

hi,

Sorry, I think you perhaps did not quite understand what I'm trying to do here. 

The Microsoft DateTime Try parser works fine - and why would I complain to a Navisworks api forum about a bug in a Microsoft method anyway?

My problem can be reproduced this way:

Create a Navisworks User data object 

Set the Navisworks user data value to a Microsoft DateTime object with year 1899.

Something like this(might not compile):

using ComApi = Autodesk.Navisworks.Api.Interop.ComApi;
using ComApiBridge = Autodesk.Navisworks.Api.ComApi;
ComApi.InwOpState10 state;
state = ComApiBridge.ComApiBridge.State;
ComApi.InwOaPropertyVec newPvec = (ComApi.InwOaPropertyVec)state.ObjectFactory(ComApi.nwEObjectType.eObjectType_nwOaPropertyVec, null, null);//perhaps I should have used "as operator" here?
ComApi.InwOaProperty MyProp = (ComApi.InwOaProperty)state.ObjectFactory(ComApi.nwEObjectType.eObjectType_nwOaProperty, null, null); //perhaps I should have used "as operator" here too?
MyProp.name = "Test";
MyProp.UserName = "Test";
MyProp.value = new DateTime(1899, 12, 30, 00, 00, 00);
newPvec.Properties().Add(MyProp);
propn.SetUserDefined(ndx, "Testtab", "Testtab", newPvec);

Also maybe I need to use the "as operator" instead of direct casting of a DateTime to a user data value.

something like this 

MyProp.value = new DateTime(1899, 12, 30, 00, 00, 00) as ComApi.InwOaProperty;

The odd thing is that I do not get an error when setting the value to a DateTime object with year newer than 1899

This will work:

MyProp.value = new DateTime(1900, 12, 30, 00, 00, 00);

Ulrik

[ulski1]

a small update:

I found that for some reason the parse to a userdata value also fail if parsing a DateTime object with year 1970 month 1 day 1

[Aaron.Lu]

" as ComApi.InwOaProperty" will report compile error.

My test result is: when the date is after "1980/1/1 0:00:00", it is ok.

[Aaron.Lu]

May I suggest another workaround: store the time with int, like this:

(DateTime.UtcNow - new DateTime(1970, 1, 1)).TotalSeconds

it will calculate an integer, after setting property value, in the future, you can get the int value and create a new DateTime from it.

[ulski1]

the hole point of parsing the date as proper date is to allow the end user to use the find items search feature in Navisworks (search for dates older than etc.). Presenting the end user with an integer is not useful - then I could just a well have cast it as sting and presented that to the user.

My guess is that the comapi internally try to create the older Date object instead of a DateTime. 

On MSDN there is an advise from Microsoft that states: (see https://msdn.microsoft.com/en-us/library/3eaydw6e.aspx)

Interop Considerations. If you are interfacing with components not written for the .NET Framework, for example Automation or COM objects, keep in mind that date/time types in other environments are not compatible with the Visual Basic Date type. If you are passing a date/time argument to such a component, declare it as Double instead of Date in your new Visual Basic code, and use the conversion methods DateTime.FromOADate and DateTime.ToOADate.

so perhaps using form to OADate would allow us to parse a DateTime to the comapi user data value?

[Aaron.Lu]

do you mean changing Navisworks to use OADate or in the plugin?
if in the plugin, the "search" feature is impossible either?

what about storing strings to properties? I think you must considered it before. but not sure why you did not use it.

[ulski1]

if I cast a DateTime to string the end user will not be able to do searches using "find items" where he specifies "MyDate">date