Property Definitions Numbers Cannot Handle 64 bit

Thu 28. May 2015, 00:30

I'm defining a bunch of Property Definitions for numbers to make code generation easier (c++ from XML). I was hoping to simply place a definition in there for each c++ type, but I found you cannot restrict the min / max range for a number within a 64 bit number space. I guess they can only take 32 bit numbers?

64 bit numbers are pretty common for database keys and other places needing database storage. It would be nice to be able to set the range to that...though for now, the workaround is simple to let it be limited to 32 bit ranges. I can at least still make a definition with a unique name, for churning our c++ / SQL code from.

EDIT: I'd like to add one more thing to this request / observation. If I define a property definition number and then use that in a feature, I cannot change the unit / decimal places / etc. To aid someone like me who is looking for ways to generate their code from the Articy XML doc, can you add a tag or some way to say "this is an int32 / float / double? I just need some way of taking a number and making sure the code I generate from it is the correct c++ / SQL data type.
ivanhawkes
 
Posts: 6
Joined: Mon 18. May 2015, 22:13

Re: Property Definitions Numbers Cannot Handle 64 bit

Thu 11. Jun 2015, 13:17

Hi Ivan,

articy:draft internally uses a double for storing numbers, so a change of the numbers parameters does not really change the type.

This leads to the problem that not the full 64 Bit range of a long could be used because the floating point representation will not be able to exactly represent numbers with more than its 52 mantissa bits.

Depending on your use case you should use the IDs of the articy objects. They are 64 bit ulongs.

I can understand the desire to have more restrictive data-type tagging when using the developer's view. Designers most times don't or don't like to bother with that.
If you start from the XML using float/double is a purely developer decision because the number value string needs to be parsed.
Für integer types, I recommend you to create number property definition with min/max values that fit byte / int or their unsigned variants and set the precision to 0.
Those definition can also be found in the XML and can be used as side information then reading such a value.

I checked your observation regarding parameters of property definitions. I only can confirm that the decimal places and unit are locked. Where the decimal places makes sense to me. Units not.
For the min/max values we should check if the overridden values further restrict the range, but should report widening as error, because the creator of the definition had something in mind to introduce a limit.

I will that file as improvement issue for the devs.

-Peter
User avatar
[Articy] Peter Sabath
Articy Staff
Articy Staff
 
Posts: 89
Joined: Wed 23. Nov 2011, 13:58
Location: Bochum

Return to Technical Discussion

Who is online

Users browsing this forum: No registered users and 10 guests

Who We Are
Contact Us
Social Links