This is strange - I was about to update the documentation for
SCI_GETPROPERTYINT, because it didn't quite reflect the way [I
thought] the code actually works... but in fact, the documentation
*does* match the code, because the code may be broken! :)
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.
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.
So, PropSet::GetInt MAY or may NOT be intended to work this way - that
is a call for Neil to make... BUT, I will note that there ARE some
instances of it being called with a non-zero default value (BTW, in
the Scintilla source, GetInt is typically USED by calling GetPropertyInt).
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.
THEN I could update the doc for SCI_GETPROPERTYINT to reflect the
proper usage and meaning of passing in a default value! :)
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?
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest
