Re: Results from testing RC2, rev: 5607:5627M

Hi Dave!

Testing 1.6 RC2 rev: 5634:5635 on Win XP- the one you've sent me.

You've got both issues fixed. The application keeps getting better. :)
I found remaining corners in both cases, but of very limited impact. So 
if you are tired of this, you might as well skip the rest of the mail.


dpage@postgresql.org wrote:
> Erwin Brandstetter wrote:
>
>> - Starting new lines by inserting data is now less confusing, the new 
>> dialogue prevents data loss. And the option to cancel the operation 
>> is a major improvement. That's the one I will be using 99% of the time.
>> The current way of handling cursor and selection will remain prone to 
>> errors and cornercases, though.
>
> Maybe - but I think they really are corner cases for the most part. 
> You're pretty much the only complainant in 5 years or so! (not that 
> I'm saying they shouldn't be fixed you understand).

Sure, I understand. Still, some features (like pasting rows) are new in 
v1.6. And beta-testers like me are "early complainers" by nature. ;)


>>
>> - The undead "undo" issue:
>> The save dialogue pops up, even if there is no data to save, even if 
>> I did not enter edit mode in the row of the cursor at all, or if I 
>> set the cursor on the "new" row. This isn't dangerous, but confusing.
>> If I answer yes to the uncalled-for save dialogue, then the rest of 
>> the operation seems to be aborted (nothing happens).
>
> Yeah, think I've got this case nailed. Will send you an exe for testing.

So you didn't skip? Curiosity killed the cat! ;)
The remaining cornercase here:
As long as I stay within the edited row, the previously described issue 
will kick in.
When undo is active while nothing has been changed, the save dialogue 
will pop up, and if I say yes, then rest of the operation will be 
cancelled silently. No saving (of course - nothing changed), but no 
pasting either.

But now I can get rid of this by clicking outside the row, so the scale 
of the issue has been diminished.


>> - While experimenting with pasting, I pasted the dummy text 'asdfg' 
>> to an integer column and saved - which produced an error as expected. 
>> The nature of the error was a bit of a surprise though:
>>
>>    An error has occurred:
>>    FEHLER: Spalte >>asdfg<< existiert nicht.
>>
>> Meaning: "Error: Column >>asdfg<< does not exist."
>> Somehow data is being mistaken for a column name. This could possibly 
>> lead to grave errors. (Or is it the German translation wrong?)
>
> Hmm. This only happens because the underlying text control handles 
> it's own paste operations - when you type into a numeric field, we 
> filter out invalid characters (ie. alpha), but when pasting that 
> doesn't happen. That will take some real effort to resolve properly.
>
> For now, I've just made sure that numeric data gets quoted to remove 
> the column/funtion ambiguity with unquoted text. That will at least 
> ensure that the user gets a sensible error message from the server.

That takes care of it, mostly.
Unlike with text fields the new quoting in numeric fields does not 
escape quotes in the pasted data.
If there is no specific reason for the deviation, you might consider 
adapting the behaviour for text fields to prevent weird effects.

Told ya to skip the rest. :p


Regards
Erwin