Neil Hodgson wrote:
Robert Roessler:
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.
...
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.
You are correct in that it is something of a non-issue... what started
this was, as I said, correcting the doc for the SCI_GETPROPERTY* calls
to reflect the use of the passed in default for SCI_GETPROPERTY_INT
(note that it is currently implemented to pass the supplied lParam
along to PropSet::GetInt).
I was testing the behavior, and realized that once I had set a
key/value pair, there did not seem to be a way to "un-set" it... so I
set a bogus (non-numeric value) for the same key to force the default
to be used - and found that it was NOT being used.
Then I looked at adjusting the doc to explain how things *really*
work, decided it was too ugly, and dumped it on you... err, put it up
for the group to consider. :)
I suppose that, since an EMPTY string works the same as NO string
(because of the way PropSet::GetInt is coded), the current behavior is
adequate, and I will go ahead and update the doc... done - it is
revision 1.148 of ScintillaDoc.html.
Robert Roessler
[EMAIL PROTECTED]
http://www.rftp.com
_______________________________________________
Scintilla-interest mailing list
[email protected]
http://mailman.lyra.org/mailman/listinfo/scintilla-interest