Thread: table OCX control

table OCX control

From
Tim Finch
Date:
Dear all,

Firstly may I apologise to Mark. The work I outline in this message was
done before I realised you had already made the first version of the
DataWidget ocx control. I had totally missed it.

http://www.fosterfinch.co.uk/pgadmin

The site has a link to a screen grab of my first table ocx control design.
it has absolutely no code in it yet.
Things to note, and for discussion
- Tables will be able to be themed (blue, red, white, yellow), wher the
background colours all change to that theme, if the user wishes to, in
order to spot tables quicker in the designer
- Bold fieldnames are Primary Keys
- italic fieldnames have some form on constraint other than FK on them
- underlined fields are FKs
- tick boxes on left do what MS SQL designer does, selects fields for display
- White boxes at end of fieldname line tell you the column type in
abbreviated form (i8 - Int8, Vc - Varchar etc.)
- The idea will bwe that when the user hovers over one of these a pop up
tells you additional info like Varchar length, or check/FK constraint details

Thoughts:
- Mark, I see you have fleshed out more on the code side of your
datawidgets, I will use these methods/props etc where feasible. I feel that
my design of the datatable ocx is a bit more clean and less fussy. As the
designer is going to be pressured for screen space at the top for the
tables we are going to need to keep the tables small.
- I know the wish list for pgAdmin contains the idea of a project file in
the future. This is going to be a key requirement, esp where query
designing is concerned as the user will position tables and colour them
etc. and will want this to be retrieved. Surely one of the best places to
keep the project file is actually in a table in database itself? In the
meantime, what will we do about storing the non SQL aspects of a view
design for retrieval later on - simply save them to a .pvd (PgAdmin View
Design) file on the local drive of the user?

Hope this input helps get ideas rolling.

Tim.


Re: table OCX control

From
Dave Page
Date:

> -----Original Message-----
> From: Tim Finch [mailto:pgadmin@timfinch.cix.co.uk]
> Sent: 07 March 2002 11:01
> To: pgadmin-hackers@postgresql.org
> Subject: [pgadmin-hackers] table OCX control
>
>
> Dear all,
>
> Firstly may I apologise to Mark. The work I outline in this
> message was
> done before I realised you had already made the first version of the
> DataWidget ocx control. I had totally missed it.
>
> http://www.fosterfinch.co.uk/pgadmin
>
> The site has a link to a screen grab of my first table ocx
> control design.
> it has absolutely no code in it yet.
> Things to note, and for discussion
> - Tables will be able to be themed (blue, red, white,
> yellow), wher the
> background colours all change to that theme, if the user
> wishes to, in
> order to spot tables quicker in the designer
> - Bold fieldnames are Primary Keys
> - italic fieldnames have some form on constraint other than FK on them
> - underlined fields are FKs
> - tick boxes on left do what MS SQL designer does, selects
> fields for display
> - White boxes at end of fieldname line tell you the column type in
> abbreviated form (i8 - Int8, Vc - Varchar etc.)
> - The idea will bwe that when the user hovers over one of
> these a pop up
> tells you additional info like Varchar length, or check/FK
> constraint details

Cool.

> Thoughts:
> - Mark, I see you have fleshed out more on the code side of your
> datawidgets, I will use these methods/props etc where
> feasible. I feel that
> my design of the datatable ocx is a bit more clean and less
> fussy. As the
> designer is going to be pressured for screen space at the top for the
> tables we are going to need to keep the tables small.
> - I know the wish list for pgAdmin contains the idea of a
> project file in
> the future. This is going to be a key requirement, esp where query
> designing is concerned as the user will position tables and
> colour them
> etc. and will want this to be retrieved. Surely one of the
> best places to
> keep the project file is actually in a table in database
> itself? In the
> meantime, what will we do about storing the non SQL aspects of a view
> design for retrieval later on - simply save them to a .pvd
> (PgAdmin View
> Design) file on the local drive of the user?

We should try to keep everything in the database to allow for
multi-developer environments. One thing I learned from pgAdmin I is to keep
the SSOs (server side objects) as simple a possible and only use them where
absolutely necessary. pgAdmin I had about 8 views, 8 functions and 3 tables
which were a real pain in the arse to autoupgrade and repair. Many people
didn't like them either because they cluttered up their databases.

