PATCH: Precise control over query's modification state

Hello,

Regarding this report:
http://www.postgresql.org/message-id/C61C1DE0-A5ED-4318-9391-7E35081C56D5@empiric.al

AZ>> 7. When I open a SQL console while an object/function/etc is
AZ>> selected, the text inside is how to create it. That’s
AZ>> (occasionally) helpful. However, if I close it without modifying
AZ>> it, I shouldn’t be asked if I’m sure I don’t want to save it first
AZ>> when I haven’t edited anything inside yet.

JFO> That's the way an option of query editor "Copy SQL from main window to
JFO> query tool" is implemented. It makes an initial modification of empty
JFO> textarea for you, surely marking it as modified.

Attached patch adds member variable to track last origin of query
modification:
ORIGIN_MANUAL - edited directly by user
ORIGIN_FILE - loaded from file
ORIGIN_INITIAL - passed into constructor
ORIGIN_HISTORY - picked from "previous queries"
ORIGIN_GQB - generated by query builder

Such approach allows for some enhancements of user's experience.
I've implemented the following in this patch:

1. Text initialization in constructor isn't considered a change, so it
will not ask for save confirmation if left intact.(*)

2. Allow to "Save As" the initial text immediately, without having to
modify text in order to enable save button. Also the behaviour
shouldn't depend on settings->GetStickySql(), because there are other
use-cases not related to this option (for example, insert-scripts on a
table).

3. Skip confirmation to replace query text by GQB if previously it was
generated by GQB and was left intact.

(*) - I've run into somewhat inconsistent behaviour of STC under
Windows - some more events may come after query initialization and
wxSafeYield() in constructor. These late events switch origin from
initial to manual, thus breaking the idea of #1. I've made a hack to
filter these events out and it seems to work ok (frmQuery.cpp:1692) on
Windows and Linux.
But think I'm missing the point in working with STC. Probably it's a
separate thread. I don't know how to work around that better :(

--
Best regards,
J.F.