efesar wrote:
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.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.
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.
Hmbpf.
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.
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.
Agreed, there are still wishes about the file menu I want to implement.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.
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.
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 old code. It's been namespaced for more than a month.Not flushed to cvs?
In any case,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.
we're still working on the object caching solution, so direct DB queries are
a temporary workaround.
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 treeThat'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.
code. I haven't pinpointed them yet, but it looks like some database object
is not being deleted after it's allocated.
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
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
