Create a live.numbox in patching mode and connect it to a flonum. If you use cmd-click on that box to change its value during patching, it will output floating numbers, even with the unit style as int. Same behavior when the patch is not anymore in patching mode, or in a live device. This can be very confusing and lead to hard to track malfunctions, as it happened to me with a device that as supposed to fire clips using the API…
what you describe is indeed confusing if you are coming from Max. Data types, as well as their representation are handled differently in Max and in Live/M4L.
In Live the data types and their graphical displays are two different things. The attribute "Unit Style" in a M4L UI element does not influence the data type that is used. It just says how the data is formatted for the display. So you can have a floating point number being used inside a live.numbox but display them as integers.
The actual data type can be set with the attribute "Type". Live/M4L knows three different data type: float, int and enmum (a custom list of items).
Unlike in Max int in M4L is limited to the values 0-255 (= 1 byte).
(It would be more precise to call this data type "char" as it is in most programming languages, but i assume that would add even more confusion for non-programmers.) If you want to use integers outside this range you have to use floats and display them as int (Unit Style). If you need to be sure that only integers are send to other object connect an [int] after the live.numbox to truncate the numbers.
What happens in your case is the following: you are using data type float displayed as int. when you are in patching mode and you use cmd-click to change the value you are triggering the function in Max to change the ui-element AND a function in Live that allows you to change the value in smaller grains. This is why you see numbers with a decimal point in this case.
lot’s of text … :) hope that puts some light on it :)