In pgAdmin II, the only SSO is pgadmin_rclog (the Revision Control log)
which was kept as simple as possible, yet as future proof as possible. This
is only created when RC is enabled on a database, and is dropped if it is
disabled. We need to make sure that any more SSOs we add are as friendly...

All sounds good though - look forward to some working code.

Regards, Dave.

Re: table OCX control

From
"Mark A. Taff"
Date:
I'll do a better job of quoting below. :)

-----Original Message-----
From: pgadmin-hackers-owner@postgresql.org
[mailto:pgadmin-hackers-owner@postgresql.org]On Behalf Of Tim Finch
Sent: Thursday, March 07, 2002 3:01 AM
To: pgadmin-hackers@postgresql.org
Subject: [pgadmin-hackers] table OCX control

Dear all,

Firstly may I apologise to Mark. The work I outline in this message was
done before I realised you had already made the first version of the
DataWidget ocx control. I had totally missed it.

http://www.fosterfinch.co.uk/pgadmin

The site has a link to a screen grab of my first table ocx control design.
it has absolutely no code in it yet.
Things to note, and for discussion
- Tables will be able to be themed (blue, red, white, yellow), wher the
background colours all change to that theme, if the user wishes to, in
order to spot tables quicker in the designer
- Bold fieldnames are Primary Keys
- italic fieldnames have some form on constraint other than FK on them
- underlined fields are FKs
- tick boxes on left do what MS SQL designer does, selects fields for
display
- White boxes at end of fieldname line tell you the column type in
abbreviated form (i8 - Int8, Vc - Varchar etc.)
- The idea will bwe that when the user hovers over one of these a pop up
tells you additional info like Varchar length, or check/FK constraint
details

<Mark>Sounds great.</Mark>

Thoughts:
- Mark, I see you have fleshed out more on the code side of your
datawidgets, I will use these methods/props etc where feasible. I feel that
my design of the datatable ocx is a bit more clean and less fussy.
<Mark>Tim said: As the
designer is going to be pressured for screen space at the top for the
tables we are going to need to keep the tables small.
Mark's reply: I don't think we are going to pressured at all for space.  The
form opens up at the current default of 80% of available screen space, and
all but one pane can be hidden by the user.  So they could easily have just
the diagramming pane take up their entire screen, if they wanted the room.
</Mark>

- I know the wish list for pgAdmin contains the idea of a project file in
the future. This is going to be a key requirement, esp where query
designing is concerned as the user will position tables and colour them
etc. and will want this to be retrieved. Surely one of the best places to
keep the project file is actually in a table in database itself? In the
meantime, what will we do about storing the non SQL aspects of a view
design for retrieval later on - simply save them to a .pvd (PgAdmin View
Design) file on the local drive of the user?

<Mark>All the view designer stuff can easily be regenerated based on a .sql
file or the reverse-engineered SQL code, with the exception of the placement
and other changes the user made to the layout of the diagramming pane.  That
should indeed be saved in the database, I think.</Mark>

Hope this input helps get ideas rolling.

Tim.


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org


Re: table OCX control

From
"Mark A. Taff"
Date:
I like the control.  Some discussion points:

1. I think the control need to be resizable, both by a minimize button and
by border dragging.
2. I like the notion of each instance of the control having the appropriate
icon (table, view, function, etc).
3. The diagramming pane should also have scroll bars, as required.  I don't
recall off the top of my head if it is there yet or not.
4. What are your plans/thoughts on linking entities?  For example, in a
standard diagramming section, I think FK relationships ought to be rendered
graphically between objects.  In the pane for the view designer though, the
user ought to be able to draw the relationship and modify them to show
inner, outer, cross joins, etc.


Your thoughts?

Regards,
Mark
-----Original Message-----
From: pgadmin-hackers-owner@postgresql.org
[mailto:pgadmin-hackers-owner@postgresql.org]On Behalf Of Tim Finch
Sent: Thursday, March 07, 2002 3:01 AM
To: pgadmin-hackers@postgresql.org
Subject: [pgadmin-hackers] table OCX control

Dear all,

Firstly may I apologise to Mark. The work I outline in this message was
done before I realised you had already made the first version of the
DataWidget ocx control. I had totally missed it.

