Re: pgadmin3 query tools

> Uh, I hate MDI. You're using it at the moment to keep tables and views,
> and MDI looks quite reasonable for this (actually, the first time MDI
> looks good for me). I don't see how the sql input field should be
> assembled into the existing query builder, unless the second notebook
> page is used; I really wouldn't like that. Actually, I INSIST that the
> query window as it is now (on top query, below result) is somehow
> retained. Explicitely I don't like the edit window to become a MDI
> child. I'll sound quite harsh about this, but this part of pgadmin2 was
> the trigger for me to jump into pgadmin3, and if that feature is spoiled
> or degraded I'll be really upset.

The only thing that is MDI is the table/view windows, and that should remain
true. I dislike MDI as well, and I wanted to avoid it. However, it was the
easiest way to do what was necessary. To build clipped frames in a similar
manner seems like unnecessary effort. The reason I would like to build my
own Pseudo-MDI class (in the future) is to avoid the uncustomizable MDI
framework in wxWindows.

Here are my two cents. We put a "view" menu in BOTH our tools. It will
either have a checkmark on Query Builder or on Query Analyzer (or the
preferred name, of course). When in the Query Builder, if they check on
Query Analyzer, it will close itself and open your tool. Vice versa in your
tool. And we can share window placement.

We can even work on merging them into one class, since wxMDIParentFrame is
derived from wxFrame. That's just a consideration. I'd like your feedback
and Dave's as well. BTW, this paragraph refers to "some later date" after I
have a nearly functional Query Builder. It would be too easy for conflicts
to develop if we merge them now. For now I'm simply going to duplicate your
menus and methods and icons.

> Nevertheless, there are other ways. I can think of an additional window
> (some kind of assistant, as MS would call it), that can be opened, and
> which will inject the query into the query execution window (directly
> executing or pasted into the editor).
> Another way would be to extract the lower part (notebook, listview and
> messages) into an isolated control, making it reusable Then we would
> have two query tools, targeted to quite different users. To hide this
> fact, the used sql tool could be selected from "options"
> (standard/advanced).

I believe Dave wants to avoid two tools. See merge idea from previous
paragraph with the "view" menu option.

I have no problem with putting the QB tabs at the bottom. The only reason I
put them at the top is simple negligence. In fact, I'm changing that as we
speak and will be in my next CVS update.

> (btw keith: checking for relowner > 1 in dlgAddTableView will hide all
> my tables... check for system namespace instead)

That's old code. It's been namespaced for more than a month. In any case,
we're still working on the object caching solution, so direct DB queries are
a temporary workaround.

BTW, I finally did come across some memory leaks in the additional tree
code. I haven't pinpointed them yet, but it looks like some database object
is not being deleted after it's allocated. I'll try to do more testing to
get further data on the memory leaks to you.

-Keith