Hi Dave!
[EMAIL PROTECTED] wrote:
(...)
Erwin; I'm somewhat wary of fixes in the treeview refresh code as there
can be odd corner cases caused by the relationships between some object
types. If I get you an updated exe, would you mind running it though
it's paces to help check I didn't miss anything?
Sure, I'll see what I can nag. :)
Actually, I've had a posting on this very subject in my draft folder for
some time. I was just not sure what's the best course of action to propose.
I'll append it here, just in case.
[EMAIL PROTECTED] did not yet write:
Hi developers! Hi Dave!
Testing the new snapshot: pgAdmin III 1.7.0 (Jun 22 2007, rev:
6379:6385). Client Win XP, host: Debian Sarge / PG 8.1.8
When making changes to achild element of a table (column, index, ...)
in the properties dialog, the SQL pane for the object is being
refreshed immediately. However, the SQL pane for the table is not
refreshed at the same time. We end up with updated SQL for the child
element but obsolete SQL for the table. This is sort of confusing.
I think it should be all or nothing in this case, with a preference on
"all": refresh the SQL pane for the table as well.
Of course we have to take into account a manual refresh on a child
elements as well. If you have an easy way of checking whether the
refresh has brought anything new, you might cascade the refresh to the
table. We might end up with updated SQL for the table and for the
initiating child element, but obsolete SQL for other child elements.
So the best course of action might be to refresh the SQL pane for
_all_ nodes of the table sub-tree whenever we "officially" know of a
change on any element in the tree under it - or on any element that
actually influences the SQL pane of the table. That is what is special
about the table node: it incorporates information of child objects in
the SQL pane. Other nodes don't. Except for views. (?)
Or never refresh anything unless the user explicitely requests it. A
refresh _may_ also be unwelcome, as information may be lost! I have
used the old information to undo changes that went wrong before ...
As far as I have seen, v1.6.3 behaves the same way.
I AM JUST NOT SURE.
Regards
Erwin
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