http://www.fosterfinch.co.uk/pgadmin

The site has a link to a screen grab of my first table ocx control design.
it has absolutely no code in it yet.
Things to note, and for discussion
- Tables will be able to be themed (blue, red, white, yellow), wher the
background colours all change to that theme, if the user wishes to, in
order to spot tables quicker in the designer
- Bold fieldnames are Primary Keys
- italic fieldnames have some form on constraint other than FK on them
- underlined fields are FKs
- tick boxes on left do what MS SQL designer does, selects fields for
display
- White boxes at end of fieldname line tell you the column type in
abbreviated form (i8 - Int8, Vc - Varchar etc.)
- The idea will bwe that when the user hovers over one of these a pop up
tells you additional info like Varchar length, or check/FK constraint
details

Thoughts:
- Mark, I see you have fleshed out more on the code side of your
datawidgets, I will use these methods/props etc where feasible. I feel that
my design of the datatable ocx is a bit more clean and less fussy. As the
designer is going to be pressured for screen space at the top for the
tables we are going to need to keep the tables small.
- I know the wish list for pgAdmin contains the idea of a project file in
the future. This is going to be a key requirement, esp where query
designing is concerned as the user will position tables and colour them
etc. and will want this to be retrieved. Surely one of the best places to
keep the project file is actually in a table in database itself? In the
meantime, what will we do about storing the non SQL aspects of a view
design for retrieval later on - simply save them to a .pvd (PgAdmin View
Design) file on the local drive of the user?

Hope this input helps get ideas rolling.

Tim.


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org


Re: table OCX control

From
Tim Finch
Date:
>Mark's reply: I don't think we are going to pressured at all for space.  The
>form opens up at the current default of 80% of available screen space, and
>all but one pane can be hidden by the user.  So they could easily have just
>the diagramming pane take up their entire screen, if they wanted the room.
></Mark>

Thats good. Its just the default opening workspace is 1/4 to each pane, and
realistically they will need the diagram, field selection and possibly
SQL  panes open all the time. I agree the results pane is optional for
design time.


><Mark>All the view designer stuff can easily be regenerated based on a .sql
>file or the reverse-engineered SQL code, with the exception of the placement
>and other changes the user made to the layout of the diagramming pane.  That
>should indeed be saved in the database, I think.</Mark>

Your right, it was the diagramming pane I was referring to. Also the idea
of theming the table controls with the colour idea ought to be a database
scope setting (or optionally database scope) rather than View scope, would
mean some concept of a central 'project file' into which modules and
functions in pgAdmin have tyhe ability to write their settings, a sort of
'Registry' but stored in the pgsl backend.

In fact if we came up with a method of doing it Registry wise then
something like the view designer could determine its own 'hives' and 'keys'
and not care how, for example, the left hand tree view in pgAdmin stores
its own project related settings. What do you think Dave/Jean?

Tim


Re: table OCX control

From
Tim Finch
Date:
At 14:35 07/03/2002 -0800, Mark A. Taff wrote:
>I like the control.  Some discussion points:
>
>1. I think the control need to be resizable, both by a minimize button and
>by border dragging.

Yes. However I thought this might be best implemented by the DiagramView
(DV) control into which the DataTable (DT) OCXs will be drawn, the DV
setting the properties of the DTs as the user redraws them.

The Min button - do you meana form of roll-up like Dreamweaver etc. ? I was
also thinking the other day that DT objects should have a 'size' property
where the object can be drawn at one of say three different font-size
sizes. For example if you were making a View based on two main tables plus
a third linking table that is simple a M-M relationship breakdown with the
PKs of each main table, you might set this to the 'small' size and use B/W
colour scheme, showing its fields in a smaller point size, and thus taking
up less room, but the main tables appear in 'Medium' or 'Large' size, and
using the colour theming to show them in colour. In this way, is a minimise
button so necessary, I'm in two minds.

>2. I like the notion of each instance of the control having the appropriate
>icon (table, view, function, etc).

