Re: table OCX control

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.