Skip site navigation (1) Skip section navigation (2)

Re: table OCX control

From: Tim Finch <pgadmin(at)timfinch(dot)cix(dot)co(dot)uk>
To: "Mark A(dot) Taff" <mark(at)libertycreek(dot)net>
Cc: <pgadmin-hackers(at)postgresql(dot)org>
Subject: Re: table OCX control
Date: 2002-03-08 11:53:37
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgadmin-hackers
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 

>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 

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.


In response to

pgadmin-hackers by date

Next:From: Tim FinchDate: 2002-03-08 11:55:25
Subject: Wine..?
Previous:From: Tim FinchDate: 2002-03-08 11:36:34
Subject: Re: table OCX control

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group