Skip site navigation (1) Skip section navigation (2)

Re: pgAdmin III commit: Include a variant of sysSettings::Write() that take

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>
Cc: pgadmin-hackers(at)postgresql(dot)org
Subject: Re: pgAdmin III commit: Include a variant of sysSettings::Write() that take
Date: 2011-02-16 18:58:49
Message-ID: AANLkTimef6VPOnf6bruDG2vJ2pEyfeLBs5w1vyahUnDg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgadmin-hackers
On Wed, Feb 16, 2011 at 6:50 PM, Peter Geoghegan
<peter(dot)geoghegan86(at)gmail(dot)com> wrote:
> On 16 February 2011 18:42, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>> The main issue I have with that is that we now have a bunch of
>> overloaded Write() members, and WriteBool(). If we're going to deviate
>> away from the API in wxConfig (which at least is private), then we
>> should do so consistently.
>>
>> FYI, in wxPython and wxPerl they implement the following:
>>
>> Write(key, value)        Writes a string
>> WriteInt(key, value)     Writes an integer
>> WriteFloat(key, value)   Writes a floating point number
>> WriteBool(key, value)    Writes a boo
>
> I totally agree. What about ctlListView? The fact that its
> AppendYesNoItem() member function doesn't overload AppendItem() is, as
> I said at the time, logical, because you aren't actually appending a
> true or false value - you're appending a "Yes" or a "No".

Yeah, I think that one is OK - AppendItem() is akin to Write() - ie.
string by default - where AppendYesNoItem() is (sort of) akin to
WriteBool().


-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

pgadmin-hackers by date

Next:From: Dave PageDate: 2011-02-16 19:23:00
Subject: pgAdmin III commit: Another set of wx2.9 updates. This patch includest
Previous:From: Peter GeogheganDate: 2011-02-16 18:50:39
Subject: Re: pgAdmin III commit: Include a variant of sysSettings::Write() that take

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group