Community
Inventor Programming - iLogic, Macros, AddIns & Apprentice
Inventor iLogic, Macros, AddIns & Apprentice Forum. Share your knowledge, ask questions, and explore popular Inventor topics related to programming, creating add-ins, macros, working with the API or creating iLogic tools.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Inventor API BUG in Double.parse for Microsoft dynamics Ax 2009 Bom generator

10 REPLIES 10
Reply
Message 1 of 11
Anonymous
1092 Views, 10 Replies

Inventor API BUG in Double.parse for Microsoft dynamics Ax 2009 Bom generator

Help please fix this bug the inventor API 2012

 

I createt a Bom generator for Microsoft dynamics Ax 2009 that runs from a form inside Inventor.

It Exports all BOM info from inventor into Microsoft dynamics, and recreates the bom inside Microsoft dynamics.

The only problem is that when the Bomlinenumber and BomQty is bigger than 10 this data is passed wrong from the inventor API, and the result inside Dynamics is 1? I found Out that when i set the local computer language settings

 

NumberDecimalSeparator = "." and the NumberGroupSeparator = "," then inventor Passes the data right?

 

We use standard DK settings and changing these settings is not an option for us.

 

I test that this a BUG in the Inventor API, I createt the same program to run outside inventor as an Windows form application with the exact same code and here all runs fine. without having to mess around with the local language settings.

 

Below is the code that does not work running inside inventor / but works from outside i an external application?

 

AxRecordBom.Field("LineNum") = Double.Parse(DgviewLineNumCellData)

AxRecordBom.Field("BOMQty") = Double.Parse(DgviewBOMQtyCellData)

 

Help to solve this Please!

 

Regards Kent Boettger.

 

10 REPLIES 10
Message 2 of 11
jan.liska
in reply to: Anonymous

If the issue is related to decimal separator/regional settings you may consider using another version of Double.Parse method:

 

public static double Parse(string s, IFormatProvider provider)
  

 

This version allows you to specify which locale is used for conversion.

 

Note that Inventor API also provides methods to convert strings/expressions - look at UnitsOfMeasure object.



Jan Liska
Solution Architect
Autodesk, Inc.
Message 3 of 11
Anonymous
in reply to: Anonymous

Can you please come up with a working Example on how this works, With the iformat provider.

I tried this code but it does not work? maybe i do this wrong?

 

AxRecordBom.Field("BOMQty") = Double.Parse(DgviewBOMQtyCellData, GetCultureInfo("da-DK").NumberFormat)


The UnitsOfMeasure objets is not relevant In this case because when I create the bom in Microsoft dynamics the BomQTy an LineNumber is actually extracted from an XLM files that holds all this info.

All works when the code is run outside inventor but not when it is executed from inside inventor?

 

And outside inventor i don't have to mees around with this iformat provider thing? why is this the case inside Inventor?

 

Regards.

Kent Boettger

Message 4 of 11
jan.liska
in reply to: Anonymous

You can use something like this:

 

CultureInfo culture = new CultureInfo("da-DK");

double result = Double.Parse(someTextValue, culture);

 

In your example, where do you get value of DgviewBOMQtyCellData?



Jan Liska
Solution Architect
Autodesk, Inc.
Message 5 of 11
Anonymous
in reply to: jan.liska

Hey i tried this, But no matter what i set the culture to, inventor does not do it right?

 

Any suggestions?

 

Dim USculture AsNew System.Globalization.CultureInfo("en-US")

                       

Dim DKculture AsNew System.Globalization.CultureInfo("da-DK")

                       

Dim result As Double = Double.Parse(DgviewBOMQtyCellData, USculture)

 

AxRecordBom.Field("BOMQty") = result

Message 6 of 11
jan.liska
in reply to: Anonymous

Double.Parse is method of .NET framework, it isn't part of Inventor API. However if your code is executed inside Inventor  it could be affected by Inventor process.

 

In your case what's value of DgviewBOMQtyCellData? Where do you get this value from?



Jan Liska
Solution Architect
Autodesk, Inc.
Message 7 of 11
Anonymous
in reply to: Anonymous

The number is read out from an Xml file. and all works fine inside inventor as long as the number isn't bigger that "9" else inventor fails to pass the number?

 

example:

BomQty = 1 all works fine inside inventor

BomQty = 2 all works fine inside inventor

BomQty = 3 all works fine inside inventor

BomQty = 4 all works fine inside inventor

BomQty = 5 all works fine inside inventor

BomQty = 6 all works fine inside inventor

BomQty = 7 all works fine inside inventor

BomQty = 8 all works fine inside inventor

BomQty = 9 all works fine inside inventor

BomQty = 10 or bigger all fails inside inventor

 

inventor somehow messes up the Double 😞

 

Message 8 of 11
jan.liska
in reply to: Anonymous

I'm afraid that this is not an Inventor API issue as you're not using Inventor API in your example.

 

I suggest to check following:

- How do you create a XML file? Are you using Inventor API for this?

- How the value looks in XML? Is it correct or not?

- When converting values from XML to .NET objects - how it's done? Do you use .NET serialization?



Jan Liska
Solution Architect
Autodesk, Inc.
Message 9 of 11
Anonymous
in reply to: jan.liska

I’m sure some thing is not right in the inventor API, because as I explained earlier, I created a form program outside inventor that runs the code perfect?  But when I run the code from an inventor addin the code fail on the double.parse issue? And it does not matter how the XML is created because outside inventor the code works, and off cause the value in the xml file is correct. Before the data values are read into Axapta the they are first organized inside a datagridview, but this is the same procedure in the Addin and the external windows application I created, to do some further test I created and *.Exe application that exports the data called from inside Inventor, and here all works fine. THIS IS A BUG IN THE INVENTOR API. I will send the code to ADN to solve this.

Message 10 of 11
adam.nagy
in reply to: Anonymous

Hi Kent,

 

Just an FYI: I think Jan is correct. This is not an Inventor API issue, perhaps Inventor issue.

If you are not calling Inventor API functions, then the problem is not related to that.

 

Many applications like Inventor override the CultureUICulture info in order to make sure that automatically the correct resources are loaded: in case of the English version of Inventor English resources are loaded, in case of Italian, Italian resources are loaded, etc., no matter what the Locale setting is on the system.

 

Some info about what AutoCAD is doing: http://adndevblog.typepad.com/autocad/2012/06/autocad-keeps-overriding-currentculture-and-currentuic... 
Inventor seems to only modify the CurrentUICulture info, so I assume that's the only difference between running your code inside an Inventor AddIn and in a separate application.

 

One thing missing from your side is telling what the type of DgviewBOMQtyCellData is - Jan asked about that already twice. 😉

I guess it's not a string because converting string "10" to double 10 should be no problem whichever CultureInfo you are using. So I think that under the hood the ToString function of DgviewBOMQtyCellData is called and that is affected by the CurrentUICulture info. Maybe you could temporarily override that to whatever CultureInfo that object expects - as shown in the above mentioned article.

 

I hope this helps.

 

Cheers, 



Adam Nagy
Autodesk Platform Services
Message 11 of 11
Anonymous
in reply to: adam.nagy

For your infomation, This is a Inventor 2012 API BUG, i have tried the same code inside Inventor 2014 and here it all works fine. But in Inventor 2012 it fails to pass a decimal number to Axapta ERP system.

 

Regards Kent Boettger

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report