Yes that's a good idea. Functions however, are these going to appear in the
top window as a diagramming object? Surely they will just get referenced in
the 'select columns' grid underneath? I'm not fully au fait with PostgreSQL
functions yet - can the return a recordset that cen be used in a query,
i.e. can they be used as a table in FROM...JOIN statement? Surely the
diagram pane is simply for graphical representation of the FROM...JOIN
statement?

>3. The diagramming pane should also have scroll bars, as required.  I don't
>recall off the top of my head if it is there yet or not.

You're right, Yes it should and no its not. Now to this end, whats the gas
on us using commercially available OCX controls. I have a legal bought copy
of VSView, which contains an OCX that is a 'scrollable pane' - it takes
care of all that side of things. There are no financial licensing issues
with distributing it, but the problem of course is its unlikely you guys
have a developer's license for it... Thought I'd ask.

>4. What are your plans/thoughts on linking entities?  For example, in a
>standard diagramming section, I think FK relationships ought to be rendered
>graphically between objects.

Oh exactly! Just like MS Access query Designer and SQL Server designer. The
lines will be drawn between fields that are 'joined' and the line will
indicate clearly, graphically, any constraint settings that make a
difference. The line should also indicate clearly if the relationship
infers 1-M, 0/1-M, 1-1 etc. etc. again inmuch the same way MS Access does.

My thinking for coding this is that the DV object when wanting to draw a
line will ask a DT object at what Twip position from the TOP setting will
it find the 'node point' to start drawing the line from for given field
'fldFieldToDrawFrom'. Similary the DV will ask the next DT what the node
point is for the line to draw to and then the line is drawn between them
using the standard VB Line OCX. Then some maths works out other geometric
object positions to graphically represent the 1-M, 1-1 stuff, and any text
that may need to appear etc.etc.

>In the pane for the view designer though, the
>user ought to be able to draw the relationship and modify them to show
>inner, outer, cross joins, etc.

Indeed. Classic Drag/Drop should work here to enable the ability of coding
this.

We also have to deal with the issue that MS Access deals with in that if we
import two Tables into a View design which have a pre defined FK between
then, whether we assume this FK reference is the intended FROM...JOIN
required for the view. In my experiebnce with Access this is 80% often what
you need with the ability to delete the line in the View Designer when not
required for the odd query where you need to do something else.


Tim.


Re: table OCX control

From
Dave Page
Date:

> -----Original Message-----
> From: Tim Finch [mailto:pgadmin@timfinch.cix.co.uk]
> Sent: 08 March 2002 11:54
> To: Mark A. Taff
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] table OCX control
>
>
> You're right, Yes it should and no its not. Now to this end,
> whats the gas
> on us using commercially available OCX controls. I have a
> legal bought copy
> of VSView, which contains an OCX that is a 'scrollable pane'
> - it takes
> care of all that side of things. There are no financial
> licensing issues
> with distributing it, but the problem of course is its
> unlikely you guys
> have a developer's license for it... Thought I'd ask.

No commercial controls thank you. Standard redistributable Microsoft ones,
or our own only. Too many licencing and compatibility problems otherwise.

Regards, Dave.

Re: table OCX control

From
Dave Page
Date:

> -----Original Message-----
> From: Tim Finch [mailto:pgadmin@timfinch.cix.co.uk]
> Sent: 08 March 2002 11:37
> To: Mark A. Taff
> Cc: pgadmin-hackers@postgresql.org
> Subject: Re: [pgadmin-hackers] table OCX control
>
>
> In fact if we came up with a method of doing it Registry wise then
> something like the view designer could determine its own
> 'hives' and 'keys'
> and not care how, for example, the left hand tree view in
> pgAdmin stores
> its own project related settings. What do you think Dave/Jean?

Hmm, you saw my earlier thoughts on this. Keep it optional, keep it simple.
I guess the best bet would be to come up with a spec proposal for us all to
consider. It might be worth keeping the Projects to-do item in mind while
developing this - as one of you said, it is related. Jean-Michel might have
some comments on that - it's his to-do item.

Regards, Dave.

Re: table OCX control

From
Tim Finch
Date:
>
>No commercial controls thank you. Standard redistributable Microsoft ones,
>or our own only. Too many licencing and compatibility problems otherwise.
>
>Regards, Dave.

thought as much, no worries, just thought it was worth checking out.
Hey! I like a challenge!

Tim.