Обсуждение: edit grid: linebreak added to data
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 last real character, but you can select a ghost linebreak - which happens every you enter edit mode. Depending on the used font it is sometimes hard to spot and a possible trap for common copy&paste jobs. In any case, it is annoying. Integer or numeric fields are not affected. But text, char, varchar, date, timestamp (and possibly others) are. The issue has been present since v1.4.2 or earlier. It might be easy fix? Here's hoping, that this is my last bug report prior to release. :) Regards Erwin
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 navigate the cursor past the last real character, > but you can select a ghost linebreak - which happens every you enter > edit mode. Depending on the used font it is sometimes hard to spot and a > possible trap for common copy&paste jobs. In any case, it is annoying. > > Integer or numeric fields are not affected. But text, char, varchar, > date, timestamp (and possibly others) are. > The issue has been present since v1.4.2 or earlier. > It might be easy fix? 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. > Here's hoping, that this is my last bug report prior to release. :) Let's hope so! Cheers, Dave.
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. You cannot navigate the cursor past the last real >> character, but you can select a ghost linebreak - which happens every >> you enter edit mode. Depending on the used font it is sometimes hard >> to spot and a possible trap for common copy&paste jobs. In any case, >> it is annoying. >> >> Integer or numeric fields are not affected. But text, char, varchar, >> date, timestamp (and possibly others) are. >> The issue has been present since v1.4.2 or earlier. >> It might be easy fix? > > 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. Hmm, I think it's actually a Microsoft bug - I see the same behaviour in Wordpad and Word 2K3, but it's only apparent when pasting into another rich text editor. I start Word, and type 'Hello', with no quotes, and no trailing carriage return, then hit Ctrl-A, Ctrl-C to copy to the clipboard. I then paste the text into Notepad, and see 'Hello', with no trailing CR. I paste the same text into Wordpad, or Word, and a CR is appended. 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). Regards, Dave.
dpage@postgresql.org 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 happen on copy. > Hmm, I think it's actually a Microsoft bug - I see the same behaviour > in Wordpad and Word 2K3, but it's only apparent when pasting into > another rich text editor. > > I start Word, and type 'Hello', with no quotes, and no trailing > carriage return, then hit Ctrl-A, Ctrl-C to copy to the clipboard. I > then paste the text into Notepad, and see 'Hello', with no trailing > CR. I paste the same text into Wordpad, or Word, and a CR is appended. > > 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 might not be needed anymore? As for date & timestamp, those will hardly grow beyond 64k. :) Regards Erwin
Erwin Brandstetter wrote: > dpage@postgresql.org 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 happen on copy. > > >> Hmm, I think it's actually a Microsoft bug - I see the same behaviour >> in Wordpad and Word 2K3, but it's only apparent when pasting into >> another rich text editor. >> >> I start Word, and type 'Hello', with no quotes, and no trailing >> carriage return, then hit Ctrl-A, Ctrl-C to copy to the clipboard. I >> then paste the text into Notepad, and see 'Hello', with no trailing >> CR. I paste the same text into Wordpad, or Word, and a CR is appended. >> >> 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 might not be needed > anymore? Why? Text/varchar can hold up to a gigabyte iirc. As for date & timestamp, those will hardly grow beyond 64k. :) True - it hadn't crossed my mind that they shouldn't realy have used the multiline editor anyway (too early, no coffee!!). I've change dates, times, timestamps and intervals to use a single line editor. I'll send you the regulation .exe update offlist :-) Thanks, Dave.
dpage@postgresql.org wrote: > Erwin Brandstetter wrote: >> dpage@postgresql.org 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 might not be needed >> anymore? > > Why? Text/varchar can hold up to a gigabyte iirc. Right. But who would possibly dream of editing gigabytes in pgAdmin? And don't you have an option "Max. characters per column" in place, which could prevent excess data? > As for date & timestamp, those will hardly grow beyond 64k. :) > > True - it hadn't crossed my mind that they shouldn't realy have used > the multiline editor anyway (too early, no coffee!!). I've change > dates, times, timestamps and intervals to use a single line editor. > > I'll send you the regulation .exe update offlist :-) I'll look into it. Regards Erwin
Erwin Brandstetter wrote: > > > dpage@postgresql.org wrote: >> Erwin Brandstetter wrote: >>> dpage@postgresql.org 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 might not be needed >>> anymore? >> >> Why? Text/varchar can hold up to a gigabyte iirc. > > > Right. But who would possibly dream of editing gigabytes in pgAdmin? And > don't you have an option "Max. characters per column" in place, which > could prevent excess data? The Max chars option is for the query tool. And no, I quite agree about editting a gigabyte of text, however it's not beyond the realms of possibility for someone to want to paste say, 100Kb of logfile into the grid. I've certainly done so myself in the past. Regards, Dave