Robert Roessler: > PropSet::GetInt(const char *key, int defaultValue) attempts to get an > expanded string value for key and then returns an int converted from > that string... > > If the key is NOT found, then the returned value comes from the > [passed-in] defaultValue.
Yes, this is the intention. > The case that I find troubling (but actually matches what is > documented for SCI_GETPROPERTYINT) is what happens when the key IS > found, but its associated string value can not be converted to an int: > the result of atoi (which is defined by the ANSI standard to be zero > in this case) is returned, NOT the [passed-in] defaultValue. I expect people to write things that look like numbers for numeric values in properties files. If there are common uses where this breaks (empty strings?) then another check could be done. > What [I think] I would like is for GetInt to be "fixed", which I am > afraid involves a more elaborate test in GetInt: if a sting value is > found, but SString.value() returns 0, then the actual string value > would need to be examined to see if that 0 value is "real", or just > was returned because atoi could not do anything "better"; in this > case, the [passed-in] defaultValue would be returned. If you really want to do this. It does not seem to be a source of problems with SciTE. > What I EXPECT to happen is for Neil to say that this probably should > not be fixed/changed... but remember those non-zero default values > being passed to Get[Property]Int - what SHOULD be happening with those? They get used if there is no setting. You could try explaining the circumstances in which you think the current behaviour is a problem. Neil _______________________________________________ Scintilla-interest mailing list [email protected] http://mailman.lyra.org/mailman/listinfo/scintilla-interest
