[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]
RE: [XaraXtreme-dev] Re: [XaraXtreme-commits] Commit Complete
- From: "Phil Martin" <Phil@xxxxxxxx>
- Date: Wed, 19 Jul 2006 10:19:41 +0100
- Subject: RE: [XaraXtreme-dev] Re: [XaraXtreme-commits] Commit Complete
I agree that it looks like a bug worth fixing if we can identify and fix
any places that relied on the previous behaviour.
> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Alex Bligh
> Sent: 19 July 2006 10:09
> To: dev@xxxxxxxxxxxxxx
> Cc: Alex Bligh
> Subject: Re: [XaraXtreme-dev] Re: [XaraXtreme-commits] Commit Complete
> > Did you do this for a reason? I certainly have written code that is
> > reliant on the string being empty after the call to this
> function (and
> > there is lots more that is also reliant on this fact). My code will
> > still work because the string is always empty before I make
> the call,
> > but I don't know for certain about of instances.
> This is so DeclarePref when passed a string leaves the static
> default value alone if the preference is not present (rather
> than NULL'ing it).
> I thought it was a winoil=>wxOil conversion bug, but it seems
> winoil does the same thing.
> The reason for changing it is because otherwise you can't use
> a static default string, like you can use a static default
> integer, which is both irritating and inconsistent. It looks
> like a bug, but sadly one on whose behaviour people might rely.
> If it's likely to break stuff, I can change it back. The case
> where it would break things is where a non NULL string is
> used as a default (as if the string is NULL, writing a NULL
> on top of it makes no difference), the preference is absent,
> and the result of it being NULL'd is something other than
> replacing the non-NULL default.