Re: pgadmin3 query tools

Hi Keith,

efesar wrote:

>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.
>
That's not far from my solution, switching from one to the other with a
menu/toolbar. We would have two tools, I wouldn't really bother about
that. As I wrote, the core code could be wrapped into a control, either
derived from wxNotebook or wxListView, whatever is more useful.
There might be another argument towards two distinct tools: Porting to
**ix might be easier. Don't know when I find the time to check with
Linux (maybe weekend), I strongly doubt that my threading code will work
there too.

>
>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.
>
Hmbpf.
I don't believe that works. wxMDIParentFrame bends that poor wxFrame in
a manner that I doubt it will still behave like a normal wxFrame for me.

>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.
>
Agreed, there are still wishes about the file menu I want to implement.

>
>
>
>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.
>
>
That's not a special concern to me. For the query builder, it even might
be a better solution. On the other side, it will look more consistent if
it's always at the bottom.

>That's old code. It's been namespaced for more than a month.
>
Not flushed to cvs?

>In any case,
>we're still working on the object caching solution, so direct DB queries are
>a temporary workaround.
>
>
Look at pgTable::GetSql(), there I browse, force pgCollections to
populate and update pgColumns. It's easy, and could be done from
PG_TABLES as well.
Calling ShowTreeDetails(browser,0,0,0,0) has virtually no cost after the
first call.

>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.
>
That's totally impossible. A long time ago, I decided to write error
free code. Since then, my code has been proven to be complete, precise,
delicious, juicy, absolutely genious and defect free.
Well, almost... ;-)

>I'll try to do more testing to get further data on the memory leaks to you.
>
Just tell me where you find something. And I'll find out who's at my
machine adding that leaks while I'm off-site. Just reviewed all
ExecuteSet and found two missing pgSet deletes in pgColumn and pgSequence.

Best regards,

Andreas