On Wed, Dec 3, 2008 at 6:13 AM, Ashesh Vashi
> Hi Luis Ochoa,
> Thanks for reviewing it.
>> A good way to access the vector, but allowing the code to access directly
>> the objects based on the index probably decrease the independece of the
>> subyacent structured inside the collection. If I decided to change the
>> vector for a hash map in a future this operator probably difficult the
>> change by example, because now we have hard code access directly to the
>> structure inside the collection.
> For the same reason, I have not introduced the operator  in
> gqbCollection class, but in gqbArrayCollection.
> I thought - as we are able to access & insert the objects using index.
> Then, why not to have direct access to the object (easy for replacement
> In case if one of us decide to change the vector for a hash map in a
> future, the insertion of an object at a particular index will also create
> the same problem, which this operator will do.
> What do you say?
Ok no problem I musunderstand all, because I get confused at the moment of
that commentary, you're right.
> Sorry if I misunderstood.
> And thanks for the help.
> Thanks & Regards,
As I have told you, this was a bug introduced earlier.
> The object sqlNoteBook (in frmQuery class) and the object tabs (in the
> gqbController class)
> both were using the same id (CTL_NTBKCENTER).
> And in frmQuery class, an event handler - OnChangeNotebook is registered
> with this id.
> I changed the id for the object tabs of gqbController to CTL_NTBKPANELS.
> Please find the patch for the same.
Ok a legacy error from the very first beta versions ;) but now is solve.
By the way Ashesh as I notice you know the tool I'm going to make you some
I have been thinking a way of adding the group by and having operators to
the GQB to basically allow the user to create more complex queries, but I'm
not sure about the correct user interface to do this task, I think that
group by can be as the ordering tab and the having tab can be as the
criteria tab. Do you have any suggestions?
And about the join panel as I told you I was thinking that if the user
select one join should be an easy option to change the query type like a
floating toolbar with button with the join types that will be show near the
selected join. What do you think about this?
Now I publish a list of what I think will be useful functionalities on the
GQB if someone desiree to contribute:
1. Add Subqueries, this probably requeries multiples tabs for query.
2. Add Support to composite types.
3. Add a new skin for the graphics probably with a scroll on right and
showing always all the columns (fixed at top) but the other columns can be
move up/down with the scrollbar (an option can allow to choose between this
and old graphics). And each table have a minimize (shrink only to table
title),restore and remove from query button just as a window in a graphical
4. Add Save/Load functionality (probably xml).
Sorry for a lot of commentaries for just one email.
Finally I tested your patch and everything was fine for me.
In response to
pgadmin-hackers by date
|Next:||From: Guillaume Lelarge||Date: 2008-12-04 22:40:15|
|Subject: Re: Patch for "Panel for Joins in the Graphic Query
|Previous:||From: svn||Date: 2008-12-04 11:52:54|
|Subject: SVN Commit by dpage: r7509 - trunk/pgadmin3/pgadmin/frm|