On Thu, Sep 17, 2009 at 4:45 PM, Dan Halbert wrote:
> [I apologize: there were typos in the Ubuntu version number and in step 7.
> Here is the corrected version.]
>
> Here's another edit grid bug: this one is a crash. I see this only on Linux,
> on both 1.8.4 and 1.10.0
> Linux is Ubuntu 9.04 (j
On 17/09/2009 16:07, Dan Halbert wrote:
> 1. Bring up a table in the edit grid.
> 2. Select a low-numbered row by clicking in the row number column on the
> extreme left. E.g, click "3".
> 3. Shift-Select a higher-numbered row in the same way to get a select range:
> e.g., shift-click "5".
>
> I
[I apologize: there were typos in the Ubuntu version number and in step 7. Here
is the corrected version.]
Here's another edit grid bug: this one is a crash. I see this only on Linux, on
both 1.8.4 and 1.10.0
Linux is Ubuntu 9.04 (jaunty), updated to latest packages as of today. If you
want to
Here's another edit grid bug: this one is a crash. I see this only on Linux, on
both 1.8.4 and 1.10.0
Linux is Ubuntu 8.04 (jaunty), updated to latest packages as of today. If you
want to know a specific gtk2 package version, let me know.
1. Start up a fresh pgadmin3.
2. Bring up an edit grid fo
Hi - this seems to be a row selection bug. I see it on both pgadmin 1.8.4 and
1.10.0, on both Linux and Windows:
1. Bring up a table in the edit grid.
2. Select a low-numbered row by clicking in the row number column on the
extreme left. E.g, click "3".
3. Shift-Select a higher-numbered row in t
Dear PgAdmin Development Team,
I'm running pgAdmin on a Gentoo Linux system:
linux-2.6.24-gentoo-r7
dev-db/pgadmin3-1.8.2 USE="-debug"
dev-db/postgresql-8.0.15 USE="doc nls pam perl python readline ssl tcl
xml zlib -kerberos -pg-intdatetime (-selinux) -test"
KDE 3.5.9
i686
I can't copy and past
Erwin Brandstetter wrote:
[EMAIL PROTECTED] wrote:
Erwin Brandstetter wrote:
[EMAIL PROTECTED] wrote:
And in case you were wondering, we use the wxTE_RICH flag to allow
the control to hold more than 64KB of text (though I do wonder if
that's actually still required).
Now that you have dis
[EMAIL PROTECTED] wrote:
Erwin Brandstetter wrote:
[EMAIL PROTECTED] wrote:
And in case you were wondering, we use the wxTE_RICH flag to allow
the control to hold more than 64KB of text (though I do wonder if
that's actually still required).
Now that you have disabled editing bytea, it mig
Erwin Brandstetter wrote:
[EMAIL PROTECTED] wrote:
It actually seems to happen on paste, not copy, and happens with the
editor in rich text mode. It's a wx bug though so I'll log it with them.
As you can deselect the ghost linebreak before copying, and if you do,
it won't be pasted, it cert
[EMAIL PROTECTED] wrote:
It actually seems to happen on paste, not copy, and happens with the
editor in rich text mode. It's a wx bug though so I'll log it with them.
As you can deselect the ghost linebreak before copying, and if you do,
it won't be pasted, it certainly looks like it owuld h
Dave Page wrote:
Erwin Brandstetter wrote:
Hi developers! Hi Dave!
Testing RC2, rev 5607:5610. Client Win XP.
There is one more longstanding issue I have not reported yet and can't
find in the "known issues" list.
In edit mode, you can select an extra linebreak past the last real
character
Erwin Brandstetter wrote:
Hi developers! Hi Dave!
Testing RC2, rev 5607:5610. Client Win XP.
There is one more longstanding issue I have not reported yet and can't
find in the "known issues" list.
In edit mode, you can select an extra linebreak past the last real
character. You cannot navig
Hi developers! Hi Dave!
Testing RC2, rev 5607:5610. Client Win XP.
There is one more longstanding issue I have not reported yet and can't
find in the "known issues" list.
In edit mode, you can select an extra linebreak past the last real
character. You cannot navigate the cursor past the las
Erwin Brandstetter wrote:
1) When a new row paste occurs, the cursor cell is moved to the
position of each column as data is inserted, such that it will be on
the last affected cell when the paste has completed. This ensures that
any undo operation will happen on the correct row.
Undoing the
Hi Dave!
[EMAIL PROTECTED] wrote:
Thanks for the insight.
So, onto the changes I've made:
1) When a new row paste occurs, the cursor cell is moved to the
position of each column as data is inserted, such that it will be on
the last affected cell when the paste has completed. This ensure
Erwin Brandstetter wrote:
Hi developers! Hi Dave!
Testing RC2. Client Win XP, Server Debian Sarge, PostgreSQL 8.1.4.
I think I have found more issues in the edit grid, which have some
potential to damage things.
I've committed some changes which I think address most of the issues you
ment
Hi developers! Hi Dave!
Testing RC2. Client Win XP, Server Debian Sarge, PostgreSQL 8.1.4.
I think I have found more issues in the edit grid, which have some
potential to damage things.
Sorry to bring this up so close to release. I did not find it any
earlier. Anyway, it is up to you what you
[EMAIL PROTECTED] wrote:
Erwin Brandstetter wrote:
(...)
If I hit now, I end up with FALSE (!). That wouldn't be by
design, would it?
Probably not :-). I've committed a change which modifies the behaviour
such that simply clicking on the cell no longer cycles the value - it
now just displa
Erwin Brandstetter wrote:
Hi developers! Hi Dave!
Testing RC1. Client is Win XP. Server is Debian Sarge.
I have come across a peculiar effect while editing boolean fields. With
other fields, if you want to discard your changes while editing a field,
you hit and the original value is back (as
Hi developers! Hi Dave!
Testing RC1. Client is Win XP. Server is Debian Sarge.
I have come across a peculiar effect while editing boolean fields. With
other fields, if you want to discard your changes while editing a field,
you hit and the original value is back (as long as you haven't
saved
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Nash
> Sent: 10 March 2006 14:02
> To: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Edit grid crashes adding new
> rows to table with auto
: Dave Page [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 8:44 AM
To: [EMAIL PROTECTED]; pgadmin-support@postgresql.org
Subject: RE: [pgadmin-support] Edit grid crashes adding new rows to
table with autoincrement primary key.
> -Original Message-
> From: [EMAIL PROTECTED]
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Nash
> Sent: 10 March 2006 13:18
> To: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Edit grid crashes adding new
> rows to table with autoincrement p
Dave, your suggestion worked ... creating a new database, and a new table
within it made it possible to edit the table without error. For
completeness, the new table definition appears below, but it's pretty clear
that there's no meaningful difference between it and the one that didn't
work:
CREA
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Nash
> Sent: 09 March 2006 17:09
> To: pgadmin-support@postgresql.org
> Subject: Re: [pgadmin-support] Edit grid crashes adding new
> rows to table with autoincrement pri
s with an
autoincrement data type.
Many thanks!
Dave N.
-Original Message-
From: Dave Page [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 09, 2006 11:57 AM
To: [EMAIL PROTECTED]; pgadmin-support@postgresql.org
Subject: RE: [pgadmin-support] Edit grid crashes adding new rows to
table wit
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of David Nash
> Sent: 09 March 2006 14:39
> To: pgadmin-support@postgresql.org
> Subject: [pgadmin-support] Edit grid crashes adding new rows
> to table with autoincrement p
Dear friends,
I'm seeing a problem consistently when using the edit grid to add new rows
to a table whose primary key has data type "bigserial." After completion of
editing the columns excluding that of the primary key, when I exit the
editing widget (e.g. by pressing the Enter key, or clicking t
28 matches
Mail list logo
