Re: Issues with dlgType

From: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
To: Dave Page <dpage(at)pgadmin(dot)org>
Cc: pgadmin-hackers <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: Issues with dlgType
Date: 2010-10-24 02:06:52
Message-ID: 4CC394BC.1020304@lelarge.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgadmin-hackers

Le 22/10/2010 05:02, Guillaume Lelarge a écrit :
> Le 22/10/2010 01:01, Dave Page a écrit :
>> On Fri, Oct 22, 2010 at 12:29 AM, Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info> wrote:
>>> Hi,
>>>
>>> I've found quite a few bugs in the way we handle the dlgType dialog, and
>>> more to the point the Length and Precision textboxes. I use some time to
>>> work on this on my 11 hour plane trip, and I have this patch. The big
>>> issue I see is that it really contains a lot of changes. I'm not sure it
>>> is appropriate to apply it on 1.12.
>>>
>>> Actually, I want to apply it on 1.12. But I would like to know what
>>> others think about it.
>>
>> Can you explain what the issues are please? Validating a patch against
>> unknown intent isn't easy.
>>
>
> I'll try. That's not really easy though.
>
> All the bugs are related to composite types.
>
> Let's say I add two members. First one is named c1, of type varchar(10),
> and second one is an integer named c2. If I click on c1, I see a
> datatype "character varying(10)" and a length of 10. Length textbox is
> disabled, whereas it should be enabled because the composite type isn't
> yet created and I should be able to change it. I also think that
> datatype should display "character varying" (ie, without the length).
> As the combobox is enabled, a user can think he could change the length
> by typing it, but alas, put another length and the "Add/change" button
> is suddenly disabled (because the "character varying(20)" is not part of
> the cached type. You can of course get rid of the length to only have
> "character varying", which is found in the types cache and which makes
> the Length textbox enabled. I would say umbersome UI, don't you think.
>
> But wait, there's more. Click on the integer member. The length textbox
> still shows the length of the previous member you selected (and
> precision too if you have one). Length and Precision textboxes are
> disabled, but it still is a weird UI.
>
> Now, let's add a third member, c3 of type numeric(10,5). Select the c1
> member. Oh, Length textbox is still enabled. Precision textbox still
> shows 2. Click on the c2 member, same behaviour (I have an integer
> member with a length of 10 (remember the textbox is enabled), and a
> disabled precision of 2. Now click again on the c1 member, and change
> the size to 12. Click on the c2 member: Length enabled of value 12, and
> Precision disabled of value 2. Weirder. Click on member c3: Length
> enabled of value 12 (whereas it should be 10), Precision disabled of
> value 2.
>
> In fact, the datatype combobox always shows the good type, with length
> and precision. The issue is that you need to change the text in the
> combobox to make it look like before, and then change Length and
> Precision to the correct ones, to be able to change the type. And you
> have to forget the values in these textboxes when you select a member
> because they usually are wrong.
>
> So, what this patch does is to always put the good value in the textbox,
> and to never change the datatype to something with length and precision.
> And to make sure everything is enabled/disabled when they should be.
>

Commited after a little chat with Dave on Jabber.

--
Guillaume
http://www.postgresql.fr
http://dalibo.com

In response to

Browse pgadmin-hackers by date

  From Date Subject
Next Message Guillaume Lelarge 2010-10-24 02:07:10 Re: Ticket 247: Defined Custom Colors not retained
Previous Message pgAdmin Trac 2010-10-24 01:55:08 Re: [pgAdmin III] #247: Defined Custom Colors not retained