Thread: pgAdmin Beta 3 problems

pgAdmin Beta 3 problems

From
"Gary Doades"
Date:
I seem to have encountered several problems with the latest Beta3 of 
pgAdmin. This was installed with the latest Beta3 Dev1 installer for 
PostgreSQL.

I had Beta2 of pgAdmin previously installed, which was uninstalled 
when I uninstalled Beta2 PostgreSQL.

1) The "Recent Files" menu doesn't seem to work at all any more. 
There was a list of files left over from a previous pgAdmin install. None 
of these worked. Even when opening a file then going to the recent files 
list it still wouldn't re-open.

2) Creating a new database on the local (Windows XP) cluster gave a 
"Locale: is invalid" message. I only typed in the name of the database 
and clicked OK. The default locale in the drop-down was UNICODE. 
When I selected something other than UNICODE and the re-selected 
UNICODE, clicked OK and it created the database OK.

3) It still gets the "dirty edit buffer" logic wrong. I have noticed that then 
I open a file it has not marked the buffer as dirty. I can navigate around 
the screen, making no changes and it is still OK. As soon as the edit 
buffer scrolls, with either the keyboard or mouse, the buffer is flagged 
as dirty and you are asked for saving changes when you quit.

Regards,
Gary.



Re: pgAdmin Beta 3 problems

From
Andreas Pflug
Date:
Gary Doades wrote:
> 
> 1) The "Recent Files" menu doesn't seem to work at all any more. #

Yes, I spoiled that. Unfortunately, I committed a mixture of old and new 
code, which results in this behaviour. Fixed now.
> 
> 2) Creating a new database on the local (Windows XP) cluster gave a 
> "Locale: is invalid" message.

I didn't believe it until I saw it with my very own eyes. This is a 
problem that the new wx snapshot introduced, some very strange stuff was 
coded for win32, which ultimately breaks two very basic wxComboBox 
methods. I had to implement a helper class to replace the broken method 
with a better one without requiring another private wx snapshot.

> 3) It still gets the "dirty edit buffer" logic wrong. I have noticed that then 
> I open a file it has not marked the buffer as dirty. I can navigate around 
> the screen, making no changes and it is still OK. As soon as the edit 
> buffer scrolls, with either the keyboard or mouse, the buffer is flagged 
> as dirty and you are asked for saving changes when you quit.

I found that too: the change is generated by the control itself, it's 
the colourising code which is done on demand when scrolling. I'm forcing 
it to colourize all text now, which stops it from throwing changed 
events later on.

Fixed in cvs, new win32 snapshot following tonight.

Phew! These where some nasty bugs. Thanks for reporting!

Regards,
Andreas