Need entry field to be longer when pfm_range_max and/or pfm_range_min keys are defined

[apizz]

It seems there's an assumption made about the length of the field to enter values when either pfm_range_max or pfm_range_min keys are provided. As a result, this cuts off entered values that are longer than 1 character. The desired value of the preference in my case is a number between 0.25 and 8.

It might be helpful to make this field a little larger to accommodate values of 4-5 characters in length, or alternatively (a thought) add an additional key to explicitly define the max value character length. Not sure how in the case of a number you could also then define where the decimal place should go ... Perhaps this could be extrapolated somehow from the values provided in pfm_range_max and pfm_range_min?

                   <dict>
			<key>pfm_default</key>
			<real>2</real>
			<key>pfm_description</key>
			<string>The number of seconds can be increments of .25.</string>
			<key>pfm_exclude</key>
			<array>
				<dict>
					<key>pfm_target_conditions</key>
					<array>
						<dict>
							<key>pfm_present</key>
							<false/>
							<key>pfm_target</key>
							<string>dwellZoomEnabled</string>
						</dict>
						<dict>
							<key>pfm_present</key>
							<false/>
							<key>pfm_target</key>
							<string>dwellZoomEnabled</string>
						</dict>
					</array>
				</dict>
			</array>
			<key>pfm_name</key>
			<string>dwellTimeZoom</string>
			<key>pfm_range_max</key>
			<real>8</real>
			<key>pfm_range_min</key>
			<real>0.25</real>
			<key>pfm_title</key>
			<string>Dwell Zoom After</string>
			<key>pfm_type</key>
			<string>float</string>
			<key>pfm_value_unit</key>
			<string>seconds</string>
		</dict>

[apizz]

Looking at another preference, it appears that the size of this field is determined by the value of pfm_default. Another preference I was working with has a pfm_default value of 250, and the field matches the character length.

[erikberglund]

It takes the maximum value and puts that in the textfield and checks how wide that makes it, then adds 2.0 pixels and sets that width. So I can see why it does that for floating point numbers. I did not take that into account, I will look at it.

[erikberglund]

Should be fixed in the next version