[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

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.
> Views?
> Alex