Andrea,
In general terms, it is the case that RecallPanelState / SavePanelState is intended to save control values and not control properties. However, when it comes to the specifics of each control there are some examples to this. The exceptions generally fall into two broad categories:
1. Some properties are too tied to the actual value of the control to be separated. The example you gave fits into this category. The value of the numeric is tied to the data type (which is a property) and to the max-min range (also properties) so they are saved along with the value. But something more trivial, like the font or the color, is completely separate of the value, so it is not saved. Another example is with graphs, where the plots (which are basically the 'values' of a graph) are saved, but the range of the axes are also saved, since they are closely related to the plots (especially in autoscale mode).
2. The distinction between values and properties, which made sense for simple controls like strings and numerics, begins to lose some of its meaning as later controls became more complex (trees, tabs, canvases, etc..). So in those cases, it also became difficult to establish a strong separation, when it came to deciding what would be save with SavePanelState. Our general philosophy came to be that when there was some doubt, we made the choice to save something rather than not saving it, since we assumed that that would provide users with the most flexibility.
I realize that this has become cumbersome for you, and I apologize for the inconvenience. Basically, it does mean that you have to programmatically override the properties that you did not want to change, by doing something like this:
GetCtrlAttribute (panel, control, ATTR_MIN_VALUE, &min);
RecallPanelState (panel, file, index);
SetCtrlAttribute (panel, control, ATTR_MIN_VALUE, min);
Luis
NI